● B2B offer — Customer service at scale
Customer service at scale: several agents, one point of supervision
Past a certain volume, customer service can no longer be handled by a single agent: it takes several specialised agents — common questions, orders, complaints, technical — coordinated under a single point of supervision. This system orchestrates them, routes requests according to your rules and escalates to an adviser as soon as the situation calls for it. Hosted in France: your customers' exchanges stay with you.
Hosted in France
Customer exchanges protected
GDPR & AI Act: governed deployment
Human oversight
Updated on
Deployed in a few weeks
Customer service at scale · hosted in France
How are requests being spread across the agents right now?
Breakdown by specialised agent: common questions, order tracking, complaints, technical — volumes and queues in progress.
Requests are routed according to your routing rules, and the reason for the routing is kept.
Escalations to an adviser are shown with their cause.
🔗 Sourced · processing queues and routing rules
Requests are routed according to your routing rules, and the reason for the routing is kept.
Escalations to an adviser are shown with their cause.
🔗 Sourced · processing queues and routing rules
What happens during a spike in activity?
The system absorbs the volume on the requests covered by your content, and maintains the priority of the queues you have designated as priorities.
Situations that call for an adviser are passed on with the full thread, whatever the volume.
✎ Support · queues prioritised, escalation preserved
Situations that call for an adviser are passed on with the full thread, whatever the volume.
✎ Support · queues prioritised, escalation preserved
Local inference · no data outside the EU
System 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 customer relations department decidesThe agent prepares, never rules
✦ In brief
A Blue Lemon Agent multi-agent customer service system coordinates several specialised agents — common questions, orders, complaints, technical — under a single point of supervision, routes requests according to your rules and escalates to an adviser with the full thread. Sized for high omnichannel volume. Hosted in France, 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
customer service 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 the volume of requests, the number of channels and specialised agents is confirmed by a pilot.
The context
What does a multi-agent system bring to your customer service?
At scale, the question is no longer how to answer one request, but how to orchestrate thousands of them.
! The issue
At high volume, customer service needs specialisation — each type of request calls for its own content and rules — and coordination: readable routing, prioritised queues, overall supervision. The system brings both, keeping for every request the reason it was routed as it was.
✓ Our answer
The customer relations management has a consolidated view of the queues and agents specialised by domain. Escalation to an adviser is preserved whatever the volume: it carries the full thread, so the customer has nothing to repeat. Local inference or an isolated resource hosted in France: your customers' exchanges and data are not entrusted to any third party.
The decisive point
Your customers' exchanges and data: sovereignty & compliance
Large-scale customer service concentrates a considerable volume of personal data. Here is how it is protected.
Local inference
The agent can run on a machine belonging to your organisation: no customer exchange or data leaves the network.
Hosting in France
Otherwise, a dedicated and isolated resource hosted in France, under French law — your contact channels and processing queues: processing and access within the European Union targeted by the architecture.
Reduced extraterritorial exposure
For your customers' exchanges and data, 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 company and its routing rules.
Reason for routing kept
Every request keeps its agent, its routing reason and its timestamp; encryption, role-based access (RBAC) and logging by queue.
AI Act: governed deployment
The agent is strictly in support; no answer outside approved content and no goodwill gesture granted; 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 exchanges concerning a dispute, an unpaid invoice or a sensitive complaint, 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
5 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.
The company in this demonstration
Fictional companyMaisonor — home equipment retailer
- Sector
- Home equipment retail — 62 stores and an online shop, with home delivery and installation
- Headcount
- 1,840 staff, including 96 customer service advisers across 2 sites, 6 supervisors and 1 customer relations director
- People served
- 1.4 million active customers, including 210,000 orders delivered and installed at home every year
- Scale
- 840,000 requests a year across 5 channels — 310,000 calls, 250,000 emails, 160,000 chat conversations, 78,000 social media messages, 42,000 web forms — with peaks of 11,400 requests in a single day
- Tools in place
- Ticketing tool, telephony, chat platform, order management and a knowledge base of 1,240 articles — the system plugs into them, nothing is replaced or migrated
- Who decides
- The customer relations director settles the routing rules; the adviser alone grants any goodwill gesture and any date commitment; the supervisors arbitrate queue priorities
- Room for improvement
- Handling routine requests takes 65 % of advisers' time; routing to the right person takes 40 % of the time to a useful first answer; picking up context takes 30 % of an escalation; and a customer repeats his situation 2.3 times on average before getting his answer
Maisonor has crossed the volume at which a customer service operation can no longer be run by hand: 840,000 requests a year across five channels, with days reaching 11,400. Four specialised agents — routine questions, order tracking, complaints, technical — work under a single supervision view and pass requests along according to rules written by customer relations. The system runs on local inference on a machine belonging to the retailer, or on an isolated resource hosted in France; it plugs into the ticketing tool, the telephony, the chat platform and order management, and any situation calling for an adviser reaches him with the full thread. The exchanges below cover a year, from go-live to the review before the executive committee.
This company, its figures and the exchanges that follow were invented for the demonstration. They illustrate a common situation; they describe no real client.
Customer service at scale · hosted in France
I read your 840,000 requests of the year across the five channels, and I draw from them a split your queues carried without anyone being able to read it at a glance.
A specialised agent is an agent dedicated to one family of requests: it has its own content, its own rules and its own permissions, and it answers nothing else.
What the sorting gives:
· Routine questions — 372,000 a year: opening hours, product availability, payment methods, return conditions, loyalty card queries.
· Order tracking — 248,000: delivery date, installation slot, change of address, parcel announced and not received.
· Complaints — 138,000: damaged product, faulty installation, delay, invoicing.
· Technical — 82,000: assembly, spare parts, compatibility, manufacturer warranty.
What is built and ready: the four agents, each with its own content and permissions, and above them a single supervision view showing the four queues side by side, by volume, by lead time and by escalation.
What that shifts, calculated on your own records: handling routine requests goes from 65 % to 8 % of your advisers' time. Your 96 advisers stop handling 840,000 requests of every kind and handle the 126,000 situations that genuinely call for an adviser — the same headcount on work that is not the same.
And the measure that makes everything else checkable: each request keeps the agent that took it, the reason it was routed there and its timestamp. 840,000 out of 840,000 — a customer service figure you cannot explain is a figure you cannot correct.
What I propose: that your customer relations director open the supervision view tomorrow at 9 am, at peak hour, and watch the four queues for twenty minutes. Whatever she wants at the top, I put at the top the same day. four-specialised-agents_840000-requests.pdf65 % → 8 % of advisers' time
⛓ Sourced · 840,000 requests of the year across 5 channels, ticketing queues, adviser time records
A specialised agent is an agent dedicated to one family of requests: it has its own content, its own rules and its own permissions, and it answers nothing else.
What the sorting gives:
· Routine questions — 372,000 a year: opening hours, product availability, payment methods, return conditions, loyalty card queries.
· Order tracking — 248,000: delivery date, installation slot, change of address, parcel announced and not received.
· Complaints — 138,000: damaged product, faulty installation, delay, invoicing.
· Technical — 82,000: assembly, spare parts, compatibility, manufacturer warranty.
What is built and ready: the four agents, each with its own content and permissions, and above them a single supervision view showing the four queues side by side, by volume, by lead time and by escalation.
What that shifts, calculated on your own records: handling routine requests goes from 65 % to 8 % of your advisers' time. Your 96 advisers stop handling 840,000 requests of every kind and handle the 126,000 situations that genuinely call for an adviser — the same headcount on work that is not the same.
And the measure that makes everything else checkable: each request keeps the agent that took it, the reason it was routed there and its timestamp. 840,000 out of 840,000 — a customer service figure you cannot explain is a figure you cannot correct.
What I propose: that your customer relations director open the supervision view tomorrow at 9 am, at peak hour, and watch the four queues for twenty minutes. Whatever she wants at the top, I put at the top the same day. four-specialised-agents_840000-requests.pdf65 % → 8 % of advisers' time
⛓ Sourced · 840,000 requests of the year across 5 channels, ticketing queues, adviser time records
Why four agents rather than one that can do everything? That is what we are offered elsewhere.
Because I measured it on your own requests, and the accuracy gap is 23 points.
The test, and it is reproducible: 4,000 requests from last year, whose right answer is known since they were handled and closed. I ran them twice — once through a single agent carrying all 1,240 of your articles, once through the four specialised agents.
· Single agent: 64 % right answers first time.
· Four specialised agents: 87 %.
· The gap sits in two families: technical goes from 41 % to 83 %, and complaints from 52 % to 79 %. On routine questions the gap is 4 points: there, a single agent does almost as well.
Why, in one sentence: a complaint and a spare-part compatibility question are not answered with the same content nor with the same permissions. An agent carrying everything arbitrates constantly between 1,240 articles; an agent carrying 190 technical articles answers within its field.
And what specialisation brings beyond accuracy: permissions follow the specialty. The “routine questions” agent does not see the bank details on a disputed invoice; the “complaints” agent does. That is stronger than an instruction, because it can be checked with one command.
What I propose next: that the same test run every quarter on 4,000 fresh requests, and that I hand you the gap family by family. The quarter a family stops improving, it is its content that needs reworking, and I will tell you which — article by article. specialisation_87-percent-against-64.pdf4,000 requests replayed, gap by family
⛓ Sourced · 4,000 closed requests from last year, knowledge base of 1,240 articles, permission matrix per agent
The test, and it is reproducible: 4,000 requests from last year, whose right answer is known since they were handled and closed. I ran them twice — once through a single agent carrying all 1,240 of your articles, once through the four specialised agents.
· Single agent: 64 % right answers first time.
· Four specialised agents: 87 %.
· The gap sits in two families: technical goes from 41 % to 83 %, and complaints from 52 % to 79 %. On routine questions the gap is 4 points: there, a single agent does almost as well.
Why, in one sentence: a complaint and a spare-part compatibility question are not answered with the same content nor with the same permissions. An agent carrying everything arbitrates constantly between 1,240 articles; an agent carrying 190 technical articles answers within its field.
And what specialisation brings beyond accuracy: permissions follow the specialty. The “routine questions” agent does not see the bank details on a disputed invoice; the “complaints” agent does. That is stronger than an instruction, because it can be checked with one command.
What I propose next: that the same test run every quarter on 4,000 fresh requests, and that I hand you the gap family by family. The quarter a family stops improving, it is its content that needs reworking, and I will tell you which — article by article. specialisation_87-percent-against-64.pdf4,000 requests replayed, gap by family
⛓ Sourced · 4,000 closed requests from last year, knowledge base of 1,240 articles, permission matrix per agent
And the routing rules — do you write them? Those are our priorities, not yours.
They are yours, applied as they stand — and I add seven new ones, written in the same form and already measured on your last twelve months.
Your 22 current rules, applied to 840,000 requests: 803,000 fall under a rule; 37,000 trigger none and used to go into the general queue, where they waited 19 hours on average.
The seven rules I propose, each with what it would have given over twelve months:
· 1 — Any request naming an installation date within 72 hours goes to the priority queue. 14,200 requests concerned, average wait 19 h → 11 minutes, and 3,100 missed installations avoided according to your own cancellation reasons.
· 2 — Any complaint about a product the same customer has already complained about goes straight to an adviser. 2,900 requests, and it is the one that protects the relationship most: a second complaint handled by an automated reply is a relationship lost.
· 3 — Any request mixing two subjects is routed on the dominant subject, with a linked thread opened for the second. It settles 6,240 mis-routings over twelve months.
· The other four, smaller in volume, are set out with the same calculation.
What that gives on the delay your customers feel: routing to the right person goes from 40 % to 5 % of the time to a useful first answer — from 6 hours to 45 minutes.
The signature stays with your customer relations director: a rule comes into force only once she approves it, and that is what lets you tell a customer why his request went there rather than elsewhere. What you gain is the writing and the measurement; the decision takes twenty minutes instead of a committee.
What I propose: that the first three come into force this week and be measured for a month. If they hold their figures, the other four follow; if not, I rewrite them with the real figures of your month. routing-rules_22-in-force-7-proposed.pdf37,000 requests with no rule, 19 h down to 45 minutes
⛓ Sourced · 22 routing rules in force, 840,000 requests of the year, installation cancellation reasons
Your 22 current rules, applied to 840,000 requests: 803,000 fall under a rule; 37,000 trigger none and used to go into the general queue, where they waited 19 hours on average.
The seven rules I propose, each with what it would have given over twelve months:
· 1 — Any request naming an installation date within 72 hours goes to the priority queue. 14,200 requests concerned, average wait 19 h → 11 minutes, and 3,100 missed installations avoided according to your own cancellation reasons.
· 2 — Any complaint about a product the same customer has already complained about goes straight to an adviser. 2,900 requests, and it is the one that protects the relationship most: a second complaint handled by an automated reply is a relationship lost.
· 3 — Any request mixing two subjects is routed on the dominant subject, with a linked thread opened for the second. It settles 6,240 mis-routings over twelve months.
· The other four, smaller in volume, are set out with the same calculation.
What that gives on the delay your customers feel: routing to the right person goes from 40 % to 5 % of the time to a useful first answer — from 6 hours to 45 minutes.
The signature stays with your customer relations director: a rule comes into force only once she approves it, and that is what lets you tell a customer why his request went there rather than elsewhere. What you gain is the writing and the measurement; the decision takes twenty minutes instead of a committee.
What I propose: that the first three come into force this week and be measured for a month. If they hold their figures, the other four follow; if not, I rewrite them with the real figures of your month. routing-rules_22-in-force-7-proposed.pdf37,000 requests with no rule, 19 h down to 45 minutes
⛓ Sourced · 22 routing rules in force, 840,000 requests of the year, installation cancellation reasons
Our sore point is the hand-off. The customer repeats everything each time, and the adviser starts from scratch.
The adviser receives a finished case, not a raw conversation — and the customer repeats nothing, on any of the five channels.
An escalation is the hand-off of a request to a human adviser, when the situation calls for judgement, a gesture or a commitment.
What the adviser has in front of him the moment the call arrives:
· The full thread, in order, across every channel — Monday's chat message, Tuesday's call, this morning's email. One thread, not three cases.
· The customer record: orders in progress, delivery and installation dates announced, earlier complaints and their outcome, gestures already granted.
· What was answered to the customer, word for word, and by which agent. An adviser who does not know what has just been promised contradicts himself within thirty seconds.
· The reason for the escalation, in one line, and what was checked beforehand.
· The three items missing to decide, where there are any, with the exact question to put to the customer.
The time this shifts: picking up context goes from 30 % to 3 % of an escalation — from 7 minutes 12 to 43 seconds. Across 126,000 escalations a year, that is 13,400 hours of adviser time going back to resolution.
And the measure the customer actually feels: he used to repeat his situation 2.3 times on average; he no longer repeats it. Your first-contact resolution goes from 58 % to 81 % — first-contact resolution is the share of requests settled without the customer having to come back.
What I propose: that six advisers take twenty escalations each this week with the full thread, and tell me what was missing. Whatever they tell me about the hundred and twenty, I add to the template for the 126,000 that follow. escalation_the-full-thread-passed-on.pdf7 min 12 down to 43 seconds, 2.3 repeats to 0
⛓ Sourced · 126,000 escalations of the year, multichannel threads, context pick-up timings
An escalation is the hand-off of a request to a human adviser, when the situation calls for judgement, a gesture or a commitment.
What the adviser has in front of him the moment the call arrives:
· The full thread, in order, across every channel — Monday's chat message, Tuesday's call, this morning's email. One thread, not three cases.
· The customer record: orders in progress, delivery and installation dates announced, earlier complaints and their outcome, gestures already granted.
· What was answered to the customer, word for word, and by which agent. An adviser who does not know what has just been promised contradicts himself within thirty seconds.
· The reason for the escalation, in one line, and what was checked beforehand.
· The three items missing to decide, where there are any, with the exact question to put to the customer.
The time this shifts: picking up context goes from 30 % to 3 % of an escalation — from 7 minutes 12 to 43 seconds. Across 126,000 escalations a year, that is 13,400 hours of adviser time going back to resolution.
And the measure the customer actually feels: he used to repeat his situation 2.3 times on average; he no longer repeats it. Your first-contact resolution goes from 58 % to 81 % — first-contact resolution is the share of requests settled without the customer having to come back.
What I propose: that six advisers take twenty escalations each this week with the full thread, and tell me what was missing. Whatever they tell me about the hundred and twenty, I add to the template for the 126,000 that follow. escalation_the-full-thread-passed-on.pdf7 min 12 down to 43 seconds, 2.3 repeats to 0
⛓ Sourced · 126,000 escalations of the year, multichannel threads, context pick-up timings
And the goodwill gesture? An unhappy customer wants his credit now, not in two days.
He will have it now, within the limits you set — and the mandate that authorises it is written, capped, dated and withdrawable on a word. It is waiting for you, it runs to seven lines.
A goodwill gesture is a credit, a partial refund, free delivery or a voucher granted to close a complaint: it commits the retailer's money, so it is decided.
What the mandate covers, and I bounded it on your own decisions:
· The four reasons on which your advisers already grant systematically: delivery more than 5 days late, installation slot missed, parcel received damaged with a photo, delivery charges wrongly billed. Over the year, 41,200 gestures granted on those four reasons, and 41,200 granted out of 41,200 eligible requests.
· A cap in amount: €40 per case, above which the request goes to an adviser. That threshold covers 33,800 of the 41,200 gestures; at €60 it would cover 38,100, and I give you both figures so that you choose on numbers.
· A cap in volume: one automatic gesture per customer per quarter. The second goes through an adviser, because a customer who complains twice is asking a question that is no longer commercial.
· A date: the mandate runs three months, and renewal needs a signature — stopping does not.
· A statement every morning: the gestures granted the day before, reason by reason and amount by amount, on one page.
· Immediate withdrawal: a word from you and every gesture goes back to an adviser, within the minute, with nothing else changing.
What that earns, in figures: 33,800 complaints closed within the conversation instead of a 2-day wait, 13,100 hours of adviser time given back to the complaints that genuinely need arbitration, and an average gesture cost falling from €34 to €26 — because a credit granted on the day costs less than a credit granted after three chases.
The decision belongs to your customer relations director — and it is taken on a text that is already written, with one signature. You sign this morning, the regime starts tomorrow, and the review is set in your diary on the 15th of the third month. goodwill-gesture-mandate_capped-dated.pdf33,800 gestures, €40 cap, 3-month review
✎ Framework · drafted mandate, 41,200 gestures granted in the year, reasons and amounts recorded
A goodwill gesture is a credit, a partial refund, free delivery or a voucher granted to close a complaint: it commits the retailer's money, so it is decided.
What the mandate covers, and I bounded it on your own decisions:
· The four reasons on which your advisers already grant systematically: delivery more than 5 days late, installation slot missed, parcel received damaged with a photo, delivery charges wrongly billed. Over the year, 41,200 gestures granted on those four reasons, and 41,200 granted out of 41,200 eligible requests.
· A cap in amount: €40 per case, above which the request goes to an adviser. That threshold covers 33,800 of the 41,200 gestures; at €60 it would cover 38,100, and I give you both figures so that you choose on numbers.
· A cap in volume: one automatic gesture per customer per quarter. The second goes through an adviser, because a customer who complains twice is asking a question that is no longer commercial.
· A date: the mandate runs three months, and renewal needs a signature — stopping does not.
· A statement every morning: the gestures granted the day before, reason by reason and amount by amount, on one page.
· Immediate withdrawal: a word from you and every gesture goes back to an adviser, within the minute, with nothing else changing.
What that earns, in figures: 33,800 complaints closed within the conversation instead of a 2-day wait, 13,100 hours of adviser time given back to the complaints that genuinely need arbitration, and an average gesture cost falling from €34 to €26 — because a credit granted on the day costs less than a credit granted after three chases.
The decision belongs to your customer relations director — and it is taken on a text that is already written, with one signature. You sign this morning, the regime starts tomorrow, and the review is set in your diary on the 15th of the third month. goodwill-gesture-mandate_capped-dated.pdf33,800 gestures, €40 cap, 3-month review
✎ Framework · drafted mandate, 41,200 gestures granted in the year, reasons and amounts recorded
And if the customer wants a human straight away, no discussion?
He gets one at the next line, and he knows from the first who he is talking to.
What is said up front, on all five channels: that he is speaking to a Maisonor digital assistant, not an adviser, and that he can ask for an adviser at any time. This is not a setting you could remove: the European regulation on artificial intelligence requires that anyone interacting with an artificial intelligence system be told so, and the notice is part of the greeting, in the language of the person.
And it is good commercial news rather than a constraint: your own verbatims say so before I do. Across 3,400 reviews left after an exchange, those that opened with the notice carry an average score of 4.2 out of 5; those where the customer worked it out along the way, 2.9. What irritates a customer is not talking to a machine: it is finding out.
What happens when he asks for an adviser:
· On written channels the thread hands over immediately, with everything that came before — measured average: 40 seconds.
· On the phone the call is transferred to the site, and the adviser picks up with the case already open.
· Outside site opening hours I book the callback with the reason and three slots, and I tell the customer when he will be called. Over the quarter, 8,900 callbacks booked and 8,600 kept within the slot announced.
The figure that counts: 126,000 escalations requested or triggered in the year, 126,000 completed. Not one was held back, slowed down or redirected to a content page.
What I propose: that a request for an adviser be recognised even when it is phrased sideways — “I want someone”, “put me through to a real one”, “stop the bot”. I recorded 47 phrasings across your last twelve months, of which 11 were not recognised by your voice system: they are recognised as of this morning, and I hand you the list so that you can add to it.
What is said up front, on all five channels: that he is speaking to a Maisonor digital assistant, not an adviser, and that he can ask for an adviser at any time. This is not a setting you could remove: the European regulation on artificial intelligence requires that anyone interacting with an artificial intelligence system be told so, and the notice is part of the greeting, in the language of the person.
And it is good commercial news rather than a constraint: your own verbatims say so before I do. Across 3,400 reviews left after an exchange, those that opened with the notice carry an average score of 4.2 out of 5; those where the customer worked it out along the way, 2.9. What irritates a customer is not talking to a machine: it is finding out.
What happens when he asks for an adviser:
· On written channels the thread hands over immediately, with everything that came before — measured average: 40 seconds.
· On the phone the call is transferred to the site, and the adviser picks up with the case already open.
· Outside site opening hours I book the callback with the reason and three slots, and I tell the customer when he will be called. Over the quarter, 8,900 callbacks booked and 8,600 kept within the slot announced.
The figure that counts: 126,000 escalations requested or triggered in the year, 126,000 completed. Not one was held back, slowed down or redirected to a content page.
What I propose: that a request for an adviser be recognised even when it is phrased sideways — “I want someone”, “put me through to a real one”, “stop the bot”. I recorded 47 phrasings across your last twelve months, of which 11 were not recognised by your voice system: they are recognised as of this morning, and I hand you the list so that you can add to it.
What worries us is the peak. In late November we take five times an ordinary day's volume.
28 November has been and gone: 11,400 requests in the day against 2,300 on an ordinary one, and your priority queue stayed under 4 minutes.
What the day gave, hour by hour:
· Peak of 1,480 requests between 10 and 11 am, that is 24 a minute across the five channels.
· 9,600 requests handled by the four specialised agents, 1,800 escalated to your advisers — which is exactly the volume a site of 96 people absorbs.
· First answer on written channels: 40 seconds, held all day.
· Average telephone wait: 1 minute 10, against 14 minutes on the same day last year.
What did not move, and this is the point that decides: the “installation within 72 hours” queue, which you designated as priority, stayed under 4 minutes all day — including through the 10 am peak. A priority queue that gives way at the peak is not a priority queue: it is an intention.
And escalation, which is the second point: 1,800 situations went to advisers with their full thread, just like an ordinary day. Volume changes neither what the adviser receives, nor the fact that he receives it.
What that gave you, in figures: last year the same day produced 2,100 requests left unanswered beyond 48 hours and 640 negative public reviews. This year: 0 requests beyond 48 hours, and 71 negative reviews.
What I propose for the next peak: that we replay 28 November as a drill in September, with the real volume replayed minute by minute. The protocol is written; it lasts three hours and it runs on a Tuesday morning, outside production. peak-of-28-november_11400-requests.pdfPriority queue under 4 minutes, 0 request beyond 48 h
⛓ Sourced · request log for 28 November, timestamped queues and lead times, public reviews for the period
What the day gave, hour by hour:
· Peak of 1,480 requests between 10 and 11 am, that is 24 a minute across the five channels.
· 9,600 requests handled by the four specialised agents, 1,800 escalated to your advisers — which is exactly the volume a site of 96 people absorbs.
· First answer on written channels: 40 seconds, held all day.
· Average telephone wait: 1 minute 10, against 14 minutes on the same day last year.
What did not move, and this is the point that decides: the “installation within 72 hours” queue, which you designated as priority, stayed under 4 minutes all day — including through the 10 am peak. A priority queue that gives way at the peak is not a priority queue: it is an intention.
And escalation, which is the second point: 1,800 situations went to advisers with their full thread, just like an ordinary day. Volume changes neither what the adviser receives, nor the fact that he receives it.
What that gave you, in figures: last year the same day produced 2,100 requests left unanswered beyond 48 hours and 640 negative public reviews. This year: 0 requests beyond 48 hours, and 71 negative reviews.
What I propose for the next peak: that we replay 28 November as a drill in September, with the real volume replayed minute by minute. The protocol is written; it lasts three hours and it runs on a Tuesday morning, outside production. peak-of-28-november_11400-requests.pdfPriority queue under 4 minutes, 0 request beyond 48 h
⛓ Sourced · request log for 28 November, timestamped queues and lead times, public reviews for the period
And your service commitments? We want something contractual, not averages.
They are written, quantified and measured by the log — and the quarter's statement is attached, line by line.
A service commitment is a value written into the contract: availability, response time, restoration time — with the way it is measured and what happens if it is not met.
The four commitments, and the quarter's result:
· Availability of the system: 99.9 % over the month, measured by a check call every minute. Quarter achieved: 99.97 %, that is 13 minutes of cumulative downtime.
· Time to take charge of a blocking incident: 15 minutes, around the clock. Quarter: 3 incidents, taken in charge in 6, 9 and 4 minutes.
· Time to restore a blocking incident: 4 hours. Quarter: 41 minutes at the longest.
· Monthly statement handed over unasked, with the detail of every deviation and its cause.
What happens if a commitment is not met: the deviation is entered in the month's statement, it triggers the credit provided for in the contract, and it is presented to your committee with its cause and its correction. It is not the provider who declares the deviation: it is the log, and you have continuous access to it.
And the measure I suggest adding, because it serves you more than availability: the time to a useful first answer per queue, published every day. Availability of 99.9 % with a priority queue at 20 minutes is a contract met and a customer lost — it is the per-queue lead time that describes what your customers live.
What I propose: that the per-queue thresholds be set by your supervisors and written into the contract at the next renewal. I hand you the values observed over twelve months for each of the four queues, so that the threshold is chosen on figures rather than on an ambition. service-commitments_quarterly-statement.pdf99.97 % achieved, 3 incidents, 41 minutes at the longest
⛓ Sourced · availability log, incident register for the quarter, timestamped lead times per queue
A service commitment is a value written into the contract: availability, response time, restoration time — with the way it is measured and what happens if it is not met.
The four commitments, and the quarter's result:
· Availability of the system: 99.9 % over the month, measured by a check call every minute. Quarter achieved: 99.97 %, that is 13 minutes of cumulative downtime.
· Time to take charge of a blocking incident: 15 minutes, around the clock. Quarter: 3 incidents, taken in charge in 6, 9 and 4 minutes.
· Time to restore a blocking incident: 4 hours. Quarter: 41 minutes at the longest.
· Monthly statement handed over unasked, with the detail of every deviation and its cause.
What happens if a commitment is not met: the deviation is entered in the month's statement, it triggers the credit provided for in the contract, and it is presented to your committee with its cause and its correction. It is not the provider who declares the deviation: it is the log, and you have continuous access to it.
And the measure I suggest adding, because it serves you more than availability: the time to a useful first answer per queue, published every day. Availability of 99.9 % with a priority queue at 20 minutes is a contract met and a customer lost — it is the per-queue lead time that describes what your customers live.
What I propose: that the per-queue thresholds be set by your supervisors and written into the contract at the next renewal. I hand you the values observed over twelve months for each of the four queues, so that the threshold is chosen on figures rather than on an ambition. service-commitments_quarterly-statement.pdf99.97 % achieved, 3 incidents, 41 minutes at the longest
⛓ Sourced · availability log, incident register for the quarter, timestamped lead times per queue
And if one of the four agents goes down in the middle of a peak day?
The other three carry on, the queue of the one that went down switches to your advisers with its full thread, and you know before your customers do.
What happens in the seconds that follow:
· The supervision view shows the queue in default, and your supervisors get the alert — measured at the last drill: 22 seconds.
· That queue's requests go to the site, with the full thread, exactly like an ordinary escalation. The customer does not see an outage: he sees an adviser.
· The other three agents are unaffected: they have their own content and permissions, and that is precisely what specialisation is for.
· Requests in progress are not lost: they resume where they were, and the customer receives a line saying an adviser is continuing the exchange.
What the March drill gave: “order tracking” agent switched off for 40 minutes mid-morning, 1,240 requests moved to the site, first-answer time going from 40 seconds to 6 minutes 20, and 0 requests lost. Six minutes twenty is the time you held all day before go-live: degradation takes you back to your starting point, not below it.
What I drew from it, and it is fixed: the drill showed that 3 of the 6 supervisors did not have the alert on their phone. That has been sorted, and the second drill came in at 22 seconds against 4 minutes at the first.
What I propose: one drill per quarter, on an agent drawn at random, on a Tuesday morning. The protocol fits on one page, it lasts forty minutes, and it is better to find a silent alert on a Tuesday in March than on a 28 November.
What happens in the seconds that follow:
· The supervision view shows the queue in default, and your supervisors get the alert — measured at the last drill: 22 seconds.
· That queue's requests go to the site, with the full thread, exactly like an ordinary escalation. The customer does not see an outage: he sees an adviser.
· The other three agents are unaffected: they have their own content and permissions, and that is precisely what specialisation is for.
· Requests in progress are not lost: they resume where they were, and the customer receives a line saying an adviser is continuing the exchange.
What the March drill gave: “order tracking” agent switched off for 40 minutes mid-morning, 1,240 requests moved to the site, first-answer time going from 40 seconds to 6 minutes 20, and 0 requests lost. Six minutes twenty is the time you held all day before go-live: degradation takes you back to your starting point, not below it.
What I drew from it, and it is fixed: the drill showed that 3 of the 6 supervisors did not have the alert on their phone. That has been sorted, and the second drill came in at 22 seconds against 4 minutes at the first.
What I propose: one drill per quarter, on an agent drawn at random, on a Tuesday morning. The protocol fits on one page, it lasts forty minutes, and it is better to find a silent alert on a Tuesday in March than on a 28 November.
Our knowledge base has 1,240 articles and nobody believes in it any more. A good half must be wrong.
Not half: 214 out of 1,240 — and the 214 have been rewritten since last night, each with the source that corrected it.
The knowledge base is the retailer's set of written answers: it, and nothing else, feeds what the agents reply.
What reading the 1,240 gave:
· 214 articles contradicted by a more recent source of the retailer — return conditions changed in April, installation lead times revised in June, two spare-part references replaced. Each carries the outdated line and its replacement alongside.
· 96 articles duplicate each other, with diverging wording. That is the costliest case: two correct answers that do not say the same thing give you a customer who is right to complain.
· 340 articles were never used in twelve months. They do no harm, but they dilute: I suggest archiving them rather than maintaining them.
· And 187 questions asked more than 200 times each have no article at all. The 187 answers are drafted, sourced on your own documents, and they are waiting for you.
The rule that holds it together, and it is the one that protects you: an agent answers only from content you have approved. When the answer is not in your content, it is not invented: the request goes to an adviser with what has been checked, and the question joins the list of articles to write. Over the year, 4,900 questions took that route, and 187 became articles.
What that changed, measured: first-line answer accuracy goes from 87 % to 94 % after the 214 rewrites, and complaints about a wrong answer fall by 46 %.
What I propose: that I run the 1,240 articles against your publications, your terms and conditions and your product sheets every month, and hand you the gaps with the rewrite already done. You approve or correct a word; the base stops ageing in silence. knowledge-base_214-articles-rewritten.pdf96 duplicates, 187 missing answers drafted
⛓ Sourced · 1,240 articles of the base, current terms and conditions and product sheets, 12 months of questions asked
The knowledge base is the retailer's set of written answers: it, and nothing else, feeds what the agents reply.
What reading the 1,240 gave:
· 214 articles contradicted by a more recent source of the retailer — return conditions changed in April, installation lead times revised in June, two spare-part references replaced. Each carries the outdated line and its replacement alongside.
· 96 articles duplicate each other, with diverging wording. That is the costliest case: two correct answers that do not say the same thing give you a customer who is right to complain.
· 340 articles were never used in twelve months. They do no harm, but they dilute: I suggest archiving them rather than maintaining them.
· And 187 questions asked more than 200 times each have no article at all. The 187 answers are drafted, sourced on your own documents, and they are waiting for you.
The rule that holds it together, and it is the one that protects you: an agent answers only from content you have approved. When the answer is not in your content, it is not invented: the request goes to an adviser with what has been checked, and the question joins the list of articles to write. Over the year, 4,900 questions took that route, and 187 became articles.
What that changed, measured: first-line answer accuracy goes from 87 % to 94 % after the 214 rewrites, and complaints about a wrong answer fall by 46 %.
What I propose: that I run the 1,240 articles against your publications, your terms and conditions and your product sheets every month, and hand you the gaps with the rewrite already done. You approve or correct a word; the base stops ageing in silence. knowledge-base_214-articles-rewritten.pdf96 duplicates, 187 missing answers drafted
⛓ Sourced · 1,240 articles of the base, current terms and conditions and product sheets, 12 months of questions asked
And omnichannel? A customer starts on chat, calls the next day, then writes on social media.
It is a single thread, whatever the channel — and it is the first gain your customers mention in your reviews.
Omnichannel means the same request continues from one channel to the next without starting over: the channel changes, the case does not.
How the matching is done, and what it gives:
· On identified channels — customer account, email, order number —, the match is certain. 724,000 requests out of 840,000.
· On unidentified channels — chat without login, social media —, I ask for one linking element: order number, email or phone. One question, asked once, and the thread joins up. 108,000 requests linked that way.
· The remaining 8,000 are handled without linking: they are general questions that need no case — opening hours, product availability, payment methods. Asking for an order number to give a store's opening hours loses more customers than it serves.
What the single thread changes, measured over the year:
· The customer used to repeat his situation 2.3 times; he no longer repeats it.
· Duplicate requests — the same customer opening two threads on two channels — fall from 41,000 to 3,100. That is 37,900 handlings avoided.
· First-contact resolution goes from 58 % to 81 %.
And one thing I advise against, with the figures behind it: opening a sixth channel before the five are settled. Your 78,000 social media messages already carry 31 % of negative public reviews for 9 % of the volume — that is where a point of quality pays most, and one more channel would dilute it.
What I propose next: that the thread be visible to the customer himself, from his account. In the 6 stores where we tried it, “where is my request?” messages fell by 62 % — people chase when they do not know. omnichannel_one-thread-across-five-channels.pdf41,000 duplicates down to 3,100, 58 % → 81 %
⛓ Sourced · 840,000 requests matched by channel, duplicate thread log, public reviews by channel
Omnichannel means the same request continues from one channel to the next without starting over: the channel changes, the case does not.
How the matching is done, and what it gives:
· On identified channels — customer account, email, order number —, the match is certain. 724,000 requests out of 840,000.
· On unidentified channels — chat without login, social media —, I ask for one linking element: order number, email or phone. One question, asked once, and the thread joins up. 108,000 requests linked that way.
· The remaining 8,000 are handled without linking: they are general questions that need no case — opening hours, product availability, payment methods. Asking for an order number to give a store's opening hours loses more customers than it serves.
What the single thread changes, measured over the year:
· The customer used to repeat his situation 2.3 times; he no longer repeats it.
· Duplicate requests — the same customer opening two threads on two channels — fall from 41,000 to 3,100. That is 37,900 handlings avoided.
· First-contact resolution goes from 58 % to 81 %.
And one thing I advise against, with the figures behind it: opening a sixth channel before the five are settled. Your 78,000 social media messages already carry 31 % of negative public reviews for 9 % of the volume — that is where a point of quality pays most, and one more channel would dilute it.
What I propose next: that the thread be visible to the customer himself, from his account. In the 6 stores where we tried it, “where is my request?” messages fell by 62 % — people chase when they do not know. omnichannel_one-thread-across-five-channels.pdf41,000 duplicates down to 3,100, 58 % → 81 %
⛓ Sourced · 840,000 requests matched by channel, duplicate thread log, public reviews by channel
One last thing, and it matters: where do our customer exchanges live?
With you. I run on local inference on a machine of the retailer, and your conversations are copied nowhere.
Local inference means the model computes on your machine: the text of a customer conversation crosses no external network to be processed. If you prefer not to administer a machine, the other route is a dedicated, isolated resource hosted in France — no pooling with another retailer.
What that changes, point by point:
· No conversation trains a model, neither ours nor a third party's. What I learn from Maisonor serves Maisonor.
· Encryption in transit and at rest, keys held by the retailer.
· Role-based access — rights follow the function and the specialty: the “routine questions” agent does not see the bank details on a disputed invoice, the “technical” agent does not see the complaint history. 6 roles for your 4 agents and your 2 human profiles, and the log shows 0 out-of-role access since go-live.
· Logging per queue: who handled what, when, with which content, and why the request went there. It is that log that lets you answer a customer who asks why his request was routed as it was.
· Hosting in France, under French law, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
And the commercial argument, since that is the real question: your 840,000 annual requests contain addresses, phone numbers, order references and sometimes photographs of the inside of your customers' homes. It is the most sensitive file you hold after your payment database, and you are in a position to write in black and white that it does not leave France. Of the 3 public tenders your business answered this year, two made it a scored criterion.
What I propose: that I maintain the sheet your data protection officer asks for every year — hosting, subcontractors, data processed, retention periods, who accesses what. It used to take two days to rebuild; the first version is written and it is in front of you. technical-framework_where-your-customer-exchanges-live.pdfLocal inference, 6 roles, processing in the EU targeted
✎ Framework · deployment architecture, role matrix, per-queue log, first version of the sheet
Local inference means the model computes on your machine: the text of a customer conversation crosses no external network to be processed. If you prefer not to administer a machine, the other route is a dedicated, isolated resource hosted in France — no pooling with another retailer.
What that changes, point by point:
· No conversation trains a model, neither ours nor a third party's. What I learn from Maisonor serves Maisonor.
· Encryption in transit and at rest, keys held by the retailer.
· Role-based access — rights follow the function and the specialty: the “routine questions” agent does not see the bank details on a disputed invoice, the “technical” agent does not see the complaint history. 6 roles for your 4 agents and your 2 human profiles, and the log shows 0 out-of-role access since go-live.
· Logging per queue: who handled what, when, with which content, and why the request went there. It is that log that lets you answer a customer who asks why his request was routed as it was.
· Hosting in France, under French law, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
And the commercial argument, since that is the real question: your 840,000 annual requests contain addresses, phone numbers, order references and sometimes photographs of the inside of your customers' homes. It is the most sensitive file you hold after your payment database, and you are in a position to write in black and white that it does not leave France. Of the 3 public tenders your business answered this year, two made it a scored criterion.
What I propose: that I maintain the sheet your data protection officer asks for every year — hosting, subcontractors, data processed, retention periods, who accesses what. It used to take two days to rebuild; the first version is written and it is in front of you. technical-framework_where-your-customer-exchanges-live.pdfLocal inference, 6 roles, processing in the EU targeted
✎ Framework · deployment architecture, role matrix, per-queue log, first version of the sheet
One year. What has it given us? My executive committee will want euros, not percentages.
€3.3 million of revenue retained, and the calculation is yours: it runs to one line and you can redo it.
The calculation first: the twelve-month repurchase rate is the share of customers who order again within the following year. Among customers who filed a complaint it was 61 %; it is 68 %. Seven points on 138,000 complaints means 9,660 customers retained, and at your average annual basket of €340, €3,284,400 of revenue retained. It is the only figure in this review that shows on your income statement, and it comes from a response time, not from a discount.
The three items you were measuring:
· Handling routine requests: 65 % → 8 % of your advisers' time. Your 96 advisers handle 126,000 situations that matter instead of 840,000 requests of every kind — same headcount, different job.
· Routing to the right person: 40 % → 5 % of the time to a useful first answer — from 6 hours to 45 minutes.
· Passing context to the adviser: 30 % → 3 % of an escalation — from 7 minutes 12 to 43 seconds, that is 13,400 hours across 126,000 escalations.
The four figures I always report together: first-contact resolution 58 % → 81 %, first-answer time 14 hours → 40 seconds on written channels, negative public reviews −54 %, escalations completed 126,000 out of 126,000. None of the four reads without the other three: a service that answers in 40 seconds and resolves one time in two is not fast, it is perfunctory.
The figure that does not flatter me, published with the rest: in the first quarter, 8,610 requests out of 210,000 were routed to the wrong agent — 4.1 %.
Its cause, measured rather than assumed: 6,240 of the 8,610 mixed two subjects — a delivery delay and an assembly question in the same message — and I routed on the first sentence. The other 2,370 were phrasings with no equivalent in your twelve months of history.
What I did with it, and it is measured: a two-subject request is now routed on the dominant subject, with a linked thread opened for the second, and the customer gets both answers in the same thread. Second quarter: 1,490 mis-routings out of 214,000 — 0.7 %, and not one comes from a two-subject message any more.
What I propose for the committee: the calculation page is written and fits on one side — one revenue line, three effort lines, four indicators. Give it out with the notice of meeting: a figure read the day before is discussed better than a figure discovered in session. yearly-review_3-3-million-retained.pdf65→8, 40→5, 30→3, and 4.1 % down to 0.7 %
⛓ Sourced · 12-month repurchase rate, 840,000 requests of the year, routing log and its corrections
The calculation first: the twelve-month repurchase rate is the share of customers who order again within the following year. Among customers who filed a complaint it was 61 %; it is 68 %. Seven points on 138,000 complaints means 9,660 customers retained, and at your average annual basket of €340, €3,284,400 of revenue retained. It is the only figure in this review that shows on your income statement, and it comes from a response time, not from a discount.
The three items you were measuring:
· Handling routine requests: 65 % → 8 % of your advisers' time. Your 96 advisers handle 126,000 situations that matter instead of 840,000 requests of every kind — same headcount, different job.
· Routing to the right person: 40 % → 5 % of the time to a useful first answer — from 6 hours to 45 minutes.
· Passing context to the adviser: 30 % → 3 % of an escalation — from 7 minutes 12 to 43 seconds, that is 13,400 hours across 126,000 escalations.
The four figures I always report together: first-contact resolution 58 % → 81 %, first-answer time 14 hours → 40 seconds on written channels, negative public reviews −54 %, escalations completed 126,000 out of 126,000. None of the four reads without the other three: a service that answers in 40 seconds and resolves one time in two is not fast, it is perfunctory.
The figure that does not flatter me, published with the rest: in the first quarter, 8,610 requests out of 210,000 were routed to the wrong agent — 4.1 %.
Its cause, measured rather than assumed: 6,240 of the 8,610 mixed two subjects — a delivery delay and an assembly question in the same message — and I routed on the first sentence. The other 2,370 were phrasings with no equivalent in your twelve months of history.
What I did with it, and it is measured: a two-subject request is now routed on the dominant subject, with a linked thread opened for the second, and the customer gets both answers in the same thread. Second quarter: 1,490 mis-routings out of 214,000 — 0.7 %, and not one comes from a two-subject message any more.
What I propose for the committee: the calculation page is written and fits on one side — one revenue line, three effort lines, four indicators. Give it out with the notice of meeting: a figure read the day before is discussed better than a figure discovered in session. yearly-review_3-3-million-retained.pdf65→8, 40→5, 30→3, and 4.1 % down to 0.7 %
⛓ Sourced · 12-month repurchase rate, 840,000 requests of the year, routing log and its corrections
A director will ask what you do without being asked.
Three things, not one more, and each is withdrawn on a word. Everything else waits for a decision.
· I stop any automated chase the moment a customer replies, whatever he replies. And the reverse holds too: if the customer reopens a closed thread himself, it reopens at the same place, with all his history — a closed case is never a closed door.
· I switch a queue to the site as soon as a specialised agent stops answering, and I alert your supervisors in 22 seconds. This year: 2 switchovers, 1,240 requests concerned, 0 lost.
· I hand you the week's statement every Monday: volumes per queue, lead times, escalations, missing content. It is the only thing I send of my own accord, and it goes only to the customer relations department.
And the decisions that stay with a person, because that is exactly what gives them their value: any goodwill gesture outside the mandate is granted by an adviser; any date commitment is made by an adviser — a date commitment is not information, it is a promise that binds the retailer; every routing rule is settled by your customer relations director. Over the year, 126,000 escalations, 126,000 decisions taken by a person.
What I propose for the session: that Monday's statement go to the executive committee once a quarter, as it is. Four pages a year, no extra writing, and the committee sees the system working rather than a report written for it.
· I stop any automated chase the moment a customer replies, whatever he replies. And the reverse holds too: if the customer reopens a closed thread himself, it reopens at the same place, with all his history — a closed case is never a closed door.
· I switch a queue to the site as soon as a specialised agent stops answering, and I alert your supervisors in 22 seconds. This year: 2 switchovers, 1,240 requests concerned, 0 lost.
· I hand you the week's statement every Monday: volumes per queue, lead times, escalations, missing content. It is the only thing I send of my own accord, and it goes only to the customer relations department.
And the decisions that stay with a person, because that is exactly what gives them their value: any goodwill gesture outside the mandate is granted by an adviser; any date commitment is made by an adviser — a date commitment is not information, it is a promise that binds the retailer; every routing rule is settled by your customer relations director. Over the year, 126,000 escalations, 126,000 decisions taken by a person.
What I propose for the session: that Monday's statement go to the executive committee once a quarter, as it is. Four pages a year, no extra writing, and the committee sees the system working rather than a report written for it.
And day to day, what exactly do my six supervisors look at?
One screen, four queues, and four figures per queue — not forty.
What the supervision view shows, continuously:
· The volume waiting per queue, and how it has moved over the hour. That is the one that triggers reinforcement.
· The time to a useful first answer per queue, against the threshold your supervisors set. Above the threshold the queue turns to alert colour, and the alert goes to the on-duty supervisor's phone.
· The escalation rate per queue. A queue whose escalation rate jumps signals outdated content, not a rise in difficulty — it happened twice this year, and both times the content in question was identified within the hour.
· The oldest requests, at the top, whatever the queue. A nine-day case costs more than ten one-hour cases.
What happens when a supervisor wants to act: he changes a queue priority in one click, and the change takes effect within the minute — with his name and the time in the log, which makes it possible to reread a difficult day rather than comment on it.
What that changed for them, measured: your supervisors used to spend 11 hours a week building reports by hand, from three tools that did not count the same way. They spend 1 hour, and the other ten have gone to coaching advisers — according to your own records, +38 % of side-by-side listening time.
What I propose next: that the per-queue thresholds be reviewed every quarter against the values actually observed, and I bring you the four curves with the proposed threshold already quantified. A threshold that never moves ends up describing the ambition of two years ago rather than today's service. supervision_four-queues-four-figures.pdf11 hours a week down to 1
⛓ Sourced · supervision screen, priority change log, supervisor time records
What the supervision view shows, continuously:
· The volume waiting per queue, and how it has moved over the hour. That is the one that triggers reinforcement.
· The time to a useful first answer per queue, against the threshold your supervisors set. Above the threshold the queue turns to alert colour, and the alert goes to the on-duty supervisor's phone.
· The escalation rate per queue. A queue whose escalation rate jumps signals outdated content, not a rise in difficulty — it happened twice this year, and both times the content in question was identified within the hour.
· The oldest requests, at the top, whatever the queue. A nine-day case costs more than ten one-hour cases.
What happens when a supervisor wants to act: he changes a queue priority in one click, and the change takes effect within the minute — with his name and the time in the log, which makes it possible to reread a difficult day rather than comment on it.
What that changed for them, measured: your supervisors used to spend 11 hours a week building reports by hand, from three tools that did not count the same way. They spend 1 hour, and the other ten have gone to coaching advisers — according to your own records, +38 % of side-by-side listening time.
What I propose next: that the per-queue thresholds be reviewed every quarter against the values actually observed, and I bring you the four curves with the proposed threshold already quantified. A threshold that never moves ends up describing the ambition of two years ago rather than today's service. supervision_four-queues-four-figures.pdf11 hours a week down to 1
⛓ Sourced · supervision screen, priority change log, supervisor time records
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?
Several specialised agents, one point of supervision. All these uses work in support, subject to your approval.
Included in your agent
The 3 capabilities essential to this promise are included, at no extra cost.
From 1,007 € excl. VAT / month
Coordination of the specialised agents
Common questions, order tracking, complaints, technical: coordinating those agents under a single supervision is what this offer sells. Naming each of them is a matter of deployment architecture, settled during the project, and is not ordered here.
Routing according to your rules
Routes every request and keeps the reason it was routed that way.
Escalation preserved
Passes the full thread to the adviser, whatever the volume.
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 arbitration of conflicts and irreversible decisions
Observability of costs, timescales, quality, failures and safe stop
Resolve common requests through to a verifiable closure
Escalate quickly to a human, with the reason and the history
What the agent must be connected to
These 2 connections are required for the agent to work. They concern your information system and are scoped during the audit.
Register of authorised agents and interface contracts
Carry the full context across channels and into the ticket/CRM
Other needs our agents cover
Each card says where the matching agent stands: available, on quote, or still being architected.
Support sub-agents to be attached
Which support sub-agents are attached to this supervision — and under which interface contract — is a matter of deployment architecture, settled during the project. No list is fixed today: nothing is priced, nothing is ordered from this page.
Being architected — not orderable Talk to us about it →Need to go further?
These agents handle a different business process, with their own owner and their own price. They are added to this one.
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 many requests can an organisation absorb?
By specialising and coordinating, human effort shifts towards the situations that call for an adviser. How large the gain is depends on your volume and remains to be confirmed by a pilot.
Handling common requests
Directing to the right person
Passing the context to the adviser
Indicative figures, not contractual, to be confirmed by a pilot on the volume of requests, the number of channels and specialised agents. Goodwill gestures, commitments to a deadline and particular situations are for the adviser, who receives the full thread.
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
A multi-agent customer service system (specialisation, routing, supervision), installed and operated for you. Prices exclude VAT — annual subscription, the time it takes for the gains to settle in for good.
Agility
Setup + controlled subscription
15,380 € excl. VAT setup
then 1,007 € 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
1,862 € 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
20,490 € excl. VAT setup
then 1,284 € excl. VAT/month · + hardware from 5,500 € (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 at scale
Your customers' exchanges stay with youLocal inference or an isolated resource hosted in France; no exchange entrusted to a third party, no conversation used to train a model.
Data in France, under French lawYour customers' exchanges and data: minimisation and location in France, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
The customer relations department keeps the decisionThe agent produces omnichannel customer service at high volume, which can be checked and altered; no approval is automated.
Human oversight & traceabilityOn the volume of requests, the number of channels and specialised agents: systematic logging and tracking, in line with the AI Act.
Going further
Related resources
Frequently asked questions
Your questions, our answers
Why several agents rather than one?
Because each type of request calls for its own content and rules. Specialisation improves how accurate the answers are, and the single point of supervision keeps the whole readable.
Does escalation hold up during a spike?
Yes. Situations that call for an adviser are passed on with the full thread, independently of the volume, and the queues you have designated as priorities stay that way.
How are requests routed?
According to your routing rules, with the routing reason kept for every request.
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 — are passed on to you at cost, without margin, outside the subscription. You keep oversight from a web dashboard.
What do the service commitments cover?
Availability, response times and follow-up, contracted according to how critical the system is.
Where are the exchanges 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.
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 system?
Several months as a rule, depending on the volume, the number of channels and specialised agents, after a free audit then phases of design, integration and testing.
Let's talk
Let's size up the potential for your customer service
15 minutes to frame your volumes and your channels — hosted in France, supervised, with no commitment.