How NX put conversational AI inside restaurant operations — and the boundary it will not cross.
Executive summary
The restaurant technology backlog is rarely a shortage of capability. It is a shortage of people willing to fill in forms. A loyalty program is one sentence at a leadership meeting and roughly forty settings in a configuration screen. A tip-out every server could describe in ten seconds is a matrix of jobs, departments, percentages and time windows. A new location's menu already exists — it is on a laminated card — and turning it into a working menu is a week of typing. The pattern is familiar to anyone accountable for technology across more than a handful of locations: capability bought, configured at the flagship, demonstrated once, quietly never rolled out. The gap between what a group has licensed and what its locations run is mostly data entry nobody has time for.
The industry's answer has been a chat window. Ours is different: Nexy fills the form in. An operator describes what they want in a sentence and Nexy returns the completed configuration — the loyalty plan, the tip pool, the menu, the unit conversions — grounded in that company's own records, every setting visible and editable before anything exists.
The trade is stated plainly because it is the whole of the risk. Anything that can fill in a tip pool can fill one in wrongly, and tips are wages. So Nexy is built to be structurally incapable of being the thing that commits the change. It drafts; a named person decides.
A conversational layer bolted onto the data. Point an assistant at the reporting warehouse and let managers ask questions. Genuinely useful, and the cheapest thing to ship, which is why nearly every vendor has one. It fails on where the work is. A manager who asks "what should my loyalty program be?" and gets four paragraphs of sound advice still has forty fields to fill in, and the forty fields were the reason it never happened. Prose is also unverifiable: an answer subtly wrong about your business looks exactly like one that is right, because nothing in it is anchored to a record you can check.
Autonomous agents with authority to act. Let it adjust prices, tune the tip-out, comp the unhappy table. The demonstrations are compelling and the wider market is clearly heading here. It fails on accountability, not capability. Restaurants sit inside wage law, tax rules, franchise agreements and card-brand rules, and every one of those regimes asks the same question afterwards: who decided this? "The system optimized it overnight" is not an answer for a labor board, a franchisee, a litigator or an auditor. The exposure is not that the agent is wrong — it is that when it is wrong, no person is in the record.
Build it against a language-service provider yourself. A first version is a weekend, and this is the most rational-looking option on the list. It fails on the ninety-five percent that is not the request. A suggestion that cannot be saved into your system is worth nothing, so you inherit the configuration rules, the per-company isolation, the validation, the cost attribution, and permanent maintenance of a supplier's lineup that changes underneath you every few months.
NX takes the first option's accessibility and the second option's ambition, and removes the second option's authority.
2. The model: four independent questions
Executives evaluating AI in an operational system tend to ask one question — "can we trust it?" — which is four questions wearing one coat.
Question
What answers it
What can Nexy see?
Your own records, scoped to the person asking
What can Nexy propose?
A fixed set of choices that already exist in those records
What can Nexy change?
Nothing. A person saves, through the ordinary path
Who asked, and what did it cost?
A record of every request
These are genuinely independent, and conflating them is why AI conversations in this industry stall. A system can be perfectly grounded and still have too much authority. It can have no authority at all and still leak one company's records into another's suggestions. It can be safe on both counts and still be unbudgetable, because nobody can attribute the spend to a location. A vendor should be able to answer all four separately.
3. The load-bearing idea, in practice
Nexy fills in the form. A person presses Save.
Not "usually", and not "unless configured otherwise". Drafting and committing are different operations performed by different parties, and Nexy only performs the first.
Three consequences follow. Nothing Nexy produces is live when it arrives — a drafted loyalty plan lands paused, with no guests enrolled and nothing sent to anyone. Every configuration change still has a person and a timestamp on it, because the save is the change. And the uncomfortable one: a draft nobody reads is a decision nobody made. The system cannot distinguish an operator who reviewed forty settings from one who pressed Save on sight. That boundary is where your governance has to live.
4. Mechanics I — What Nexy can see
A request is answered against your records as they are at that moment: the jobs your people actually work, the discounts that exist, the menu items and their prices, your units of measure, message templates, sales categories and time windows. That set is scoped to the company and location of the person asking. One group's records are never the basis for another group's suggestions, and there is no shared pool of "restaurant knowledge" assembled from customers.
So Nexy's understanding of your business comes from your business. It is not recalling a general impression of how restaurants work and dressing it in your terminology; it is reading your configuration and working inside it.
The sharp edge. A draft is therefore only as good as the records it had to choose from. A company that has never defined time windows gets a tip pool that runs all day, because there is no AM and no PM to reference. That is correct — inventing a time window would be worse — but it means the first fix for a disappointing draft is usually your reference data, not the request.
5. Mechanics II — What Nexy is allowed to propose
The shape of the answer is fixed before the answer is produced, and the available choices are the ones already in your records. Nexy cannot propose a discount you do not have, route money to a job nobody works, or attach a reward to a menu item that does not exist. Those are not instructions it is asked to follow. They are options it is never offered.
Where a request cannot be fully honoured, the draft says so on screen, in the operator's language, beside the settings affected. Two real examples: "No time ranges exist for this venue, so this pool runs all day. Add one to split an AM and a PM pool." And on a loyalty draft, a note that no text-message template exists yet, so reward notifications will go out by email only.
The failure mode worth engineering against is not Nexy declining to answer. It is Nexy quietly filling a gap with something plausible. A stated gap is cheap; a confident invention is found in production by a guest.
6. Mechanics III — What only the platform decides
Nexy handles judgment and language. Arithmetic, geometry, matching and limits belong to ordinary code, and the split is drawn on purpose rather than by convenience.
A digital menu board is the clearest case. Nexy chooses which category to feature, writes the headline, picks the palette and decides between a list and tiles — art direction, where taste is the whole task. It never places anything. No position of any element on a guest-facing board comes from Nexy, because a misplaced price is a customer-facing defect and layout is a solved problem in code.
The same line is drawn wherever it matters. On a vendor invoice, Nexy reads the paper; matching a line to your inventory item is code. On a loyalty or tip-pool draft, every number is clamped to a legal range and anything internally inconsistent is dropped before you see it. On daily sales, the decision that a day is abnormal is arithmetic against explicit thresholds — voids above a set share of gross, discounts above another, each with a dollar floor so a quiet Tuesday cannot trip a percentage. Nexy writes the explanation of an exception; it does not decide there is one.
The takeaway: the places where being wrong costs money are not the places Nexy owns.
7. Mechanics IV — What is recorded
Every request is a record: who asked, which location and company, what they asked for, what came back, which engine served it, and what it cost, to the cent. It is queryable alongside the rest of your operational history, and cost is attributable by person, location and company — which is what makes AI a budget line rather than a surprise. The expensive surfaces, image generation most obviously, are additionally capped per person per day and per location per day, so one enthusiastic user on a Regenerate button is a bounded exposure.
Access is revocable for one person, one location, or an entire company, and revocation is checked before anything is generated. It stops the spend, not just the answer.
8. No single dependency
Nexy is a capability, not a supplier. More than one language engine is in service, and which one handles a given workload is decided by measurement on real restaurant data rather than by version number.
That measurement routinely contradicts the marketing. On a benchmark menu with a known-good answer, the newest and most expensive engine available cost roughly six times the incumbent and extracted fewer items with worse modifier coverage. It was not adopted. Only generally-available engines are used — never preview versions, however capable — because a preview can be withdrawn without notice and many workloads share a default, so one quiet retirement would take a dozen features down together.
This matters at renewal time: the engine behind a feature can be replaced without the feature changing, and no single provider's roadmap sits on your critical path.
9. A worked draft
One sentence, typed into the loyalty screen by an owner who has been meaning to do this for a year:
1 point per dollar, $5 off at 500 points, points expire after 90 days
What comes back, seconds later:
Setting
Drafted value
How guests progress
Amount spent
Earn rate
1 point per $1
Reward
$5 off
Reward at
500 points
Points expire after
90 days
Status
Paused
Guests enrolled
None
Above it, a banner: "Drafted by Nexy — nothing is live yet", the reasoning behind the choices, and any gaps Nexy could not fill.
Two things here carry the paper. The arithmetic: a hundred points is a dollar, always, so this plan returns one percent of spend — and the units are counterintuitive enough that getting them wrong by a factor of ten is the commonest error in hand-built plans. And the last two rows: the programme does not exist yet. No guests, no earning, nothing sent to anyone.
That is the entire contribution — twenty minutes of form-filling reduced to a sentence, and a plan a person still has to read, adjust and turn on.
📸 Screenshot: the loyalty Setup screen immediately after drafting, with the banner at the top.
10. The conflation: a draft vs. a decision
This is the pair that gets merged, in both directions, usually by someone describing the system to a third party.
A draft
A decision
What it is
A filled-in but unsaved record
A live configuration
Who produced it
Nexy
A named person
Effect if nobody acts
None; it never existed
It is in force
How it appears in the history
As a request, with its cost
As a change by that person
Undoing it
Close the screen
The normal change process
Both swaps do damage. Treat a draft as a decision — "Nexy set up our loyalty program" — and you have described a system nobody reviewed, which is untrue today and, if it becomes the habit, eventually true. The person who saved it owns it, and that is the name asked for when a franchisee, an auditor or a wage claim arrives.
The reverse error is assuming a change is provisional because AI proposed it. Once saved, a generated record is indistinguishable from a hand-built one — same validation, same permissions, same audit entry, same effect at the register. That is intentional; a parallel class of "AI records" with their own rules would be a second system to reason about. A saved draft is simply a change, and unwinding it is ordinary change management.
11. Where the model deliberately stops
Nexy never moves money. It will draft the rule governing a tip pool; it never performs a distribution. It will draft a loyalty program; it never grants a reward, comps a check or issues a refund.
Nexy does not change your configuration on a schedule. There is no overnight optimization pass and no "apply recommendations automatically" setting to find, because the audit trail is the product here.
Two surfaces do run without a person, and both are narrow by construction. Written summaries are the first: the intra-day sales narrative, the end-of-day summary, a plain-language account of a single check's history for support. These produce words about the business, never changes to it, and they are throttled rather than continuous — regenerated only after a material move in sales and at least two hours after the last one, because a nearly identical paragraph every hour across a large estate is a bill, not information. The guest text-message concierge is the second: it can confirm or cancel that guest's own waitlist entry, reservation or order, or hand the conversation to a human. It cannot see another guest, has no general capability, is off until a location turns it on, and falls back to simpler keyword handling on any error.
Nexy is not the system of record for anything. Remove it entirely and every menu, plan, pool, board and report still exists and still works. You lose the shortcut, not the data.
That is by design, not an omission.
12. Timing
Stage
When
A configuration draft comes back
Seconds, on request
A photographed or PDF menu becomes a draft menu
Under a minute for a typical page
The intra-day sales narrative refreshes
On a material move in sales, at most every two hours
The end-of-day summary
Once the day's numbers are final, then locked
Anything becomes live
When a person saves it
The last row is the only one with no automatic answer, and that is the point of it.
13. Governance
The mechanics are settled by here. What remains is judgment, and it is mostly about the boundary in the load-bearing idea.
Require that every AI-drafted record still names a reviewer. The platform records who saved it. Your policy is what that person was expected to have read first.
Read the flags before the draft. They are the only part where Nexy tells you what it could not do, and the part that gets skipped. Skipping them is the most reliable way to get a wrong pool out of a working system.
Fix your reference data before you judge the output. "Nexy got the tip pool wrong" is very often "nobody ever set up time windows". Drafting quality is a downstream measure of configuration hygiene.
Budget the automatic surfaces, not the ones people click. Operator drafting is bursty and small. Recurring summaries across two hundred locations are the line that grows without anyone deciding to grow it — review that one monthly, per location.
Point the drafting tools at the locations that never got configured. The return is at the site with no loyalty program and no tip pool, not at the flagship that has both and a manager who likes the forms.
Enable the guest-facing agent one location at a time, and read a month of transcripts. It is the only surface where a mistake reaches a customer directly rather than an operator who can catch it.
Ask which engine serves each feature and when it last changed. If your vendor cannot answer, their AI strategy is one supplier's roadmap with a logo on it.
Put AI revocation in your offboarding checklist. A departure should remove it in the same pass as everything else.
14. Good to know
Nexy has one voice everywhere — a drafted plan's wording, an end-of-day summary, a support reply — so generated language reads as part of the product rather than a bolted-on second one.
A menu photographed on a phone can become a complete draft menu, items and modifier groups included. Accuracy is measured against known-good menus before any change is made to how it works.
Generated images are staged, not saved. Regenerate as often as you like; only the one you accept becomes an asset, and the rest expire.
Nexy's read capabilities can be granted to approved outside tools through an explicit consent step, with reading and writing separated. Write access is never implicit — it has to be ticked, and it is unticked by default.
NX support runs on the same capability operators use, which is why a support answer and an operator's answer tend to agree.
Every non-AI route to the same screen is still there. Guided setup, ready-made templates and a blank record all end in the same editor, and none of them involve Nexy.
15. Glossary
Nexy — the conversational AI built into NX. One capability with one voice across drafting, summarizing and guest messaging, rather than a separate product.
Draft — a filled-in but unsaved record. No effect on any guest, register or report until a person saves it; closing the screen ends its existence.
Grounding — answering from your own records rather than general knowledge, so every choice in a draft refers to something that exists in your configuration.
Flag — a plain statement on a draft of something Nexy could not do or was not certain about. Part of the answer, not an error.
Engine — the underlying language service handling a request. More than one is in use; which one serves a workload is decided by measurement and can change without the feature changing.
Revoke — withdrawing Nexy from a person, a location or a company. Applied before anything is generated, so it stops the spend as well as the answer.
Automatic surface — a place Nexy runs without anyone asking: the sales narratives, the end-of-day summary. These produce words about the business, never changes to it.