If you run Micros Simphony, the question that decides whether a voice agent is worth buying is narrow: does a finished phone order arrive in Simphony as a ticket the kitchen can work from, priced the way the register would have priced it? A voice that sounds convincing and fires a wrong modifier is a more expensive problem than a call that rang out, because you make the food twice.
X1 Voice reaches Simphony through Deliverect. Your published items, prices and modifier groups come across, the agent prices each call against them, and the completed order is written back as a normal order. Nobody re-keys anything.
On a Simphony estate that plumbing detail carries more weight than it does elsewhere, because Simphony is rarely a single-store system.
Centrally managed menus change who does the work
Most Simphony deployments manage item definitions centrally and push them to properties. That's a strength for consistency and it changes the shape of a voice rollout in three ways worth planning around.
The menu has to be published to Deliverect for each property you want the agent to answer for. If the estate already pushes to delivery marketplaces, this exists. If it doesn't, publishing is the first real task and it is a corporate one, not something a GM can finish on a Tuesday afternoon.
Item names come across as their configured names. Enterprise menus accumulate names built for a button grid rather than for speech: abbreviations, size prefixes, internal codes. The agent inherits all of it and will say it aloud. Deciding what an item is called when spoken is a small governance decision that nobody owns by default, and it needs an owner before launch. Menu naming for voice clarity covers the patterns that read badly on a call.
Changes propagate on a sync rather than instantly. For price updates that's harmless. For a sold-out item mid-shift it is not, so establish what your 86 path looks like before you rely on the agent to tell callers what is unavailable.
What a rollout should look like
Do not turn this on across forty properties at once, even though the configuration would let you.
Pick one store with real phone volume and a manager who will actually report problems. Run it for two to three weeks. Read a sample of transcripts weekly rather than watching a dashboard, and keep a list of every phrase the agent handled badly. Almost all of those entries will be menu naming or modifier structure, not the voice model, and almost all of them are one-time fixes that then apply estate-wide.
Then roll to a second store that is deliberately different, ideally one with a different daypart mix or a heavier catering line. The failures that show up at store two are the ones that would have surprised you at scale. Designing a voice AI pilot lays out what to agree on up front, including exit criteria, so the pilot ends in a decision rather than in a shrug.
The rollout mistake specific to enterprise estates is treating this as an IT project with a go-live date. The technical connection is the short part. The menu grooming and the escalation policy are the parts that determine whether store managers keep it on.
The failure mode that shows up at scale
Modifier trees built for a trained operator.
A required modifier group with a sensible default, a size implemented as three separate items, a "half and half" option that exists on one pizza and not the other: none of this hurts when an employee who has worked the station for a year is ringing it in, because that employee knows what the buttons mean. An agent follows the structure literally. It will either refuse a combination that is obviously fine or send through a ticket that validates and is wrong at the pass.
The correction is structural, not conversational. Simplifying modifier trees covers the specific shapes that break. On a centrally managed estate this is genuinely good news, because you fix it once at corporate and every property inherits the fix.
The test to run, and what not to accept as proof
Ask the vendor to take a deliberately hard order on your real published menu, not a sample: "large, half one way half the other, hold the onions on the second half, substitute the side, add a drink, apply the promo." Then walk to the printer.
Do not accept the agent reading the order back correctly as evidence. The repeat-back and the injected ticket are separate steps, and only the second one reaches the kitchen. Integration depth, not voice quality, is the argument that should drive the purchase.
Run the same test with a caller who interrupts, changes their mind halfway, and asks a question about an allergen. What you are measuring is not whether the agent is charming. It is whether the ticket is right and whether the handoff happens when it should.
Run it at two properties with different menus, too. An agent that handles the flagship store cleanly and stumbles on a smaller property's regional items has a menu problem you want to find in a demo rather than in week three of a rollout.
The numbers worth pulling after a month
Answered-call rate, which should sit near 100 percent. Order accuracy, measured by reading a sample of tickets against transcripts rather than trusting a summary screen, using the order accuracy measurement method. Escalation reasons split into "by design" and "by defect," where only the second bucket is a to-do list. And phone revenue per store against the same period last year.
That last one is the honest test. If answered calls climbed and phone revenue did not move, the agent is absorbing calls that were already being answered by staff. That is still worth labor money, but it is a different business case than incremental revenue, and on a multi-unit estate the difference decides whether the rollout gets funded.
Setup runs under 24 hours per property once the menu is published, and plans start at $250 per month per location, which you can check against your own volume on the pricing page. If your estate mixes Simphony with other systems, that's ordinary; X1 Voice connects directly to Square, Clover and OrderCounter and reaches the rest of the supported POS list through Deliverect, so one configuration covers a mixed portfolio.
Start with one store and one hard order. If five test calls produce five tickets you would have been glad to see a new hire ring in, the integration is doing what it needs to. If three do, the gap is almost certainly in your item names and modifier groups, and that is worth fixing regardless of what you decide about voice.