What to order, what to make ahead, when each delivery should land, what to move between sites, who is on when. Synapse answers each per location, from that location’s own history, and returns the answers to the systems your sites already run - ordering first, its interface documented end to end.
At one site, each mistake is somebody’s evening. Across hundreds of sites it is a line in the budget - and only one of the two mistakes appears on a report.
Stock at its date, written off. Batches binned at close. Afternoons with more staff than customers. This mistake is visible - it rolls up into a waste line and a payroll line - and somewhere on its way up it was renamed the price of doing business and given a budget.
This one is invisible. The shelf was empty, the customer left, nothing was recorded - the day just looked slow. At one shop the owner might notice. Across a chain, the report is the only witness: the next forecast reads the suppressed sales as truth, orders less and rosters fewer, and the mistake teaches itself to get worse at every site it touches.
Not an industry average. Not a regional average. That site.
At scale the usual compromise is the cluster: sites binned by format or region, each served the bin’s average. The average is wrong at every particular site - high where it is quiet, low where it is busy - and both errors are ordered, prepped and rostered, every week, at every site.
Synapse fits one demand forecast per location, from that location’s own history - its peaks, its opening hours, its quiet Tuesdays. Every other answer starts from that fit. The order, the prep plan, the delivery slot, the transfer and the roster agree with each other, because they came from the same picture of that site’s day.
The same input always produces the same answer, and anything that cut a number is named in plain language.
The shared forecast the other five read.
How much to buy, and for which delivery.
What to make ahead, and when to start.
When each delivery, pickup and handoff should happen.
Which stock to move between sites.
Who works, and when.
Everything a plan needs travels in the request. The service reads no database to answer you and, unless you switch plan storage on, holds nothing afterwards.
A plan request describes four things: what you sell, what has been selling, what is on hand right now, and the building it goes in. Send it as JSON assembled from your own systems, or as CSV exports posted for parsing - a column the parser cannot place is kept, never dropped. Units live in the field names; none is ever inferred.
How much to buy, where each line will physically go, and what bound every line it had to cut - the constraint by name, and the ideal it was cut from. Anything the engine assumed because your data did not say comes back in plain language, citing the default by name.
The same input produces byte-identical output, on any machine, at any hour. A plan’s id is a hash of the input and the engine version, so an unchanged id is proof that nothing changed - and a retried request cannot produce a second order. Pin the as-of date and a plan is reproducible whenever an audit asks for it.
The schema routes need no credentials, because you should be able to read the contract before you sign anything. A validation route answers with the full issue list - level, code, path, message, hint - so a feed can be fixed from the response alone.
Requests carry a bearer key. Keys are managed in the customer portal, held only as digests and compared in constant time; the plaintext never reaches a log line.
Ordering’s interface, end to end: the data contract, the CSV templates, the endpoints, the error table, and a worked plan computed by the real engine.
Two decisions, one made-up restaurant, computed in your browser. At your scale the surface is the API - but the engine answering below is the engine behind it, running the same in a browser tab as in the service. Every figure is worked out here, from its data.
Hartwell’s is a made-up 60-seat restaurant. Sixteen weeks of its sales are read here, and the week’s order is worked out in your browser. Change how you buy; the order follows.
Loading the demo…
The same sales history, read the other way: who works, when, and what the week’s wages come to.
Loading the demo…
The forecast and all five decisions run as six demos in the customer portal. Create an account there to run them.
No cutover on day one. Synapse runs beside the process you already have, and is judged against it.
A sales export and a list of what each site stocks, for the region you pick.
Synapse is set up against each site, and each site’s forecast is fitted from its own history.
The plans sit beside the orders your process actually placed, week by week. Keep whichever wins. No charge during the pilot.
Send a sales export and a list of what your sites stock. We set Synapse up against a region and run plans you can check against the orders you actually placed. No charge during the pilot.
API keys are managed in the customer portal. Create an account.