Toast knows what you sold. Toast knows who was clocked in. Almost nobody running a restaurant or a venue can put those two facts side by side on the same clock without a manager building a spreadsheet on their day off. You end up managing labor against a gut feel about which hours were busy, and the gut feel is usually a week behind the reality.
Two streams, pulled through the Toast API: sales and labor. Sales means orders, the items on them, and the timestamps that say when the money actually landed. Labor means shifts, job codes, and the hours worked underneath them. Menu items and job codes come across with their own identifiers so categorization is stable even when someone renames something on the terminal.
Both streams are normalized into the same time grid. That is the entire point. Weekly totals already exist in Toast; what does not exist is a view where a Friday between six and seven can be read against the hours you paid for in that same window.
The sync runs against the Toast API on a schedule and writes into a store you own. Sales are bucketed by hour as they come in, and labor hours are bucketed the same way, so every comparison is apples to apples rather than a daily total divided by a guess.
Categorization is where these builds usually go wrong, so we split it in two and hand both to you. One mapping editor covers menu items: which items roll into which revenue category, so that a seasonal cocktail and last year's version of it stop landing in different buckets. A separate mapping editor covers job codes: which codes are front of house, which are back of house, which are salaried and should not distort an hourly comparison at all.
You control both editors. We do not hard-code your categories into a build you have to call us to change, because menus change monthly and job codes change whenever a manager adds one at eleven at night. When a new item or code appears unmapped, it shows up as unmapped rather than getting silently dropped into "other".
The mapped, bucketed output feeds a weekly operating scorecard: sales by category against labor by category, on the periods you actually run on.
API access to your Toast account, authorized by someone with the authority to grant it for the locations in scope. If you run multiple locations, we need to know which ones belong in the same report and which are managed separately.
We also need a working session with the person who owns the menu and the person who owns the schedule. They define the initial categories in the mapping editors. That is a conversation about your operation, not a technical exercise, and it is the difference between a report managers argue with and one they use.
The synced data lands in a database in your accounts, under your access controls, not in a shared multi-tenant product. We pull transaction and labor records for reporting; we do not need or store card data. Access is scoped to the people you name.
No. This integration reads. Menu configuration, job codes, and shift records stay under the control of your managers inside Toast. The categorization we apply lives in our mapping editors, so a reporting decision never changes what your staff sees on the terminal.
The scorecard survives the switch. Sales and labor arrive through a sync layer, and the mapping and reporting sit above it, so replacing the source means rebuilding the sync rather than rebuilding the reporting. You would not be starting over.
You own it. It is a custom build in your accounts, handed to a named owner on your staff with the mapping editors documented. The recurring work is maintaining categories when the menu changes, and a manager can do that without touching code.
Field shapes move and endpoints get versioned. When that happens the sync fails or returns partial data, so the build treats a failed run as a visible event rather than a silent one. We fix the mapping to the new shape; you find out from a status indicator, not from a labor number that quietly went wrong.
Start with a complimentary industry analysis. You leave with the one project worth deploying first.
Schedule a Consultation