If you run Lightspeed, one question decides whether a voice agent is worth buying: does a finished phone order land in Lightspeed as a correct ticket? Everything else is a demo detail. A pleasant voice that drops the "no onions" costs you more than a call that rang out unanswered, because now you have paid for the food twice and annoyed someone who was already a customer.
X1 Voice reaches Lightspeed through Deliverect. Your items, prices and modifier structure come across, the agent prices each call against them, and the completed order is written back as an order Lightspeed handles like any other. Nobody re-types anything at the counter.
That routing detail is worth understanding rather than skipping past, because it shapes both what the setup asks of you and where the system will occasionally frustrate you.
What the Deliverect hop actually changes
A direct integration talks to the POS. A channel integration talks to a middleware layer that talks to the POS. Practically, three things follow from that.
Your menu has to exist in Deliverect before the agent can read it. If you already push Lightspeed to delivery marketplaces, this is done and setup is short. If you don't, publishing the menu is the real first task, and it is the step most likely to add a day.
Menu changes propagate on a sync, not instantly. Change a price in Lightspeed at 4pm and the agent picks it up on the next sync rather than on the next ring. For a price change that's fine. For an 86'd item on a Saturday night it matters, which is why you want to know how your vendor handles 86ing and menu sync failure modes before you rely on the agent to tell callers what's sold out.
Modifier names come across as whatever they are called in Lightspeed. If your build screen says "MOD - NO ONI", the agent inherits that, and it will read it aloud unless someone maps it to something a person would say. This is the single most common reason a well-built agent sounds wrong on its first day of calls.
The Friday night version of this
Here is what the integration looks like on a real shift rather than in a slide.
It's 6:40pm. Two people are on the line, one of them has a question about the gluten-free crust, and the counter is three deep. The agent answers on the second ring, takes a pickup order with a substitution, charges the card, and the ticket prints at expo with the modifier attached. Nobody at the counter looked up.
At the same time, a caller asks whether you cater a party of forty for Sunday. The agent doesn't try. It takes the name, the number, the headcount and the date, transfers if a manager is on, and leaves a transcript if not. That is the correct behavior, and it is the behavior worth checking in a demo — see human handoff and failover for how to write those rules.
The value shows up in the calls you never knew you were losing. Most operators underestimate their own miss rate because a phone ringing out during a rush leaves no record. Count the calls you miss in a typical week, multiply by your average ticket, and see whether the number is as small as it feels.
The failure mode nobody demos
Modifier tree mismatch, and it is worth being blunt about it.
Lightspeed menus grow organically. Somebody adds a "half and half" option under one pizza but not the other. Somebody builds sizes as separate items rather than as a size group. A required modifier group has a default that only makes sense if a human is standing at the screen. None of that hurts you when a trained employee is ringing it in, because the employee knows what the buttons mean.
An agent doesn't. It follows the structure. So it will either refuse a combination that is obviously fine, or fire a ticket that is technically valid and wrong in the kitchen.
The fix is not clever prompting. It's cleaning the structure, and it's a one-time job of a couple of hours for most menus. Simplifying modifier trees covers the specific patterns that break, and it's the work that separates an agent that runs quietly from one you turn off after a week.
Ask any vendor to take a deliberately awkward order on your real menu: "large, half pepperoni half plain, no onions on the second half, sub fries, add a Diet Coke, and use the coupon." Then walk to the printer. Do not accept the voice repeating it back correctly as proof. The repeat-back and the ticket are two different systems, and only one of them feeds the kitchen.
The numbers to check after a month
Four, and they take about twenty minutes to pull.
Answered-call rate, which should approach 100 percent and is the whole point. Order accuracy, measured by actually reading a sample of phone tickets against the transcripts rather than trusting a dashboard, using something like the order accuracy measurement method. Escalation reasons, sorted into "by design" and "by defect," where the defect bucket is your work list. And phone revenue as a share of total, compared against the same month before you turned it on.
If answered calls went up and phone revenue did not, the agent is taking calls that were already being answered. That's still worth something in labor terms, but it changes the payback math, and you should know which case you are in rather than assuming.
What setup actually costs you in time
Connecting the account is minutes. Reviewing what came across is not, and that's where the real day goes.
Plan on someone sitting down with the imported menu once, reading the item names aloud, and fixing the ones that sound like database fields. Set your hours, your delivery zones if you deliver, and any phone-only rules such as a minimum for delivery. Then place five or six test calls yourself, ordering the way your regulars actually talk rather than the way the menu is written. Most single locations are live well inside a day, and plans start at $250 a month, which you can check against your own call volume on the pricing page.
If you run Lightspeed at some locations and something else at others, that isn't a blocker. X1 Voice connects directly to Square, Clover and OrderCounter and reaches the rest of the supported POS list through Deliverect, so a mixed estate runs on one agent configuration.
The decision rule is narrow. Run the awkward-order test on your own menu, walk to the printer, and count how many of five calls produced a ticket you would have been happy to see a new employee ring in. If it's five, the integration is doing its job. If it's three, the problem is almost always your modifier structure rather than the voice, and that is fixable before you sign anything.