# Your first restaurant sales comparison

Your weekly total is higher. Did you get more orders, or did people spend more each time?

Once your POS data is connected to Feast, your AI can compare the two. The useful answer names the location, dates and sales definition, shows the calculation, and tells you when the data is incomplete.

## What the answer should look like

**Synthetic example. These numbers are invented to demonstrate the method, not customer results.**

Example Restaurant uses Square. Both periods are complete Monday-through-Sunday calendar weeks in America/New_York. Amounts are in US dollars.

| Metric | September 28 to October 4, 2026 | October 5 to October 11, 2026 | Change |
| --- | ---: | ---: | ---: |
| Order amount | $600 | $750 | +$150 (+25%) |
| Completed orders | 4 | 5 | +1 (+25%) |
| Average order amount | $150 per order | $150 per order | $0 |

**The higher total came from one more completed order, not a higher average order amount.** This comparison does not explain why the extra order happened. Marketing results, opening hours or other data may help investigate that next.

Here, order amount means the sum of the selected Square order amounts after the mapping subtracts tax, service charge and tip. It is not profit, a universal accounting net-sales definition or revenue attributed to marketing. A real comparison needs the definition that matches your POS report.

## Ask this with your own restaurant data

> For my restaurant, compare the last two complete Monday-through-Sunday weeks using the restaurant's local timezone. Use only one connected POS and location. Show the exact dates, source, sales definition, completed orders and average order amount. Check import coverage and missing amounts before interpreting a total. Explain whether the difference comes from order count, average order amount or both. Do not infer the cause from the comparison alone.

Name the restaurant if your Feast account has access to several. If data is still importing, the answer should say so. An empty query is not proof that the restaurant had no sales.

Check the same metric, location and local dates in your POS. Once those agree, ask the next question: which days or dayparts account for the difference?

[Start your free Feast setup](https://feastalytics.com/connect-ai). Choose your POS and AI, connect your restaurant data and book the setup call. We help you check the connection and ask your first question.

## Inspect or reproduce the example

The [downloadable JSON recipe and synthetic order rows](https://feastalytics.com/restaurant-data-first-answer.json) contain the exact inputs and expected outputs. They can be inspected without an account. They are not a public restaurant database and do not contain customer records.

The recipe uses Feast's current read-only `describeData` and `queryData` tools. Other Feast tools can change account data. A request to compare orders does not authorize sending messages, changing campaigns or writing to the POS.

### 1. Select the authorized restaurant and discover its fields

Call `listOrganizations`. Select the restaurant returned by the tool. In hosted MCP, add that `organizationId` to each following input. The CLI selects it with `--org`.

Call `describeData` for `interface.location` and `interface.order`. Read the returned fields and grammar before querying. Use `queryData` on `interface.location` to identify the location and source type. The JSON recipe includes these inputs.

Do not run the synthetic location ID against a real restaurant and interpret the empty result as zero sales. Replace it with the authorized location returned by the tools. Confirm that the history has finished importing before comparing totals.

### 2. Use local calendar boundaries

For this New York example, both weeks fall in daylight saving time. Midnight local time is 04:00 UTC:

| Week | Inclusive start | Exclusive end |
| --- | --- | --- |
| September 28 to October 4 | `2026-09-28T04:00:00.000Z` | `2026-10-05T04:00:00.000Z` |
| October 5 to October 11 | `2026-10-05T04:00:00.000Z` | `2026-10-12T04:00:00.000Z` |

An inclusive start and exclusive end keep an order exactly at midnight in only one week. Convert the restaurant's actual timezone for each period. Do not assume the UTC offset is always four hours, especially around daylight saving changes. A restaurant trading day that ends after midnight needs different boundaries.

### 3. Check missing amounts, then compare each week

The recipe first counts completed rows with a missing amount across both weeks. A nonzero result means the amount data is incomplete. Report that gap instead of replacing missing amounts with zero or presenting the total as complete. A zero missing-amount count does not establish that the full import is complete; check coverage separately.

For each week, `queryData` filters `interface.order` by `type`, `locationId`, `status` and the `closedAt` boundaries. It then aggregates `$amount` with `SUM` and `$id` with `COUNT`. The example only includes Square rows whose status is `COMPLETED`.

The second week's exact query input, before adding your authorized `organizationId` for hosted MCP, is:

```json
{
  "schemaName": "interface",
  "objectTypeName": "order",
  "commands": [
    {
      "type": "filter",
      "filter": {
        "type": "and",
        "filters": [
          { "$type": { "string": "square", "match": "EQ" } },
          { "$locationId": { "string": "synthetic-square-location", "match": "EQ" } },
          { "$status": { "string": "COMPLETED", "match": "EQ" } },
          { "$closedAt": { "datetime": "2026-10-05T04:00:00.000Z", "match": "GTE" } },
          { "$closedAt": { "datetime": "2026-10-12T04:00:00.000Z", "match": "LT" } }
        ]
      }
    },
    {
      "type": "aggregate",
      "aggregate": { "aggregate": { "$amount": "SUM", "$id": "COUNT" } }
    }
  ]
}
```

Its expected data is `[{"amount":750,"id":5}]`. After this aggregation, the `id` field contains the count, not an order identifier. Row identity and source definitions need checking before adapting this method to another POS.

### 4. Calculate the answer

**Average order amount = order amount / completed orders**

`$750 / 5 orders = $150 per order`

**Percentage change = (current value - previous value) / previous value x 100**

`($750 - $600) / $600 x 100 = 25%`

Do not calculate a finite percentage change when the previous value is zero. Show the absolute difference instead.

The fixture also contains open, canceled, other-location, other-source and out-of-period rows. The filters exclude them. Automated tests execute these same published payloads through Feast's query endpoint against isolated synthetic storage. That checks this example's query contract and calculations, not a live OAuth connection, POS ingestion or real restaurant's import completeness.

[Read the connector setup guide](https://feastalytics.com/restaurant-data-connector-quickstart.md) or [start your free setup](https://feastalytics.com/connect-ai).