● B2B offer — Organisation & flows
Sorting and routing agent: the right request to the right department
A misrouted request goes round the organisation twice before reaching the right place. Your agent reads the incoming request, classifies it under your categories and proposes the department to handle it, explaining what it is going on. Hosted in France — local inference or an isolated resource — the content of the requests stays with you. The allocation stays changeable: the receiving department keeps control.
Hosted in France
Requests handled internally
GDPR & AI Act: governed deployment
Human oversight
Updated on
Deployed in a few weeks
Sorting and routing · hosted in France
Handle the requests that came in since yesterday evening.
Requests classified under your categories: sales, technical, administrative, complaint.
For each, the department proposed and the element of the message I am going on.
Four requests fall under more than one category: I flag them without deciding.
✎ Action · allocation proposed, changeable
For each, the department proposed and the element of the message I am going on.
Four requests fall under more than one category: I flag them without deciding.
✎ Action · allocation proposed, changeable
The ones straddling two departments — what do you propose?
Nothing. They mention both a technical problem and a sales request; choosing arbitrarily would waste both departments' time.
I pass them up with both possible readings, for you to decide.
✎ Support · ambiguity raised, not resolved at random
I pass them up with both possible readings, for you to decide.
✎ Support · ambiguity raised, not resolved at random
Local inference · no data outside the EU
Flows 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 receiving department decidesThe agent prepares, never rules
✦ In brief
A Blue Lemon Agent sorting and routing agent reads incoming requests, classifies them under your categories and proposes the department to handle them, stating what element it is going on. Ambiguous requests are raised rather than allocated at random. It runs on local inference or is hosted in France: the content of your clients' and partners' requests does not leave your premises, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity. Live within a few weeks,.
100%
hosted in France in the target architecture
0
transfer outside the EU in the target architecture
6
routing 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 incoming requests is confirmed by a pilot.
The context
What does an AI agent bring to your incoming request flows?
Every rerouting adds a delay and another reading. But a mistaken automatic allocation sends the request into a queue where nobody is expecting it.
! The issue
A misrouted request travels from department to department, each one reading it again before passing it on — the delay grows without anyone making progress. Yet a badly designed automatic routing sends the request into a queue where it sits, and entrusting the content of your clients' and partners' requests to a third-party service exposes it to the Cloud Act.
✓ Our answer
Assisted routing is only of interest if it is sovereign and explainable. Local inference or an isolated resource hosted in France, an allocation justified by an element of the message, ambiguous cases raised: the receiving department sees what the allocation rests on and can correct it in one move. The agent directs; it does not lock anything in.
The decisive point
The content of the requests that reach you: sovereignty & compliance
The requests that reach you contain complaints, client data and sometimes sensitive information. Here is how the architecture of our agents protects them.
Local inference
The agent can run on a machine belonging to your organisation: no request leaves the network, no attachment passes through a public cloud.
Hosting in France
Otherwise, a dedicated and isolated resource hosted in France, under French law — the requests received and their attachments: processing and access within the European Union targeted by the architecture.
Reduced extraterritorial exposure
For the content of the requests that reach you, 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 organisation and its allocation rules.
Allocation rules under your control
You define the categories and the receiving departments; every allocation is justified, logged and changeable at any time.
AI Act: governed deployment
The agent is strictly in support; no request is locked into a queue with no way to correct it; 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.
- The events logged, their content, their retention period and who may access them are defined for the deployment chosen.
For requests containing health data or sensitive reports, 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.
Sorting and routing · hosted in France
Four flags this morning on the request routing.
· Forty-one requests made two round trips between departments. They took eleven days longer than the others.
· Seven requests marked urgent went out on Friday to a mailbox checked on Monday.
· The "other" category has tripled in six months: 312 requests, against 104.
· My unclassified rate is 8%. I am not trying to lower it, and I will tell you why. morning-watch_4-flags.pdf41 requests, eleven days longer
⛓ Source · 3,940 requests, routing log, mailbox checking times
· Forty-one requests made two round trips between departments. They took eleven days longer than the others.
· Seven requests marked urgent went out on Friday to a mailbox checked on Monday.
· The "other" category has tripled in six months: 312 requests, against 104.
· My unclassified rate is 8%. I am not trying to lower it, and I will tell you why. morning-watch_4-flags.pdf41 requests, eleven days longer
⛓ Source · 3,940 requests, routing log, mailbox checking times
An 8% unclassified rate — is that not a failure?
It is what stops the other 92% from being wrong, and it is the one thing I will defend on this page.
What I could do: classify 100% of requests. Technically, it is enough to pick the most likely category when I do not know.
What would happen: the requests I do not understand would go out anyway, to a department that is not expecting them. They would come back — that is exactly where this morning's 41 round trips come from — but their clock would have been running.
What I do instead: when I do not recognise a request, I put it in a visible queue, with what I understood and what is missing. A person routes it in fifteen seconds.
What that gives, measured: 315 unclassified of 3,940, routed by hand in under two hours on average. Against eleven days for a misrouted request.
What I will always refuse: being asked to bring that rate down. A sorter that classifies everything is not wrong less often: it is wrong in silence. 315-unclassified_2-hours.pdf2 hours against 11 days
⛓ Source · 3,940 requests, 315 unclassified, times compared
What I could do: classify 100% of requests. Technically, it is enough to pick the most likely category when I do not know.
What would happen: the requests I do not understand would go out anyway, to a department that is not expecting them. They would come back — that is exactly where this morning's 41 round trips come from — but their clock would have been running.
What I do instead: when I do not recognise a request, I put it in a visible queue, with what I understood and what is missing. A person routes it in fifteen seconds.
What that gives, measured: 315 unclassified of 3,940, routed by hand in under two hours on average. Against eleven days for a misrouted request.
What I will always refuse: being asked to bring that rate down. A sorter that classifies everything is not wrong less often: it is wrong in silence. 315-unclassified_2-hours.pdf2 hours against 11 days
⛓ Source · 3,940 requests, 315 unclassified, times compared
How did you spot all that? And who do you tell?
I look at what you have opened to me: incoming requests, which department each went to, what became of it, and your mailbox checking times.
Routing follows whose time is lost: a request coming back a second time does not go out again — I queue it and tell the process owner; an urgent request sent to an unchecked mailbox to the sending department, within the hour; a swelling category to whoever defines the categories, monthly; a request I do not recognise into the visible queue, with no guessed recipient.
With a chase: within the hour on a misdirected urgency, 7 days otherwise. Then a monthly summary: by category and by delay, never by department or by handler.
What that gives you over the month: 3,625 requests classified and forwarded without intervention, 315 routed by hand in under two hours, and not one left of the 41 requests that cost eleven days by going twice around the house.
What you gain from tomorrow: eleven days handed back on every stray request, seven urgent items that no longer go to a mailbox opened on Monday, and a receiving department that gets the request with its category, the part of the message behind it and its history. It keeps control, and it takes over in fifteen seconds when I get it wrong.
On what I see: I read the requests you open to me, nothing else; access is opened by role, logged and withdrawn with a single word, and the content of your exchanges leaves neither your walls nor France.
The next step is ready: fifteen minutes to map your categories, your departments and the times your mailboxes are opened.
✎ Framework · no guessed category, no request closed, no urgency changed
Routing follows whose time is lost: a request coming back a second time does not go out again — I queue it and tell the process owner; an urgent request sent to an unchecked mailbox to the sending department, within the hour; a swelling category to whoever defines the categories, monthly; a request I do not recognise into the visible queue, with no guessed recipient.
With a chase: within the hour on a misdirected urgency, 7 days otherwise. Then a monthly summary: by category and by delay, never by department or by handler.
What that gives you over the month: 3,625 requests classified and forwarded without intervention, 315 routed by hand in under two hours, and not one left of the 41 requests that cost eleven days by going twice around the house.
What you gain from tomorrow: eleven days handed back on every stray request, seven urgent items that no longer go to a mailbox opened on Monday, and a receiving department that gets the request with its category, the part of the message behind it and its history. It keeps control, and it takes over in fifteen seconds when I get it wrong.
On what I see: I read the requests you open to me, nothing else; access is opened by role, logged and withdrawn with a single word, and the content of your exchanges leaves neither your walls nor France.
The next step is ready: fifteen minutes to map your categories, your departments and the times your mailboxes are opened.
✎ Framework · no guessed category, no request closed, no urgency changed
The 41 requests that made two round trips?
Each hand-back looks justified, and the sum of them does not.
What I record: 41 requests routed to a department, sent back, routed to another, sent back again. Average time: 19 days, against 8 for the others.
What that figure points at, and it is not a department: each hand-back taken alone is defensible — the department judges it is not their scope, and they are often right. What is missing is a third instance, and that is exactly what I put in place below.
What I do from this morning: a request coming back a second time does not go out again. I stop it, put it in the visible queue with the history of both passes, and tell the process owner. It is the only thing I block.
Why block rather than route a third time: because a third routing has a one-in-two chance of being right, and the request has already waited. A two-minute human decision beats a bet.
What I supply: both departments involved, the reason for each hand-back as it was written, and the time already consumed. 41-requests_19-days-against-8.pdfA request coming back twice does not go out again
⛓ Source · 41 requests, hand-back log, times compared
What I record: 41 requests routed to a department, sent back, routed to another, sent back again. Average time: 19 days, against 8 for the others.
What that figure points at, and it is not a department: each hand-back taken alone is defensible — the department judges it is not their scope, and they are often right. What is missing is a third instance, and that is exactly what I put in place below.
What I do from this morning: a request coming back a second time does not go out again. I stop it, put it in the visible queue with the history of both passes, and tell the process owner. It is the only thing I block.
Why block rather than route a third time: because a third routing has a one-in-two chance of being right, and the request has already waited. A two-minute human decision beats a bet.
What I supply: both departments involved, the reason for each hand-back as it was written, and the time already consumed. 41-requests_19-days-against-8.pdfA request coming back twice does not go out again
⛓ Source · 41 requests, hand-back log, times compared
And the "other" category that tripled?
It no longer says anything, and that is a symptom, not negligence.
What I record: 312 requests classified "other" this half-year, against 104 six months earlier. It has become the third category in the process.
What I looked at: what they contain. Of the 312, 187 group into four subjects that did not exist in your scheme six months ago — two new offers, a regulatory change, and a type of complaint that appeared after a change to your terms.
What that means: "other" is not a category, it is an indicator. When it swells, it is not that requests are becoming obscure: it is that the scheme has aged.
What I have written, and what is left to settle: the four categories are drafted — label, definition, and the routing rule that goes with each. Adopting them is settled between departments: a category decides who receives what, and therefore who works — that is settled around a table, not in a sorting tool.
What I supply: the four subjects, their volume, and one sample request for each, to whoever defines the scheme. Four new categories would take "other" from 312 down to 125. 312-others_4-subjects.pdf"Other" is an indicator, not a category
⛓ Source · 312 "other" requests, grouping by subject, current scheme
What I record: 312 requests classified "other" this half-year, against 104 six months earlier. It has become the third category in the process.
What I looked at: what they contain. Of the 312, 187 group into four subjects that did not exist in your scheme six months ago — two new offers, a regulatory change, and a type of complaint that appeared after a change to your terms.
What that means: "other" is not a category, it is an indicator. When it swells, it is not that requests are becoming obscure: it is that the scheme has aged.
What I have written, and what is left to settle: the four categories are drafted — label, definition, and the routing rule that goes with each. Adopting them is settled between departments: a category decides who receives what, and therefore who works — that is settled around a table, not in a sorting tool.
What I supply: the four subjects, their volume, and one sample request for each, to whoever defines the scheme. Four new categories would take "other" from 312 down to 125. 312-others_4-subjects.pdf"Other" is an indicator, not a category
⛓ Source · 312 "other" requests, grouping by subject, current scheme
And the ones that could go to two departments at once?
They come up as ambiguous cases, and that is the mechanism that ended the ping-pong.
What an ambiguous case is here: a request that meets the criteria of two or more categories, with nothing in the text to separate them. That is not the same as unclassified: an unclassified request resembles nothing, an ambiguous one resembles two things.
Across the quarter's 3,400 requests: 8% unclassified — the 272 we discussed — and 141 ambiguous cases, or 4.1%. Their commonest pairings:
· 62 between billing and contracts — "I am being billed for something my contract does not cover" belongs to both, and whichever department gets it alone sends it back;
· 39 between technical and sales — a fault on an option that may never have been taken out;
· 24 between HR and payroll;
· 16 carrying two distinct requests in one message. Those I split, proposing two routings and saying so.
What the supervisor receives: the two possible departments, the parts of the text that argue for each, and the request's history where there is one. They decide in a minute. The chosen routing is recorded as a proposed rule: when the same pairing comes back ten times with the same decision, I propose making it a rule — 4 rules proposed this quarter, 3 adopted.
What it returned: of the 41 requests that made two round trips, 34 belonged to those ambiguous pairings. Over the following quarter, 6 round trips instead of 41, and the 11 days lost on average fell to 1 day 4 hours.
And the principle does not move: picking at random between two departments removes the ambiguity from the screen, not from the circuit. A sorter that classifies everything is not wrong less often, it is wrong in silence.
✎ Framework · ambiguous cases raised — two possible recipients, neither chosen
What an ambiguous case is here: a request that meets the criteria of two or more categories, with nothing in the text to separate them. That is not the same as unclassified: an unclassified request resembles nothing, an ambiguous one resembles two things.
Across the quarter's 3,400 requests: 8% unclassified — the 272 we discussed — and 141 ambiguous cases, or 4.1%. Their commonest pairings:
· 62 between billing and contracts — "I am being billed for something my contract does not cover" belongs to both, and whichever department gets it alone sends it back;
· 39 between technical and sales — a fault on an option that may never have been taken out;
· 24 between HR and payroll;
· 16 carrying two distinct requests in one message. Those I split, proposing two routings and saying so.
What the supervisor receives: the two possible departments, the parts of the text that argue for each, and the request's history where there is one. They decide in a minute. The chosen routing is recorded as a proposed rule: when the same pairing comes back ten times with the same decision, I propose making it a rule — 4 rules proposed this quarter, 3 adopted.
What it returned: of the 41 requests that made two round trips, 34 belonged to those ambiguous pairings. Over the following quarter, 6 round trips instead of 41, and the 11 days lost on average fell to 1 day 4 hours.
And the principle does not move: picking at random between two departments removes the ambiguity from the screen, not from the circuit. A sorter that classifies everything is not wrong less often, it is wrong in silence.
✎ Framework · ambiguous cases raised — two possible recipients, neither chosen
The 7 urgent requests sent to a mailbox checked on Monday?
They were routed correctly. It was the timing that was not.
What I record: seven requests marked urgent went out on Friday after 4 p.m. to a department whose mailbox is checked on Monday morning. The routing was right; the outcome was not.
Where they go anyway, and why: to the department that owns them. Routing a request to a department that does not own it because they check their mailbox more often means trading a good destination for a bad one — and the request would come straight back.
And the urgency level I take as it stands: it was set by whoever wrote, or by the rule you gave me. A sorter that corrects urgencies teaches people to overstate them, and the level then stops meaning anything at all.
What I do: I route normally, and I tell the sending department within the hour — "this urgent request will only be read on Monday; if it cannot wait, here is the department's direct contact."
What I propose, and it is the real fix: that each department declare its checking times, and that I display them at the moment of routing. Of eleven departments, four have not declared them — so I can announce nothing about those. 7-urgent_4-departments-without-times.pdfThe routing was right, the timing was not
⛓ Source · 7 requests, checking times declared by 7 departments of 11
What I record: seven requests marked urgent went out on Friday after 4 p.m. to a department whose mailbox is checked on Monday morning. The routing was right; the outcome was not.
Where they go anyway, and why: to the department that owns them. Routing a request to a department that does not own it because they check their mailbox more often means trading a good destination for a bad one — and the request would come straight back.
And the urgency level I take as it stands: it was set by whoever wrote, or by the rule you gave me. A sorter that corrects urgencies teaches people to overstate them, and the level then stops meaning anything at all.
What I do: I route normally, and I tell the sending department within the hour — "this urgent request will only be read on Monday; if it cannot wait, here is the department's direct contact."
What I propose, and it is the real fix: that each department declare its checking times, and that I display them at the moment of routing. Of eleven departments, four have not declared them — so I can announce nothing about those. 7-urgent_4-departments-without-times.pdfThe routing was right, the timing was not
⛓ Source · 7 requests, checking times declared by 7 departments of 11
Can you close a request once handled?
No, and it is the most useful refusal on this page.
What I could do: notice a reply went out and close the request. It would empty the queue and the dashboard would look good.
Why I do not: because I do not know whether the reply answers. A closed request is a request that drops out of the chasing — and if the reply missed the point, nobody will ever know.
What I do: I mark "reply sent on [date]", and the request stays open until a person closes it, or the requester confirms.
What that produces, and it is uncomfortable: 412 requests carry "reply sent" without having been closed. Of those 412, 38 received a further message from the requester — meaning the reply had not been enough.
Those 38 are the whole argument: had I closed them, they would have come back as new requests, without their history, and the process would have started from zero. 412-open_38-follow-ups.pdf38 replies that had not been enough
⛓ Source · 412 requests with a reply sent, 38 requester follow-ups
What I could do: notice a reply went out and close the request. It would empty the queue and the dashboard would look good.
Why I do not: because I do not know whether the reply answers. A closed request is a request that drops out of the chasing — and if the reply missed the point, nobody will ever know.
What I do: I mark "reply sent on [date]", and the request stays open until a person closes it, or the requester confirms.
What that produces, and it is uncomfortable: 412 requests carry "reply sent" without having been closed. Of those 412, 38 received a further message from the requester — meaning the reply had not been enough.
Those 38 are the whole argument: had I closed them, they would have come back as new requests, without their history, and the process would have started from zero. 412-open_38-follow-ups.pdf38 replies that had not been enough
⛓ Source · 412 requests with a reply sent, 38 requester follow-ups
Can you tell us which department is fastest?
Yes, and I can even give it to you without the effect that makes that figure dangerous — provided it is measured differently.
What I produce if you ask: average handling time per department, requests received, requests sent back. It is lawful, and I supply the information notice and works council file if you go down to the individual level.
The effect to know: a department compared on its handling time sends back faster anything not obviously its own. That is exactly what produces your 41 requests that made two round trips between departments — eleven days lost each, every send-back looking justified.
The measure I propose instead, answering the same question: the request's end-to-end time, from lodging to the answer reaching the requester, attributed to the chain and not to the last link. A fast send-back does not improve it — it worsens it, because it adds a leg.
What it changes immediately: the 41 round trips stop being invisible, and the "other" category — up from 104 to 312 requests in six months — appears for what it is: a symptom of the circuit, not sloppy sorting.
Both are available. You can have both. end-to-end-time.pdfWhat opens · the effect of per-department time · the measure that cannot be gamed
⛓ Source · 41 round trips at eleven days, "other" category from 104 to 312
What I produce if you ask: average handling time per department, requests received, requests sent back. It is lawful, and I supply the information notice and works council file if you go down to the individual level.
The effect to know: a department compared on its handling time sends back faster anything not obviously its own. That is exactly what produces your 41 requests that made two round trips between departments — eleven days lost each, every send-back looking justified.
The measure I propose instead, answering the same question: the request's end-to-end time, from lodging to the answer reaching the requester, attributed to the chain and not to the last link. A fast send-back does not improve it — it worsens it, because it adds a leg.
What it changes immediately: the 41 round trips stop being invisible, and the "other" category — up from 104 to 312 requests in six months — appears for what it is: a symptom of the circuit, not sloppy sorting.
Both are available. You can have both. end-to-end-time.pdfWhat opens · the effect of per-department time · the measure that cannot be gamed
⛓ Source · 41 round trips at eleven days, "other" category from 104 to 312
What do you keep from all this?
Each request's full path — it is the path that explains a delay, not the department holding it at the end.
What is kept: the request and its category, with the reason for the classification, the successive departments it passed through and the time at each step, the send-backs with their reason, the collection times of the destination mailboxes, and the unclassified requests.
Why I keep 8 % unclassified rather than forcing: I could classify 100 % of requests. What is certain is that the rate would be 100 % — not that it would be right. The 8 % unclassified are what stops the 92 % being wrong, and it is the one thing I will defend without reservation on this page.
What the collection times caught: 7 requests marked urgent sent on a Friday after 4 pm to a department collected on Monday. They were routed correctly: it was the timing that was not. I now divert them to the on-call route, and flag it.
What I still do not do: close a request because an answer went out. That would empty the queue and give an excellent figure — and an answer sent is not a request handled. Closing belongs to whoever handled it, or to the requester. what-you-keep_routing.pdf5 items kept · the 8 % that stop the 92 % being wrong
⛓ Source · 8 % unclassified by design, 7 urgent requests to a Monday-collected mailbox
What is kept: the request and its category, with the reason for the classification, the successive departments it passed through and the time at each step, the send-backs with their reason, the collection times of the destination mailboxes, and the unclassified requests.
Why I keep 8 % unclassified rather than forcing: I could classify 100 % of requests. What is certain is that the rate would be 100 % — not that it would be right. The 8 % unclassified are what stops the 92 % being wrong, and it is the one thing I will defend without reservation on this page.
What the collection times caught: 7 requests marked urgent sent on a Friday after 4 pm to a department collected on Monday. They were routed correctly: it was the timing that was not. I now divert them to the on-call route, and flag it.
What I still do not do: close a request because an answer went out. That would empty the queue and give an excellent figure — and an answer sent is not a request handled. Closing belongs to whoever handled it, or to the requester. what-you-keep_routing.pdf5 items kept · the 8 % that stop the 92 % being wrong
⛓ Source · 8 % unclassified by design, 7 urgent requests to a Monday-collected mailbox
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 entry points into your flows. 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 469 € excl. VAT / month
Classification by category
Puts each request into your business categories, without creating new ones.
Proposing the receiving department
Suggests the team responsible and states the element of the message behind that choice.
Raising ambiguous cases
Flags the requests that fall under more than one department instead of deciding at random.
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
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.
Tier-2 customer support agent (diagnosis)
Once routed, technical diagnosis and resolution are the level-2 support agent's job.
Tier-2 customer support agent (diagnosis) from 574 € excl. VAT / month Discover the agent →Omnichannel customer relations agent
Holding the conversation across every channel, and its history, belongs to the omnichannel customer agent.
Omnichannel customer relations agent from 680 € excl. VAT / month Discover the agent →
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 reroutings can an organisation avoid?
By proposing the right department on arrival, the back-and-forth between teams and the delay before the first reply both come down. How large the gain is depends on your volume and remains to be confirmed by a pilot.
First reading and routing
Successive reroutings
Classification for tracking
Qualitative, non-contractual comparison: the proportions shown illustrate the shift of the work towards review, they represent no measurement. Every output of the agent is reviewed and approved by a competent person.
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 sorting and routing agent (classification, reasoned allocation), installed and operated for you.
Agility
Setup + controlled subscription
3,360 € excl. VAT setup
then 469 € 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
654 € 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
6,555 € excl. VAT setup
then 669 € excl. VAT/month · + hardware from 1,058 € (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 incoming flows
The requests received do not leave the companyLocal inference or an isolated resource hosted in France; no message from a client or a partner entrusted to a third party, no content used to train a model.
Data in France, under French lawThe content of the requests that reach you: minimisation and location in France, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
The receiving department keeps the decisionThe agent produces a classification and a proposed allocation, which can be checked and altered; no approval is automated.
Human oversight & traceabilityOn your volume of incoming enquiries: systematic logging and tracking, in line with the AI Act.
Going further
Related resources
Frequently asked questions
Your questions, our answers
Is the proposed allocation final?
No. The receiving department can correct it in one move, and the correction is recorded. The agent directs to save time; it never locks a request into a queue.
What does the agent base its choice on?
On your categories and your allocation rules, and it states the element of the message behind the proposal. An allocation that could not be explained would be unusable: explainability is part of what is delivered.
What does the agent do with a request straddling two departments?
It raises it, flagging both possible readings, without choosing. Deciding at random would waste both teams' time; a human decision is quicker.
Is the content of the requests 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 clients' messages are not used to train a third-party model.
Does it connect to our request management tools?
Yes. Requests come in from your customers' channels — WhatsApp Business, your website chat, email — and go out to your teams in Microsoft Teams, Slack or their email, as well as into the common ticketing tools, without changing anyone's habits. 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. The integration is defined at the design stage.
How long does it take to deploy this agent?
A few weeks as a rule, depending on the number of categories and departments involved, after a free audit then a phase of design, integration and testing.
Related use cases
Other agents for your flows and your client relations
Let's talk
Let's size up the potential in your incoming enquiries
15 minutes to map your categories and your departments — hosted in France, supervised, with no commitment.