What we ask for, what we don't, and the controls you keep.
We hear the same hesitation from operators: "How do I share data without giving away the store?" Fair question. This page is the answer, written for the CFO, the controller, and the IT director who'll actually have to sign off.
The short version. We ask for a small, time-limited slice of POS data, three categories, thirty stores, ninety days. No PII. No PCI. No fuel. No totals. Anonymous store IDs you assign yourself. Mutual NDA before anything moves. Designed so nobody, not us, not anyone reading our work, can reconstruct your P&L from what we receive.
To tell whether a price change, a planogram reset, a promotion, a remodel, or a new product launch actually moved the needle, we need a baseline of how your stores were performing before the change and a peer set of stores that were not changed.
That is the entire reason for the data request. No data, no answer. Everything else on this page is about making the ask as small, controlled, and reversible as we know how to make it.
Most data conversations break down because the operator and the analyst have different mental models of what's being requested. Here's ours, side by side, so there's no ambiguity.
We do ask for
- Categories: 2 to 3 you choose, packaged beverages, snacks, candy, tobacco, or a foodservice subset.
- Stores: 30 stores you choose, labeled with anonymous IDs (Store_001 to Store_030) you assign.
- Time period: The last 90 days, day by day.
- Fields per row: Store ID, Category, SKU/PLU, Date, Units Sold, Sales Dollars at SKU level.
- Format: CSV, XLSX, or NAXML. Whatever your back-office system already produces. Ugly is fine.
We don't ask for
- No card data. No PAN, no PCI-scope data of any kind, ever.
- No customer PII. No names, phone numbers, emails, loyalty IDs.
- No employee or labor data. No cashier IDs, no shifts, no payroll.
- No fuel volumes or fuel dollars. The single largest line, we don't need it for inside-store work.
- No chain-level totals, no margin, no cost of goods. Nothing that would let anyone size or model the whole company.
Scope note: The numbers above describe our standard pilot. Specific scope, store count, time window, category breadth, is agreed in writing before any data moves. Larger engagements (longer history, more categories, multi-format chains) follow the same structural safeguards but at scope tailored to the question being answered.
The list above on the left is everything we need to do the work. The list on the right is everything we'd need and don't take in order to back into your P&L. By design, the data we receive cannot reconstruct your gross profit, your EBITDA, your same-store-sales trajectory, or your covenant ratios.
If it helps to see it: this is the structure your back-office team would send. Six columns. Anonymous identifiers you assign. Nothing tying a row back to a customer, a card, a cashier, or a chain total.
| Store_ID | Category | SKU | Date | Units | Sales_USD | What this column is |
|---|---|---|---|---|---|---|
| Store_007 | Bev_Energy | RB-16OZ-ORG | 2026-01-04 | 42 | $167.58 | Store_ID is anonymous. You assign it. We never know which store this is. |
| Store_007 | Bev_Energy | MD-16OZ-ORG | 2026-01-04 | 28 | $98.00 | Category is your label. We work with whatever taxonomy your POS uses. |
| Store_007 | Snack_Salty | LAYS-CLAS-LG | 2026-01-04 | 19 | $57.00 | SKU can be UPC, PLU, or your internal item number. Doesn't matter. |
| Store_012 | Bev_Energy | RB-16OZ-ORG | 2026-01-04 | 37 | $147.63 | Date is daily. We don't need hour-of-day; that introduces labor concerns we'd rather skip. |
| Store_012 | Snack_Salty | LAYS-CLAS-LG | 2026-01-04 | 22 | $66.00 | Units is integer count of items rung up. |
| Store_023 | Tobacco | MARLB-RED-PK | 2026-01-04 | 14 | $133.86 | Sales_USD is gross. Tax handling is whatever your POS exports, we adjust. |
| … | … | … | … | … | … | And so on. Roughly 30 stores × 90 days × 50–500 SKUs per category. |
Notice what's not in the file. No customer column. No card column. No employee column. No fuel column. No "total revenue" footer row. The structure is the safeguard, there's nothing in here that anyone could use to reverse-engineer your business.
This is the part that often surprises operators: the file we want is one your back-office team already generates. It has a name. They know the report. We're not asking for a custom export, we're asking for the standard one, filtered down to the categories and stores you choose.
| If you run on… | Ask for… | Standard since |
|---|---|---|
| PDI Enterprise | Item Movement Report (NAXML 3.x), filtered to your selected categories and stores | NAXML 3.4+ |
| PDI CStore Essentials | Daily Sales by Department + CStoreOffice Item Movement, exported as CSV | v.2018+ |
| Verifone Commander | Department Report + PLU Sales Report, exported as CSV; or NAXML via XMLGateway BOOutbox | NAXML 3.3+ |
| Gilbarco Passport | Combined PJR export from XMLGateway, merchandise only, NAXML 3.4 if available | v7+ |
| NCR / Aloha (foodservice) | Sales Summary by Daypart + PMix (Product Mix) report | v15+ |
| Toast (foodservice) | Sales Summary + Menu Item Sales, both built-in CSV exports | standard |
| Other | Tell us what you run. We've worked with most of them. Worst case, we send a tiny SQL helper for your DBA. | — |
The point: when this lands on your back-office team, the right answer to "can you run this?" is "yeah, give me twenty minutes." Not "let me see if our IT team can build something custom."
Every one of the items below is a commitment we put in the engagement letter, in writing, before any data moves. None of this is aspirational language, it's contract terms.
Mutual NDA, signed first
Three pages, not twelve. Your counsel can mark it up. Mutual means we sign the same restrictions you do.
You name the categories & stores
Not us. Pick what you want analyzed. Pick which 30 stores. Anything we'd want to suggest is a recommendation, never a requirement.
You assign the anonymous IDs
We never see real store numbers, addresses, or brand affiliations unless you choose to share them later. Store_001 means whatever you want it to mean.
Defined retention
Default: we delete the raw file 90 days after the engagement ends. Want it sooner? Say so. We'll write whatever timeline you want into the agreement.
No resale, no syndication
Your data does not become an input to anyone else's product. No data brokers. No CPG benchmark we sell elsewhere. This is in plain English in the NDA.
No identification, ever
Anything we publish, case studies, conference talks, blog posts, is fully anonymized and pre-cleared by you in writing. Default answer can be no.
Audit right
Ask in writing what files we hold and where; we answer within 5 business days. No hand-waving.
Right to terminate, anytime
Any reason. No questions. No fees. We delete what we have. No claw-back, no penalty.
The things your IT team will ask about when they review whoever they're about to share data with.
SOC 2 Type I scoping is targeted for after the first three pilot engagements close. We're not rushing it for the badge, we're sequencing it for when the controls actually matter most.
Additional commitments that legal and IT-security teams at publicly-traded operators look for. These apply to every engagement, public or private, but they are written here for the reviewers who need to see them spelled out.
Material Non-Public Information.
For publicly-traded clients, we treat any data received as if it could constitute Material Non-Public Information (MNPI). Seurat personnel with access to client data are prohibited from trading in client securities during the engagement and for 12 months following completion. Aggregated SKU-level performance data, even from a sample of stores, may be material under applicable securities laws, and we handle it accordingly.
Infrastructure and encryption.
Client data is stored exclusively in Google Cloud Platform (US region) with encryption at rest (AES-256) and in transit (TLS 1.2 or higher). Access is restricted to the named Seurat principal listed in the engagement letter. No data is processed by third-party subprocessors without explicit written client approval.
Breach notification.
In the event of any actual or suspected unauthorized access to client data, we will notify the named client contact within 72 hours of discovery, including the nature of the incident, data affected, and remediation steps. This commitment lives in the engagement letter, not just on this page.
From "okay, let's do this" to a written read on your data, here's the actual sequence. Total operator-side effort: roughly 60 minutes of back-office time, once.
Mutual NDA, today
We send our standard mutual NDA. Three pages. Your counsel can red-line. If you have a preferred form, we'll sign yours.
One-page data spec to your back-office team
Exact column names, exact format. Hand it to your PDI rep, your IT person, or whoever runs your back-office reports.
Your team generates the export
It's the report they already know how to run. Roughly 20 minutes of back-office time. Output is one CSV or NAXML file.
Secure transfer to us
SFTP, encrypted email, or your shared drive of choice. We accept whatever your IT team prefers.
Written read, in plain English
Within 14 days of receiving the file. Specific findings, peer benchmark where the cohort permits, one or two recommendations on what to test or change next. You decide whether and how to use it.
Twenty minutes to see if there's a fit.
If this all reads reasonably, the next move is a short conversation about your specific questions and which categories make sense to start with. We don't pitch on these calls, we listen, ask questions, and figure out together if there's a fit.