Running on Foodics: what we build next to it
For restaurant groups and partners on Foodics, we build the checks that sit next to it, starting with a Proof on your real data that takes 5 working days.
If your restaurants run on Foodics, we build what sits next to it: an agent that watches the order flow, a duplicate check on supplier invoices, and a venue database for a sales team. Each one starts as a Proof on your real data. It costs from 1,500 euro, takes 5 working days and writes nothing.
We are not Foodics, and we are not a Foodics partner. Their marketplace does not list us. We work as your technical team, on the access you grant.
How apps connect to Foodics, in their words
- The marketplace. The Foodics App Marketplace lists third-party apps in categories such as accounting, ERP, delivery management, inventory management, loyalty and online ordering. Xero and QuickBooks Online are among the apps it lists.
- The API. The Foodics API documentation describes a REST API that returns JSON, with a sandbox next to production. Its resources include orders, products, suppliers and purchase orders.
- Access. The Foodics docs say an app gets its access token through the OAuth 2.0 code grant flow, and that each token is limited by scopes.
- Webhooks. Foodics lists webhook events it posts to an app's address, such as order.created and order.delivery.created.
- Apps not on the marketplace. A Foodics help article says the client finds a technical team to build the integration, then emails Foodics support from the owner's address with the account number, the app name and the scope. It says the account plan must be at the Advanced level, or the client must have bought the API license.
That last route is how we work with you: you stay the account owner and decide the scope.
What we build next to it
- An operations agent on the order flow. It checks each order against your rules: an order stuck between a delivery app and the kitchen, a menu out of sync. In the Pilot it fixes only what your written rulebook allows, and hands the rest to a person with the evidence attached. Our delivery orders demo runs on synthetic data. On 7 replayed days, 249 planted incidents, it scored precision 0.98 and recall 0.99, with 95% handled without a person and 5% handed to a person.
- A duplicate check on supplier invoices. We read Xero, QuickBooks Online, Sage Business Cloud and Exact Online through their APIs, or CSV and Excel files. Each new invoice is checked against earlier ones before it is paid. Likely duplicates go on a hold list for a person.
- A venue database for a partner's sales team. The list your team sells from: venues collected from several sources, duplicates merged, the source kept for every field, and a nightly self-test that stops the update when it misses known cases.
The Proof path
- Day 1. One workflow, and 3 to 5 pass/fail tests written with you.
- The build. We build it on your real data in shadow mode: it reads and reports, and writes nothing. On Foodics that means a token limited to the scopes the workflow needs.
- The price. from 1,500 euro, half up front and half when it passes your tests. If it fails and we can't fix it within 5 working days, the first half comes back. The Proof is credited in full against a Pilot booked within 30 days.
- Next. The Pilot is from 6,000 euro and runs for 30 days, live in your systems against a baseline you agree first. You own the code.
A worked example, on synthetic data
Our sample day-5 output for the duplicate check has 20 sample invoices, 4 held. Every row is synthetic, in pounds. One supplier sent invoice DG-10482 on Monday and again on Friday as DG 10482, with a space for the dash. The check held it next to the original. A person cleared the list: 3 confirmed duplicates, 1 false alarm released. The false alarm was a monthly fee for a different month. The sample hold list shows each row's evidence.
Send us the job in the form below and a plan with a fixed price comes back within 24 hours.
Contact
Send us the problem or email jayron@geurs.com