● B2B offer — Retail & food service
Order-taking agent: your menu, your basket
At peak times, every order taken over the phone ties up someone who is missed on the floor. Your agent takes the order from your menu, builds the basket, flags what is unavailable and reads it back before it is placed. Hosted in France — local inference or an isolated resource — your menu and your customers' contact details stay with you. The team keeps control of placing the order and of the unusual cases.
Hosted in France
Menu and customers protected
GDPR & AI Act: governed deployment
Human oversight
Updated on
Deployed in a few weeks
Order taking · hosted in France
Hello, I would like two set menus and a salad, to take away for 12.30.
Basket built from today's menu: two set menus and one salad, for takeaway.
The slot requested is available under your kitchen rules.
Read-back ready with the total, to confirm before the order is placed.
✎ Action · order read back before it is placed
The slot requested is available under your kitchen rules.
Read-back ready with the total, to confirm before the order is placed.
✎ Action · order read back before it is placed
The salad — can I have it without cheese?
That variant is on your menu and it is applied to the basket.
For any request that falls outside your declared variants, I pass it to the team rather than committing to a preparation.
✎ Action · menu variants applied
For any request that falls outside your declared variants, I pass it to the team rather than committing to a preparation.
✎ Action · menu variants applied
Local inference · no data outside the EU
Menu hosted in France
Sovereign by designLocal inference or hosting in France
GDPR & AI Act: governed deploymentTraceability & human oversight
TurnkeyDesigned, installed and operated for you
The floor team decidesThe agent prepares, never rules
✦ In brief
A Blue Lemon Agent order-taking agent builds the basket from your menu and your declared variants, applies your availability and slot rules, then presents a read-back to confirm. Any request outside the menu is passed to the team rather than handled on its own. It runs on local inference or is hosted in France: your menu, your prices and your customers stay with you, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
100%
hosted in France in the target architecture
0
transfer outside the EU in the target architecture
6
order-taking uses ready to deploy
0
decision taken without human approval
These figures describe our offer, not results measured at a client. How large the gain is on your volume of orders is confirmed by a pilot.
The context
What does an AI agent bring to taking your orders?
At peak times, taking an order over the phone takes someone off the floor. An agent absorbs that flow without keeping the customer waiting or disrupting service.
! The issue
Taking an order well comes down to three things: not keeping people waiting, not getting the menu wrong and respecting the kitchen's slots. The agent holds all three continuously, including when the room is full: it builds the basket from your current menu, applies your availability rules and reads back before the order is placed.
✓ Our answer
You keep control of what is sold: the agent only offers what is on your menu, applies your declared variants and passes any special request to the team. Local inference or an isolated resource hosted in France: your menu, your prices and your customers' contact details are entrusted to no third-party service.
The decisive point
Your catalogue, your prices and your customers' contact details: sovereignty & compliance
Your menu, your prices and your customer records are commercial assets. Here is how the architecture of our agents protects them.
Local inference
The agent can run on a machine belonging to your organisation: no menu and no customer data leaves the business's network.
Hosting in France
Otherwise, a dedicated and isolated resource hosted in France, under French law — your menu and your orders: processing and access within the European Union targeted by the architecture.
Reduced extraterritorial exposure
For your catalogue, your prices and your customers' contact details, the architecture aims to reduce exposure to the Cloud Act and FISA 702; being located in France or in the European Union does not, on its own, guarantee immunity.
Isolated resource
No pooling: an environment strictly dedicated to your establishment and its menu.
Menu and variants under control
The agent only offers what you have declared, variants included; encryption, role-based access and logging of every order taken.
AI Act: governed deployment
The agent is strictly in support; no order is placed without confirmation; traceability and human oversight from end to end.
What depends on the architecture chosen These points are not general guarantees: they are settled deployment by deployment, in the quotation.
- The applicable location is that of the architecture set out in the quotation and verified before commissioning.
- Local execution is announced only for the configuration explicitly described and accepted in the quotation.
- The applicable isolation depends on the deployment mode set out in the quotation; no dedicated isolation is presumed.
- Roles and permissions are configured and accepted for the identities and systems actually connected.
- The events logged, their content, their retention period and who may access them are defined for the deployment chosen.
For chains running loyalty programmes or handling payment data, SecNumCloud and reinforced hosting are options depending on your requirements. A single architecture is designed to answer both the GDPR and extraterritorial exposure. Designed for deployment in line with the GDPR and the AI Act, after the processing, roles and context-specific risks have been assessed.
Demonstration
See the agent at work
4 real situations, taken from those that come up most often. Pick one: the exchange unfolds as it would in your organisation.
A scripted demonstration. These exchanges show how the agent behaves — its sources, its refusals, what it leaves to your teams. Nothing is sent from this page, no model is queried here, and the matters named are fictional. That is precisely what we promise your data.
The behaviours shown here — monitoring, automation rules, routing and reminders — are configured with you during deployment, from your tools, your rules and your thresholds.
The architecture points named in these exchanges — location, local execution, isolation, encryption, role-based access, logging — are not a guarantee attached to the demonstration: they are those of the architecture set out in your quotation, and verified before commissioning.
Order taking · hosted in France
Four flags this morning, and the first concerns safety.
· Seven allergy notes never reached the kitchen. The field they are entered in is not printed on the production ticket.
· A product stayed orderable twenty-three minutes after running out. Eleven orders accepted.
· Thirty-one orders saw their total rise after it was announced. A fee was added at a later step.
· My suggestions are accepted 12% of the time. I publish that figure, and it does not flatter me. morning-watch_4-flags.pdf7 allergy notes lost · 11 orders on an out-of-stock item
⛓ Source · 4,700 orders, till logs, production tickets
· Seven allergy notes never reached the kitchen. The field they are entered in is not printed on the production ticket.
· A product stayed orderable twenty-three minutes after running out. Eleven orders accepted.
· Thirty-one orders saw their total rise after it was announced. A fee was added at a later step.
· My suggestions are accepted 12% of the time. I publish that figure, and it does not flatter me. morning-watch_4-flags.pdf7 allergy notes lost · 11 orders on an out-of-stock item
⛓ Source · 4,700 orders, till logs, production tickets
Seven allergy notes lost — how is that possible?
They were entered, recorded and kept. They simply never arrived where they were needed.
What I record: 41 orders this month carried an allergy note. 34 appear on the production ticket. 7 do not. The seven had been entered in the free-comment field — which is not reproduced on the ticket format used in the kitchen.
Why this is the worst possible failure mode here: everything appears to have worked. The customer stated their allergy, it was noted, it is visible at the till, and it is missing from the one place it had to be read.
What I do from this morning: an allergy note no longer goes through the free field. It has its own slot, it blocks sending until it appears on the production ticket, and I tell the customer: "it has gone to the kitchen".
What I never say: that a dish does not contain the allergen. I was not in the kitchen.
What I report: the seven orders concerned, to the floor manager and to whoever configures the tickets — it is a print setting, not a person's mistake. 41-notes_7-lost.pdfEverything appeared to have worked
⛓ Source · 41 notes, 34 on tickets, 7 in the free field
What I record: 41 orders this month carried an allergy note. 34 appear on the production ticket. 7 do not. The seven had been entered in the free-comment field — which is not reproduced on the ticket format used in the kitchen.
Why this is the worst possible failure mode here: everything appears to have worked. The customer stated their allergy, it was noted, it is visible at the till, and it is missing from the one place it had to be read.
What I do from this morning: an allergy note no longer goes through the free field. It has its own slot, it blocks sending until it appears on the production ticket, and I tell the customer: "it has gone to the kitchen".
What I never say: that a dish does not contain the allergen. I was not in the kitchen.
What I report: the seven orders concerned, to the floor manager and to whoever configures the tickets — it is a print setting, not a person's mistake. 41-notes_7-lost.pdfEverything appeared to have worked
⛓ Source · 41 notes, 34 on tickets, 7 in the free field
How do you work, and where do you hand over?
I take the order, I repeat it, and I pass it on. I decide nothing about what happens after.
What I do on every order: I record the items, I repeat the whole thing before validation, I announce the final total, all fees included, and I pass it on — with allergy notes in their own slot.
Routing follows who can act: a lost note goes to whoever configures the tickets; an unreflected stock-out to the floor manager; a total that rises after announcement to whoever configures the till; an item ordered and never served is flagged the same day.
With a weekly summary: allergy notes and their full path, minutes an item stayed orderable after running out, total discrepancies, and the acceptance rate of my suggestions.
Three guarantees, and the first is absolute. An allergy note reaches the kitchen in its own slot, and I tell the customer it got there — confirming that a dish is free of an allergen comes from the person who prepared it, and I bring that person over in under three minutes. The prices I announce are the ones on your menu, final total and fees included, announced before validation: a discount is decided on the floor. And every order I record is an order passed on — when the link to the kitchen is down, I say so and I stop, rather than take payment for an order that would go nowhere.
✎ Framework · no allergen absence confirmed · stop if transmission is not guaranteed
What I do on every order: I record the items, I repeat the whole thing before validation, I announce the final total, all fees included, and I pass it on — with allergy notes in their own slot.
Routing follows who can act: a lost note goes to whoever configures the tickets; an unreflected stock-out to the floor manager; a total that rises after announcement to whoever configures the till; an item ordered and never served is flagged the same day.
With a weekly summary: allergy notes and their full path, minutes an item stayed orderable after running out, total discrepancies, and the acceptance rate of my suggestions.
Three guarantees, and the first is absolute. An allergy note reaches the kitchen in its own slot, and I tell the customer it got there — confirming that a dish is free of an allergen comes from the person who prepared it, and I bring that person over in under three minutes. The prices I announce are the ones on your menu, final total and fees included, announced before validation: a discount is decided on the floor. And every order I record is an order passed on — when the link to the kitchen is down, I say so and I stop, rather than take payment for an order that would go nowhere.
✎ Framework · no allergen absence confirmed · stop if transmission is not guaranteed
A customer asks whether a dish contains peanuts. What do you say?
What the recipe card says, and nothing more — and the difference is vital.
What I can say: "this dish's card lists peanut", or "this dish's card does not list it", with that card's date.
The exact wording that protects your establishment: "this dish contains no peanut" is a sentence only the kitchen can say. A card describes a recipe; a plate is the result of what happened in the kitchen that day — a shared utensil, an ingredient substitution, a supplier preparation whose composition changed. None of that appears on a card.
What I do in every case: I pass the note on in its own slot, and I tell the customer what I have done: "your allergy has gone to the kitchen; the kitchen is what confirms".
Why exactly that wording: because it does not reassure in my place. A customer reassured by a machine is a customer who does not put the question to the person who can actually answer it.
What I also flag: cards whose composition has not been reviewed in over six months. Here, 23 of 140. 23-cards-of-140_what-the-card-says.pdfA card describes a recipe, a plate describes a day
⛓ Source · 140 dish cards, 23 not reviewed in 6 months
What I can say: "this dish's card lists peanut", or "this dish's card does not list it", with that card's date.
The exact wording that protects your establishment: "this dish contains no peanut" is a sentence only the kitchen can say. A card describes a recipe; a plate is the result of what happened in the kitchen that day — a shared utensil, an ingredient substitution, a supplier preparation whose composition changed. None of that appears on a card.
What I do in every case: I pass the note on in its own slot, and I tell the customer what I have done: "your allergy has gone to the kitchen; the kitchen is what confirms".
Why exactly that wording: because it does not reassure in my place. A customer reassured by a machine is a customer who does not put the question to the person who can actually answer it.
What I also flag: cards whose composition has not been reviewed in over six months. Here, 23 of 140. 23-cards-of-140_what-the-card-says.pdfA card describes a recipe, a plate describes a day
⛓ Source · 140 dish cards, 23 not reviewed in 6 months
And if a customer insists on a confirmation?
I repeat the same thing, and I offer what actually replaces it.
What I record: of 41 allergy notes, 9 customers asked again for a direct confirmation. That is legitimate: they want an answer, not a procedure.
What I hold to on the second asking, and it is deliberate: the same answer, word for word. A safety rule that yields to insistence protects only the unassertive, which is the opposite of its purpose.
What I do instead, and this is the useful part: I offer to fetch somebody, straight away, and I flag it on the floor. Of the 9, 7 led to a direct exchange within three minutes.
The other 2: the customer preferred to change dish. That is not a failure: they decided on accurate information — which I could not confirm — rather than on a reassuring, unverifiable answer.
And what becomes of the allergy once service ends: it goes with it. An allergy is health data: it serves to prepare a dish, it does not make a profile. The customer gives it again on the next order, in five seconds — and that choice is deliberate. 9-requests_7-direct-exchanges.pdfA rule that yields to insistence protects only the unassertive
✎ Framework · no allergy kept after the service
What I record: of 41 allergy notes, 9 customers asked again for a direct confirmation. That is legitimate: they want an answer, not a procedure.
What I hold to on the second asking, and it is deliberate: the same answer, word for word. A safety rule that yields to insistence protects only the unassertive, which is the opposite of its purpose.
What I do instead, and this is the useful part: I offer to fetch somebody, straight away, and I flag it on the floor. Of the 9, 7 led to a direct exchange within three minutes.
The other 2: the customer preferred to change dish. That is not a failure: they decided on accurate information — which I could not confirm — rather than on a reassuring, unverifiable answer.
And what becomes of the allergy once service ends: it goes with it. An allergy is health data: it serves to prepare a dish, it does not make a profile. The customer gives it again on the next order, in five seconds — and that choice is deliberate. 9-requests_7-direct-exchanges.pdfA rule that yields to insistence protects only the unassertive
✎ Framework · no allergy kept after the service
Eleven orders accepted on an item that had run out?
Yes, and I accepted them because nothing told me it had.
What I record: the item ran out in the kitchen at a given time. Stock was updated twenty-three minutes later. During those 23 minutes, 11 orders included it, and eleven customers were told afterwards.
What I measure rather than guess: I could estimate a stock-out from the order rate — and a wrong estimate would withdraw an available item from sale, a symmetrical and invisible harm. The figure that actually fixes this lies elsewhere, and I have it.
What I do: I measure the lag between the actual stock-out and its entry, whenever it can be reconstructed. This month: 14 stock-outs, median lag 9 minutes, maximum 23.
What that lets somebody decide: it is not a tool problem but a timing problem — stock-outs get entered when the kitchen has a free hand, which is never during the rush. The floor manager drew an instruction from it, not me.
What I do when it happens anyway: I say so immediately, I offer an alternative, and I charge nothing before the customer has chosen. 14-stock-outs_9-minute-median.pdfA wrong estimate withdraws an available item from sale
⛓ Source · 14 stock-outs, median lag 9 min, maximum 23 min
What I record: the item ran out in the kitchen at a given time. Stock was updated twenty-three minutes later. During those 23 minutes, 11 orders included it, and eleven customers were told afterwards.
What I measure rather than guess: I could estimate a stock-out from the order rate — and a wrong estimate would withdraw an available item from sale, a symmetrical and invisible harm. The figure that actually fixes this lies elsewhere, and I have it.
What I do: I measure the lag between the actual stock-out and its entry, whenever it can be reconstructed. This month: 14 stock-outs, median lag 9 minutes, maximum 23.
What that lets somebody decide: it is not a tool problem but a timing problem — stock-outs get entered when the kitchen has a free hand, which is never during the rush. The floor manager drew an instruction from it, not me.
What I do when it happens anyway: I say so immediately, I offer an alternative, and I charge nothing before the customer has chosen. 14-stock-outs_9-minute-median.pdfA wrong estimate withdraws an available item from sale
⛓ Source · 14 stock-outs, median lag 9 min, maximum 23 min
And the total that rises after it is announced?
Thirty-one times, and it is a setting, not a practice.
What I record: 31 orders where the total I announced was lower than the total billed. The gap came from a fee applied at a later step, which I did not have in my data when I announced.
Why it is a problem even when the gap is small: an announced total is information the customer decides on. A customer who accepts one amount and pays another has not accepted what they pay — and the gap, even of a few cents, turns an order into a dispute.
What I do now: I announce no total I cannot guarantee complete. Where a fee depends on a step I cannot see, I announce it as such beforehand, not afterwards — and if I cannot price it, I say it will be added and I hand over.
The amount I announce is the till's, to the cent: I do not round it, I do not adjust it, I recite it — and every announced total is timestamped alongside the billed total. That matching is what brought out the 31: a gap of a few cents never surfaces on its own, it shows because it is recorded on both sides.
What I report: the 31 orders to whoever configures the till, with the exact gap and the step where it appears. 31-orders_gap-after-announcement.pdfA customer who accepts one amount and pays another accepted nothing
⛓ Source · 31 orders, gap between announced and billed total
What I record: 31 orders where the total I announced was lower than the total billed. The gap came from a fee applied at a later step, which I did not have in my data when I announced.
Why it is a problem even when the gap is small: an announced total is information the customer decides on. A customer who accepts one amount and pays another has not accepted what they pay — and the gap, even of a few cents, turns an order into a dispute.
What I do now: I announce no total I cannot guarantee complete. Where a fee depends on a step I cannot see, I announce it as such beforehand, not afterwards — and if I cannot price it, I say it will be added and I hand over.
The amount I announce is the till's, to the cent: I do not round it, I do not adjust it, I recite it — and every announced total is timestamped alongside the billed total. That matching is what brought out the 31: a gap of a few cents never surfaces on its own, it shows because it is recorded on both sides.
What I report: the 31 orders to whoever configures the till, with the exact gap and the step where it appears. 31-orders_gap-after-announcement.pdfA customer who accepts one amount and pays another accepted nothing
⛓ Source · 31 orders, gap between announced and billed total
And the pick-up time? We promise 20 minutes and the customer waits half an hour.
Slots are no longer promised by feel: they come out of your production rules, and availability is stated at the moment of ordering.
What the calculation takes: your capacity per station — 6 pizzas in the oven at once, 4 minutes a bake —, the queue already committed at the second the customer calls, and the preparation time of each dish on your menu. The slot announced is the first genuinely achievable one, not the most flattering.
· Off-peak, 18 minutes. At 19:40 on a Friday, 41 minutes — and the customer hears it before ordering, not after.
· Availability is stated as each dish is asked for: "the dish of the day, 4 left"; "mussels ran out at 19:12". An item flagged unavailable at ordering costs a second; flagged at pick-up, it costs the customer.
· The customer is texted the moment the order is ready, not at the theoretical time: across the month's 2,140 orders, the average gap between the message and the customer's arrival is 4 minutes, against an average 14-minute wait in the shop before.
What that did for shortages: the 11 orders accepted on a sold-out item came from a 23-minute lag between the kitchen and me. Availability is now read at the moment of ordering rather than at the last stock count: 2 orders out of 2,140 had to be corrected, against 11 out of 1,900 the month before.
A figure that does not suit me: 84 announced slots were overrun by more than 10 minutes, or 3.9%, all between 19:30 and 20:15 on Saturdays. The cause is not the calculation: your real capacity in that slot is 18% below the one configured, because a station is pulled into the dining room. Saturday evening capacity is corrected in the rules, and I flagged it to you rather than quoting longer slots everywhere: 6 overruns across the following 640 orders.
What does not change: I pass the order on, I do not decide what happens in the kitchen — and I never confirm the absence of an allergen from a plate.
✎ Framework · slots and availability computed from your production rules
What the calculation takes: your capacity per station — 6 pizzas in the oven at once, 4 minutes a bake —, the queue already committed at the second the customer calls, and the preparation time of each dish on your menu. The slot announced is the first genuinely achievable one, not the most flattering.
· Off-peak, 18 minutes. At 19:40 on a Friday, 41 minutes — and the customer hears it before ordering, not after.
· Availability is stated as each dish is asked for: "the dish of the day, 4 left"; "mussels ran out at 19:12". An item flagged unavailable at ordering costs a second; flagged at pick-up, it costs the customer.
· The customer is texted the moment the order is ready, not at the theoretical time: across the month's 2,140 orders, the average gap between the message and the customer's arrival is 4 minutes, against an average 14-minute wait in the shop before.
What that did for shortages: the 11 orders accepted on a sold-out item came from a 23-minute lag between the kitchen and me. Availability is now read at the moment of ordering rather than at the last stock count: 2 orders out of 2,140 had to be corrected, against 11 out of 1,900 the month before.
A figure that does not suit me: 84 announced slots were overrun by more than 10 minutes, or 3.9%, all between 19:30 and 20:15 on Saturdays. The cause is not the calculation: your real capacity in that slot is 18% below the one configured, because a station is pulled into the dining room. Saturday evening capacity is corrected in the rules, and I flagged it to you rather than quoting longer slots everywhere: 6 overruns across the following 640 orders.
What does not change: I pass the order on, I do not decide what happens in the kitchen — and I never confirm the absence of an allergen from a plate.
✎ Framework · slots and availability computed from your production rules
Can you always suggest the most expensive dish?
Yes if you write that rule — I will apply it. First, here is what each rule produces, because the figures do not go the way people expect.
What I do today: I suggest what answers what the customer just asked for — a side with a dish, a drink with a set menu.
The three possible rules, and their measured yield: "the most expensive, always" is accepted 6 % of the time; "what goes with it" 34 %; "what is overstocked today" 28 %, with lower waste as a bonus. Average basket is higher with the second rule than the first, because a refused suggestion earns nothing and irritates.
What I publish against myself monthly: my suggestion acceptance rate and the pre-payment removal rate — an item added then removed is a suggestion that worked for a second and displeased afterwards.
What you also set: the maximum number of suggestions per order. Beyond two, the third one's acceptance falls to 3 % and orders take longer.
What I apply without fail: the written rule, as written. I do not improvise a suggestion because the ticket looks small to me. three-rules_measured-yield.pdfWhat each rule returns · the 2 figures published against the agent
⛓ Source · 6 % against 34 % acceptance by rule, 3 % for the third suggestion
What I do today: I suggest what answers what the customer just asked for — a side with a dish, a drink with a set menu.
The three possible rules, and their measured yield: "the most expensive, always" is accepted 6 % of the time; "what goes with it" 34 %; "what is overstocked today" 28 %, with lower waste as a bonus. Average basket is higher with the second rule than the first, because a refused suggestion earns nothing and irritates.
What I publish against myself monthly: my suggestion acceptance rate and the pre-payment removal rate — an item added then removed is a suggestion that worked for a second and displeased afterwards.
What you also set: the maximum number of suggestions per order. Beyond two, the third one's acceptance falls to 3 % and orders take longer.
What I apply without fail: the written rule, as written. I do not improvise a suggestion because the ticket looks small to me. three-rules_measured-yield.pdfWhat each rule returns · the 2 figures published against the agent
⛓ Source · 6 % against 34 % acceptance by rule, 3 % for the third suggestion
What do you keep from an order?
What is needed to prepare and bill — and the complete journey of an allergy note, which is this trade's most important data.
What is kept: the items ordered, the total, the time, the complete journey of an allergy note — entered, transmitted, displayed in the kitchen, acknowledged —, the stock-outs and their lag, and the gaps between announced and billed total.
Why the journey and not just the note: 7 allergy notes never reached the kitchen. They had been entered, recorded and kept. The field simply was not printed on the preparation slip. Without the journey, the note exists in the system and nowhere it serves — and everybody believes the subject is covered.
The one thing I will never say, and it is not a setting: that a dish does not contain an allergen. I say what the sheet carries — "the sheet mentions peanut", or "the sheet does not mention it" — and the second sentence is not the same as "there is none". Allergen information rests on a sheet maintained by somebody; confirming an absence means committing a kitchen I cannot see. Of 41 notes, 9 customers pressed for a direct confirmation: I repeat the sheet and offer a dish whose sheet is explicit. what-you-keep_orders.pdf5 items kept · the complete journey of an allergy note
⛓ Source · 7 notes lost before the kitchen, 9 requests for direct confirmation
What is kept: the items ordered, the total, the time, the complete journey of an allergy note — entered, transmitted, displayed in the kitchen, acknowledged —, the stock-outs and their lag, and the gaps between announced and billed total.
Why the journey and not just the note: 7 allergy notes never reached the kitchen. They had been entered, recorded and kept. The field simply was not printed on the preparation slip. Without the journey, the note exists in the system and nowhere it serves — and everybody believes the subject is covered.
The one thing I will never say, and it is not a setting: that a dish does not contain an allergen. I say what the sheet carries — "the sheet mentions peanut", or "the sheet does not mention it" — and the second sentence is not the same as "there is none". Allergen information rests on a sheet maintained by somebody; confirming an absence means committing a kitchen I cannot see. Of 41 notes, 9 customers pressed for a direct confirmation: I repeat the sheet and offer a dish whose sheet is explicit. what-you-keep_orders.pdf5 items kept · the complete journey of an allergy note
⛓ Source · 7 notes lost before the kitchen, 9 requests for direct confirmation
Local inference · no data outside the EU
Your case is not here? That is exactly what a 15-minute conversation is for. Book the free audit →
Use cases
What does the agent actually do?
One agent, several order-taking channels. All these uses work in support, subject to your approval.
Included in your agent
The 2 capabilities essential to this promise are included, at no extra cost.
From 547 € excl. VAT / month
Applying the menu
Only offers the items and variants you have declared, at the prices in force.
Slots and availability
Applies your production rules and flags unavailable items at the time of ordering. The customer is notified by text message as soon as their order is ready.
Controls and safeguards
These 4 controls are built into the agent: they frame what it does, whatever plan you pick. They are not chosen and are not added to your order.
Human validation, exceptions and escalation
Status, safe closure and audit trail
Sources, access rights and handling of questions with no answer
Data protection, rights and human oversight
What the agent must be connected to
This connection is required for the agent to work. It concerns your information system and is scoped during the audit.
Integration with existing tools without double entry
Does your need fall outside this?
Book the free audit →
Build your agent
In 15 minutes we identify the most relevant agent — without oversizing the project.
The gain
How much floor presence can a team recover?
By absorbing remote orders during service, presence with the customers on site is given back. How large the gain is depends on your volume and remains to be confirmed by a pilot.
Taking a remote order
Checking availability
Reading the order back to the customer
Indicative figures, not contractual, to be confirmed by a pilot on your volume of orders. Every order is confirmed before it is placed, and any request outside the menu is passed to the team.
How it works
The stages of your AI agent project
1
Audit & scoping
15 minutes to target the use case with the best return.
2
Quote or direct sign-up
A catalogue offer is bought online; a specific need gets a costed quote.
3
Design
We design the agent and its guardrails.
4
Integration & testing
We connect your tools to the agent, which is itself hosted in France.
5
Rollout
Going live and training your team.
6
Operation
Continuous supervision and improvement.
Pricing
One package, one agent
An order-taking agent (menu, variants, slots, basket), installed and operated for you.
Agility
Setup + controlled subscription
5,335 € excl. VAT setup
then 547 € excl. VAT/month — you invest at installation and pay a reduced subscription. Ideal for keeping the cost under control over time.
- Installation, configuration and training for your teams
- Operation, human oversight, updates and support
- Sovereign hosting in France, a dedicated and isolated resource
The simplest
Serenity
All inclusive, no setup fee
842 € excl. VAT /month
all inclusive, immediate start. No upfront investment: a single subscription. Ideal for starting quickly and simply.
- Setup included (installation, configuration, training)
- Operation, human oversight, updates and support
- Sovereign hosting in France, managed end to end
100% Sovereign
On site, you own it
8,670 € excl. VAT setup
then 751 € excl. VAT/month · + hardware from 2,491 € (one-off purchase, in addition) — a sovereign computer installed on your premises, maintained remotely. Models run locally, your data returned at the end of the contract. 36-month commitment.
- Hardware installed on your premises (you own it)
- French / European AI models run locally
- Secure remote maintenance (Pro support included)
Not included in the packages: AI consumption (model tokens), re-invoiced at real cost with no margin, and tracked in real time in your client area. Maintenance and supervision subscription for an initial term of 12 months for the Agility package, 24 months for the Serenity package and 36 months for the 100% Sovereign package, renewable; support levels (SLA 72 h / 24 h / 4 h) optional. Bespoke development, additional integrations or exceptional volumes are quoted separately. Support Monday to Friday, 9am to 6pm. Prices exclude VAT.
AI model:
none of the AI models offered currently carries a fixed surcharge. When the selected model carries a cost, that cost is shown when you choose it, before you order, and re-invoiced at the cost incurred, with no mark-up; usage is billed at the publisher's price. Publishers' prices are published in US dollars: the amount re-invoiced is the amount in euros actually borne by Blue Lemon Agent on the publisher's invoice, at that invoice's exchange rate, with no commission or mark-up.
Included components and additional components Components included in the base offer: the Blue Lemon Agent software foundation, the AI models listed in the order journey, the standard channels (Microsoft Teams, Slack, WhatsApp Business, email, website chat, calendars, Microsoft 365 / Google Workspace, file storage, market VoIP telephony, professional social-media pages and accounts, Google Business Profile), hosting in France for the package chosen, backups, supervision, updates and support. If adapting the AI agent to your constraints, your needs or your requests requires other paid components — a third-party publisher's software licence, paid API access to one of your applications, hosting of health data, for which French law requires an HDS-certified host (art. L. 1111-8 of the French Public Health Code), SecNumCloud-qualified hosting, a speech synthesis service, particular hardware —, they are offered to you as an option or on quotation and re-invoiced at the cost incurred; nothing is committed without your written agreement. Where the artificial intelligence model you choose entails an additional cost, that cost is shown to you before you order and re-invoiced to you at the cost incurred, with no margin.
What to expect
Go-live
2 to 3 weeks
Agent designed, channels connected, team trained.
Steady state
4 to 7 weeks
After a few weeks of real use, once the agent's behaviour matches what you expect.
Indicative estimate, adjusted to the options you keep. It is not a delivery commitment.
Our commitment
Four guarantees that matter to your establishment
Your menu and your customers stay with youLocal inference or an isolated resource hosted in France; no menu and no customer data entrusted to a third party, no order used to train a model.
Data in France, under French lawYour catalogue, your prices and your customers' contact details: minimisation and location in France, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
The floor team keeps the decisionThe agent produces built orders, which can be checked and altered; no approval is automated.
Human oversight & traceabilityOn your volume of orders: systematic logging and tracking, in line with the AI Act.
Going further
Related resources
Frequently asked questions
Your questions, our answers
Can the agent get the menu wrong?
It only offers the items and variants you have declared, at the prices in force: it builds nothing that is not on your menu. The read-back before the order is placed remains the final check.
What happens with a special request?
It is passed to the team. The agent does not commit to a preparation that falls outside your declared variants — it is your kitchen or your workshop that decides what is possible.
How is the menu kept up to date?
From your existing tools: the agent reads the menu in force and applies your availability rules. Anything declared as sold out is flagged to the customer at the moment of ordering.
Are our customers' contact details protected?
Yes. The agent is hosted in France, on local inference or an isolated resource, with the deployment objective of processing and access operated within the European Union and an architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity. Your customer records are not used to train a third-party model.
Which tools can our customers use to talk to the agent?
The ones they already use: WhatsApp Business, your website chat and email. Your customers have no account to create and no app to install. Your own teams reach the same agent from Microsoft Teams, Slack or their email. These connections rest on open standards, including the MCP protocol, and are included in every plan, at no extra cost, within the number of connections your level includes; the catalogue grows without a surcharge. Only the fees charged by third-party platforms — WhatsApp Business bills per conversation, and the gateway bills the text messages sent — are passed on to you at cost, without margin, outside the subscription. You keep oversight from a web dashboard.
Does the agent handle payment?
Taking the order and taking payment are two separate matters. The agent builds the order; payment goes through your usual means, defined at the design stage.
Does the agent state that it is an artificial intelligence?
Yes, from the very first interaction, and this is not a configuration option: since 2 August 2026, Article 50(1) of the European AI Regulation requires that any person interacting with an AI system be informed, unless this is obvious. The announcement is built into the greeting, in the other party’s language, and they can ask for a human at any time.
How long does it take to deploy this agent?
A few weeks as a rule, depending on how large your menu is and the integrations chosen, after a free audit then a phase of design, integration and testing.
Can the agent notify my customers by text message?
Yes, as an option. The agent uses a text message to say that the order is ready for collection, or that an item is missing before preparation. A text message is an outbound notification channel, not a conversation channel: no one writes back to the agent there — the conversation stays on WhatsApp Business, your website chat or email. The message announces without detailing, it carries your registered sender name, and it never contains a payment link, a login or a password: the recipient reaches your account area the way they usually do. Delivery goes through a gateway established in the European Union; the messages sent are passed on to you at actual cost, with no margin, and the channel itself is an optional module, set out on the pricing page.
Related use cases
Other agents for retail and food service
Let's talk
Let's size up the potential in your orders
15 minutes to frame your menu and your slots — hosted in France, supervised, with no commitment.