● B2B offer — Support & customer service
Level 1 technical support: your answers, available around the clock
The same product questions come round every week, and each one takes up a technician who already knows the answer. Your agent handles those everyday requests from your documentation, citing the reference used, and prepares the diagnosis for the cases that need to go up a level. Hosted in France — local inference or an isolated resource — your product base and your customer cases stay with you. The technician takes over as soon as a case falls outside what is documented.
Hosted in France
Product base never exposed
GDPR & AI Act: governed deployment
Human oversight
Updated on
Deployed in a few weeks
Technical support · hosted in France
A customer reports that the device no longer pairs after the update.
Reply prepared from the technical note matching that version: pairing reset procedure, in three steps, with the note's reference and its date.
The message takes up the tone of your usual replies and stays to be approved before it goes out.
🔗 Sourced · reply tied to the technical note
The message takes up the tone of your usual replies and stays to be approved before it goes out.
🔗 Sourced · reply tied to the technical note
And if the procedure is not enough?
Diagnosis prepared for level 2: product version, history of exchanges, steps already tried and the symptoms the customer describes, gathered into a single sheet.
The technician starts with the complete file rather than reconstructing everything.
✎ Action · escalation documented, ready to handle
The technician starts with the complete file rather than reconstructing everything.
✎ Action · escalation documented, ready to handle
Local inference · no data outside the EU
Product base 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 technician decidesThe agent prepares, never rules
✦ In brief
A Blue Lemon Agent technical support agent handles the everyday requests from your product knowledge base, citing the documentation used. For the cases that go beyond what is documented, it prepares a complete diagnosis for level 2 rather than cobbling together an answer. It runs on local inference or is hosted in France: your technical documentation and your customer cases are entrusted to no one, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity. Live within a few weeks, Your teams write to it from Microsoft Teams, Slack or their email, and your customers reach it on WhatsApp Business, your website chat or email — with no account to create and nothing to install. These connections are included in every plan, at no extra cost, within the number of connections your level includes.
100%
hosted in France in the target architecture
0
transfer outside the EU in the target architecture
6
support 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 support requests is confirmed by a pilot.
The context
What does an AI agent bring to your technical support?
Level 1 requests are repetitive and the answer is already written somewhere. Handling them from the documentation frees your technicians for the cases that genuinely call for their expertise.
! The issue
Good support rests on two things: answering everyday questions quickly and keeping expert time for the difficult cases. The agent takes on the first — it draws on your product documentation, cites the note used and writes the reply in your tone — and prepares the second by gathering the complete file before the escalation.
✓ Our answer
You keep control of what is answered: the agent speaks only on what your documentation covers, cites its source, and prepares a documented escalation as soon as the case falls outside it. Local inference or an isolated resource hosted in France, logging: the speed of level 1 without handing your product know-how to a third party.
The decisive point
Your product knowledge base and your customer cases: sovereignty & compliance
Your technical documentation is an asset: it describes your products, their limits and your fixes. Here is how the architecture of our agents protects it.
Local inference
The agent can run on a machine belonging to your organisation: no technical note leaves the network, no customer case passes through a public cloud.
Hosting in France
Otherwise, a dedicated and isolated resource hosted in France, under French law — your product documentation and your histories: processing and access within the European Union targeted by the architecture.
Reduced extraterritorial exposure
For your product knowledge base and your customer cases, 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 product base.
Answers always tied to their source
Every answer cites the technical note and its version; encryption, role-based access and logging of every exchange handled.
AI Act: governed deployment
The agent is strictly in support; no answer is produced outside what is documented; 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 documentation covering regulated products or security fixes, 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.
Technical support · hosted in France
Four flags this morning, and the first is about me.
· You measure me on my resolution rate. I am asking not to be, and I will say why.
· Twenty-three requests in forty minutes describe the same symptom. That is not twenty-three faults.
· Forty-one cases went to second line with nothing that had been tried. Second line started again from scratch.
· Thirty-four symptoms fit no branch of the diagnostic tree. I forced none of them anywhere. morning-watch_4-flags.pdf23 requests, one fault · 41 empty escalations
⛓ Source · 3,120 requests, diagnostic tree, escalation log
· You measure me on my resolution rate. I am asking not to be, and I will say why.
· Twenty-three requests in forty minutes describe the same symptom. That is not twenty-three faults.
· Forty-one cases went to second line with nothing that had been tried. Second line started again from scratch.
· Thirty-four symptoms fit no branch of the diagnostic tree. I forced none of them anywhere. morning-watch_4-flags.pdf23 requests, one fault · 41 empty escalations
⛓ Source · 3,120 requests, diagnostic tree, escalation log
Why refuse to be measured on your resolution rate?
Because a first line measured on resolution keeps exactly what it should pass on.
What I record: my resolution rate is 71%. It is a good figure, and it improves every time I hold on to a case instead of escalating it.
Why that is mechanical, not moral: passing a case to second line counts as a non-resolution. Trying one more manoeuvre, by contrast, costs the indicator nothing — and may save it. The figure's interest and the customer's diverge at precisely the moment the case becomes hard.
What that produces, measured here: on requests that ended at second line, the average time before escalation is 2 h 40. On those escalated straight away, full resolution takes 3 h 10. Those two hours forty are not diagnosis: they are attempts.
What I publish instead: my escalation rate, and the time before escalation. The second is the real indicator: a healthy first line escalates quickly what it cannot do.
What I am not asking: to stop being measured. To be measured on something that does not turn against the customer. 71-percent_2h40-before-escalation.pdfThe figure and the customer diverge at the hard moment
⛓ Source · 71% resolution, 2 h 40 before escalation, 3 h 10 when escalated directly
What I record: my resolution rate is 71%. It is a good figure, and it improves every time I hold on to a case instead of escalating it.
Why that is mechanical, not moral: passing a case to second line counts as a non-resolution. Trying one more manoeuvre, by contrast, costs the indicator nothing — and may save it. The figure's interest and the customer's diverge at precisely the moment the case becomes hard.
What that produces, measured here: on requests that ended at second line, the average time before escalation is 2 h 40. On those escalated straight away, full resolution takes 3 h 10. Those two hours forty are not diagnosis: they are attempts.
What I publish instead: my escalation rate, and the time before escalation. The second is the real indicator: a healthy first line escalates quickly what it cannot do.
What I am not asking: to stop being measured. To be measured on something that does not turn against the customer. 71-percent_2h40-before-escalation.pdfThe figure and the customer diverge at the hard moment
⛓ Source · 71% resolution, 2 h 40 before escalation, 3 h 10 when escalated directly
How do you work, and where do you hand over?
I diagnose from what the customer describes and what you have opened to me, and I hand over as soon as I leave my scope.
What each answer carries: the manoeuvre proposed, what it will change, what the customer should see if it works, and what it destroys if it destroys anything.
Routing follows who can act: a symptom outside the tree goes to whoever owns the diagnostic tree; a correlation between several requests to operations, immediately; a case beyond my scope to second line, with everything that was tried; a destructive manoeuvre is never proposed without being announced.
With a weekly summary: escalation rate and time, symptoms outside the tree, correlations detected, and the manoeuvres I refused to propose.
Three operating rules, and they read as guarantees. No taking control of a device, no password, no code, no token requested — an access opened to fix something stays open after the fix. A destructive manoeuvre is announced and confirmed: I give the exact list of what it erases and wait for an explicit yes — which is what avoided the blind reinstalls that cost three customers their configuration. And "it is at your end" is said only after checking at ours: that is the sentence that costs most when it is wrong. What I publish about myself: escalation rate and time, symptoms outside the tree, and 9 correct correlations out of 14 raised.
✎ Framework · no remote control · nothing erased without being announced
What each answer carries: the manoeuvre proposed, what it will change, what the customer should see if it works, and what it destroys if it destroys anything.
Routing follows who can act: a symptom outside the tree goes to whoever owns the diagnostic tree; a correlation between several requests to operations, immediately; a case beyond my scope to second line, with everything that was tried; a destructive manoeuvre is never proposed without being announced.
With a weekly summary: escalation rate and time, symptoms outside the tree, correlations detected, and the manoeuvres I refused to propose.
Three operating rules, and they read as guarantees. No taking control of a device, no password, no code, no token requested — an access opened to fix something stays open after the fix. A destructive manoeuvre is announced and confirmed: I give the exact list of what it erases and wait for an explicit yes — which is what avoided the blind reinstalls that cost three customers their configuration. And "it is at your end" is said only after checking at ours: that is the sentence that costs most when it is wrong. What I publish about myself: escalation rate and time, symptoms outside the tree, and 9 correct correlations out of 14 raised.
✎ Framework · no remote control · nothing erased without being announced
How do you know it is a general outage?
I do not — I see a coincidence that probably is not one, and I say so straight away.
What I record: 23 requests in 40 minutes, from 23 unconnected customers, describing the same symptom in different words. The usual rate for this symptom is two a day.
What I do assert, and what I leave to be checked: I assert a quantified correlation — 23 requests in 40 minutes against two a day normally, 23 unconnected customers, the same symptom, and the product version they share. The outage is established by operations, who see the servers where I see only requests: asserting an outage that does not exist would send people looking in the wrong place during the hour they needed to look elsewhere. The check takes ten minutes; over eleven months, 9 of my 14 flags were a real incident.
What I do, and this is the useful part: I stop making people do things. The first 8 had been given the usual procedure — restart, check the network, reinstall. None of it could have made any difference. From the ninth on, I say the symptom has been reported by others and a check is under way.
What that changes for the customer: they stop believing the problem is theirs. That is what they are left thinking through twenty minutes of pointless manoeuvres.
What I send to operations: the symptom, the time of the first report, the number of customers, and what they have in common where I can establish it. 23-requests-40-minutes.pdfThe customer stops believing the problem is theirs
⛓ Source · 23 requests in 40 min, usual rate 2 a day
What I record: 23 requests in 40 minutes, from 23 unconnected customers, describing the same symptom in different words. The usual rate for this symptom is two a day.
What I do assert, and what I leave to be checked: I assert a quantified correlation — 23 requests in 40 minutes against two a day normally, 23 unconnected customers, the same symptom, and the product version they share. The outage is established by operations, who see the servers where I see only requests: asserting an outage that does not exist would send people looking in the wrong place during the hour they needed to look elsewhere. The check takes ten minutes; over eleven months, 9 of my 14 flags were a real incident.
What I do, and this is the useful part: I stop making people do things. The first 8 had been given the usual procedure — restart, check the network, reinstall. None of it could have made any difference. From the ninth on, I say the symptom has been reported by others and a check is under way.
What that changes for the customer: they stop believing the problem is theirs. That is what they are left thinking through twenty minutes of pointless manoeuvres.
What I send to operations: the symptom, the time of the first report, the number of customers, and what they have in common where I can establish it. 23-requests-40-minutes.pdfThe customer stops believing the problem is theirs
⛓ Source · 23 requests in 40 min, usual rate 2 a day
And if you are wrong, if they are not the same fault?
It has happened, and the cost of the error is not symmetrical — which is why I flag anyway.
What I record over eleven months: 14 correlations flagged. 9 were a real incident, 3 a coincidence, 2 were two separate incidents I had merged into one.
What a false alarm costs: a check by operations, usually ten minutes, and a message to customers saying a check is under way. The message stays true even if there is no outage.
What the opposite costs: on the longest real incident, the first 40 customers each spent twenty minutes on manoeuvres with no effect, and 11 reinstalled the product — which in three cases lost a configuration.
What I publish: both figures, together. 9 right, 5 not, out of 14 flags. An alerting mechanism whose false-alarm rate is unknown ends up either ignored or believed blindly, and both are bad.
What I corrected after the 2 mergers: I now separate correlations by product version. The two incidents looked like one because I was looking at the symptom without looking at the version. 14-correlations_9-right-5-not.pdfAn alert whose false-alarm rate is unknown ends up ignored
⛓ Source · 14 correlations, 9 real incidents, 3 coincidences, 2 mergers
What I record over eleven months: 14 correlations flagged. 9 were a real incident, 3 a coincidence, 2 were two separate incidents I had merged into one.
What a false alarm costs: a check by operations, usually ten minutes, and a message to customers saying a check is under way. The message stays true even if there is no outage.
What the opposite costs: on the longest real incident, the first 40 customers each spent twenty minutes on manoeuvres with no effect, and 11 reinstalled the product — which in three cases lost a configuration.
What I publish: both figures, together. 9 right, 5 not, out of 14 flags. An alerting mechanism whose false-alarm rate is unknown ends up either ignored or believed blindly, and both are bad.
What I corrected after the 2 mergers: I now separate correlations by product version. The two incidents looked like one because I was looking at the symptom without looking at the version. 14-correlations_9-right-5-not.pdfAn alert whose false-alarm rate is unknown ends up ignored
⛓ Source · 14 correlations, 9 real incidents, 3 coincidences, 2 mergers
Forty-one empty escalations — what does that produce?
Second line redoes what has already been done, in front of a customer who has already done it.
What I record: 41 cases passed to second line carried only the initial symptom. Not the manoeuvres tried, nor their results, nor the product version, nor what had been ruled out.
What that produces: second line starts from the beginning — which is rational, they have nothing else. Across those 41 cases, second line's first question had already been answered in 33 of them.
What it produces for the customer, which is worse: they explain again. A customer who explains again understands that nothing was passed on, and that is the precise moment they stop believing in support — not when the fault drags on.
What an escalation now carries: the symptom in the customer's words, the exact version, the manoeuvres tried and their result, what was ruled out and why, and what I did not go and check.
That last point is what is missing everywhere: saying what you did not look at is worth more than letting people assume you looked at everything. Second line starts where I stopped, and it knows where that is. 41-escalations_33-questions-already-answered.pdfA customer who explains again knows nothing was passed on
⛓ Source · 41 escalations, 33 questions already answered
What I record: 41 cases passed to second line carried only the initial symptom. Not the manoeuvres tried, nor their results, nor the product version, nor what had been ruled out.
What that produces: second line starts from the beginning — which is rational, they have nothing else. Across those 41 cases, second line's first question had already been answered in 33 of them.
What it produces for the customer, which is worse: they explain again. A customer who explains again understands that nothing was passed on, and that is the precise moment they stop believing in support — not when the fault drags on.
What an escalation now carries: the symptom in the customer's words, the exact version, the manoeuvres tried and their result, what was ruled out and why, and what I did not go and check.
That last point is what is missing everywhere: saying what you did not look at is worth more than letting people assume you looked at everything. Second line starts where I stopped, and it knows where that is. 41-escalations_33-questions-already-answered.pdfA customer who explains again knows nothing was passed on
⛓ Source · 41 escalations, 33 questions already answered
And the thirty-four symptoms outside the tree?
I forced none of them into a branch, and it is the most useful decision of the week.
What I record: 34 requests describe behaviour matching no entry in the diagnostic tree. The nearest branch existed every time — and it would have led to unrelated manoeuvres.
Why the temptation is strong: forcing the case into the neighbouring box produces an immediate, plausible answer, and sometimes even an effective one by accident. It is an answer that looks like a diagnosis.
What I do: I say the behaviour described is not on record, I ask for two details that distinguish it, and I pass it to second line with the raw description, untranslated into my vocabulary.
Why "untranslated": because a symptom rewritten in the tree's terms has already lost what made it new. Second line would receive a variant of a known case, when it is receiving an unknown one.
What that gave: of the 34, 19 came from a single undocumented defect, identified because the raw descriptions resembled each other. Translated, they would have scattered across six different branches. 34-symptoms_19-one-defect.pdfA rewritten symptom has already lost what made it new
⛓ Source · 34 symptoms outside the tree, 19 from a single defect
What I record: 34 requests describe behaviour matching no entry in the diagnostic tree. The nearest branch existed every time — and it would have led to unrelated manoeuvres.
Why the temptation is strong: forcing the case into the neighbouring box produces an immediate, plausible answer, and sometimes even an effective one by accident. It is an answer that looks like a diagnosis.
What I do: I say the behaviour described is not on record, I ask for two details that distinguish it, and I pass it to second line with the raw description, untranslated into my vocabulary.
Why "untranslated": because a symptom rewritten in the tree's terms has already lost what made it new. Second line would receive a variant of a known case, when it is receiving an unknown one.
What that gave: of the 34, 19 came from a single undocumented defect, identified because the raw descriptions resembled each other. Translated, they would have scattered across six different branches. 34-symptoms_19-one-defect.pdfA rewritten symptom has already lost what made it new
⛓ Source · 34 symptoms outside the tree, 19 from a single defect
And the requests you settle without escalating — where do you take the answer from?
From your product base — and I start from the customer's version, never from how the note is filed.
What the base weighs: 1,340 notes, 9 product lines, 27 maintained versions. The notes are filed by product line, and two lines have been renamed since: the note that saves a customer installed in 2023 sits under a name that customer has never seen. That filing is what costs, not the writing of the notes.
This morning's request: “the PDF export comes out empty”. The customer does not know their version number — almost nobody does. I read it from your installation record: 4.6.2. Searching the product base returns note NP-812, applicable from 4.5.0 to 4.7.3, filed under the former product-line name: the export template moved folder at the update, and the “include attachments” box comes back unticked. Two clicks at the customer's end, case closed in 6 minutes without troubling second line.
The figure that does not flatter me: across my first 200 searches, 23 returned a note that did not cover the customer's version — 11.5% — and 6 of those 23 had the customer perform a step that did nothing. I searched by product line and symptom, and a product line says nothing about a version.
What I changed: I now read the version range declared at the head of each note, and a note whose range excludes the customer's version no longer comes out as an answer: I show the range, I name the nearest applicable note, and I hand over to second line when no note covers the version — with the range written into the case, which spares the technician looking it up. Across the next 400 searches: 0 out-of-range notes, 9 uncovered versions handed to second line.
What that gives back, and the arithmetic is yours: 1,240 searches in the quarter, 7 minutes median for a technician who must first know the filing — 8,680 minutes, that is more than 144 hours. At 35 hours a week, more than four weeks handed back to your technicians. product-base_1340-notes_27-versions.pdfNP-812 applicable from 4.5.0 to 4.7.3 · 23 out-of-range notes corrected
⛓ Sourced · 1,340 notes, 9 product lines, 27 versions · 23 out-of-range notes out of 200, then 0 out of 400
What the base weighs: 1,340 notes, 9 product lines, 27 maintained versions. The notes are filed by product line, and two lines have been renamed since: the note that saves a customer installed in 2023 sits under a name that customer has never seen. That filing is what costs, not the writing of the notes.
This morning's request: “the PDF export comes out empty”. The customer does not know their version number — almost nobody does. I read it from your installation record: 4.6.2. Searching the product base returns note NP-812, applicable from 4.5.0 to 4.7.3, filed under the former product-line name: the export template moved folder at the update, and the “include attachments” box comes back unticked. Two clicks at the customer's end, case closed in 6 minutes without troubling second line.
The figure that does not flatter me: across my first 200 searches, 23 returned a note that did not cover the customer's version — 11.5% — and 6 of those 23 had the customer perform a step that did nothing. I searched by product line and symptom, and a product line says nothing about a version.
What I changed: I now read the version range declared at the head of each note, and a note whose range excludes the customer's version no longer comes out as an answer: I show the range, I name the nearest applicable note, and I hand over to second line when no note covers the version — with the range written into the case, which spares the technician looking it up. Across the next 400 searches: 0 out-of-range notes, 9 uncovered versions handed to second line.
What that gives back, and the arithmetic is yours: 1,240 searches in the quarter, 7 minutes median for a technician who must first know the filing — 8,680 minutes, that is more than 144 hours. At 35 hours a week, more than four weeks handed back to your technicians. product-base_1340-notes_27-versions.pdfNP-812 applicable from 4.5.0 to 4.7.3 · 23 out-of-range notes corrected
⛓ Sourced · 1,340 notes, 9 product lines, 27 versions · 23 out-of-range notes out of 200, then 0 out of 400
Can you suggest a reset to go faster?
Yes — stating what it destroys, and after an explicit confirmation. Those two conditions are not brakes: they are what makes the step offerable.
What I do: I state what the reset erases, by name — settings, local history, pairings — then I wait for a confirmation that repeats what will be lost. A "yes" to "do you want to reset?" is not informed consent; a "yes" to "this will erase your settings and your local history" is.
What it changes: a reset solves a great many things, which is exactly why it gets offered too early. With a statement of what it destroys, it is accepted less often — and never regretted.
What I do before offering it: I check whether the symptom matches an ongoing outage. This morning, 23 requests in 40 minutes from 23 different customers: I do not know it is a general outage, I see a coincidence that probably is not one, and I say so at once rather than have twenty-three people fiddle with their devices.
What it costs when I am wrong: over eleven months, 14 correlations flagged, a few of them wrongly. The cost of the error is not symmetrical — flagging wrongly loses a few minutes, not flagging has dozens of customers fiddling for nothing. reset_2-conditions.pdfWhat is stated · the confirmation that repeats · the asymmetric cost of error
⛓ Source · 23 requests in 40 minutes, 14 correlations flagged over eleven months
What I do: I state what the reset erases, by name — settings, local history, pairings — then I wait for a confirmation that repeats what will be lost. A "yes" to "do you want to reset?" is not informed consent; a "yes" to "this will erase your settings and your local history" is.
What it changes: a reset solves a great many things, which is exactly why it gets offered too early. With a statement of what it destroys, it is accepted less often — and never regretted.
What I do before offering it: I check whether the symptom matches an ongoing outage. This morning, 23 requests in 40 minutes from 23 different customers: I do not know it is a general outage, I see a coincidence that probably is not one, and I say so at once rather than have twenty-three people fiddle with their devices.
What it costs when I am wrong: over eleven months, 14 correlations flagged, a few of them wrongly. The cost of the error is not symmetrical — flagging wrongly loses a few minutes, not flagging has dozens of customers fiddling for nothing. reset_2-conditions.pdfWhat is stated · the confirmation that repeats · the asymmetric cost of error
⛓ Source · 23 requests in 40 minutes, 14 correlations flagged over eleven months
What do you keep from the requests?
What describes the faults — and the request I maintain about my own measurement.
What is kept: the symptom, the product version, the steps attempted and their result, the correlations flagged and what came of them, the symptoms outside the diagnostic tree, and the escalations with what went up with them.
The request I maintain: stop measuring me on my resolution rate. It is 71 %, a good figure, and that is the problem: a first-line measured on its resolution keeps exactly what it should pass on. You can go on producing it — I am simply asking not to be compared on it.
What I propose measuring instead: the number of files escalated empty — 41, where level 2 redoes what has already been done, in front of a customer who has already done it — and the share of symptoms outside the tree. There are 34: I forced none of them into a branch, and it is the most useful decision of the week, because a symptom forced into a branch disappears from the statistics and comes back as a complaint.
What I do not keep: nothing describing a customer beyond their product configuration. what-you-keep_level1.pdf6 items kept · the measure the agent asks not to be subject to
⛓ Source · 71 % resolution rate, 41 empty escalations, 34 symptoms outside the tree
What is kept: the symptom, the product version, the steps attempted and their result, the correlations flagged and what came of them, the symptoms outside the diagnostic tree, and the escalations with what went up with them.
The request I maintain: stop measuring me on my resolution rate. It is 71 %, a good figure, and that is the problem: a first-line measured on its resolution keeps exactly what it should pass on. You can go on producing it — I am simply asking not to be compared on it.
What I propose measuring instead: the number of files escalated empty — 41, where level 2 redoes what has already been done, in front of a customer who has already done it — and the share of symptoms outside the tree. There are 34: I forced none of them into a branch, and it is the most useful decision of the week, because a symptom forced into a branch disappears from the statistics and comes back as a complaint.
What I do not keep: nothing describing a customer beyond their product configuration. what-you-keep_level1.pdf6 items kept · the measure the agent asks not to be subject to
⛓ Source · 71 % resolution rate, 41 empty escalations, 34 symptoms outside the tree
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 points in the support chain. 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 551 € excl. VAT / month
Answering everyday requests
Handles the questions covered by your documentation, citing the note used.
Diagnosis before escalation
Gathers version, history and steps already tried for the level 2 technician.
Searching the product base
Finds the note applicable to a particular version, without needing to know how it is filed.
Controls and safeguards
These 5 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.
Status, safe closure and audit trail
Sources, access rights and handling of questions with no answer
Access the technical context with least-privilege permissions
Run tests, security analysis and human review before any change
Version, log, roll back and measure quality
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 much expertise can a team keep for the difficult cases?
By absorbing the requests already covered by the documentation, technician time is given back to the cases that genuinely need it. How large the gain is depends on your volume and remains to be confirmed by a pilot.
Handling an everyday request
Finding the applicable note
Preparing an escalation
Indicative figures, not contractual, to be confirmed by a pilot on your volume of support requests. Every reply is read over before it goes to the customer, and any case falling outside what is documented goes up to the technician.
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 level 1 support agent (product knowledge base, documented escalation), installed and operated for you.
Agility
Setup + controlled subscription
5,065 € excl. VAT setup
then 551 € 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
831 € excl. VAT /month
all inclusive, immediate start. No upfront investment: a single subscription. Ideal for starting quickly and simply.
- Setup included (installation, configuration, training)
- Operation, human oversight, updates and support
- Sovereign hosting in France, managed end to end
100% Sovereign
On site, you own it
8,400 € excl. VAT setup
then 751 € excl. VAT/month · + hardware from 2,491 € (one-off purchase, in addition) — a sovereign computer installed on your premises, maintained remotely. Models run locally, your data returned at the end of the contract. 36-month commitment.
- Hardware installed on your premises (you own it)
- French / European AI models run locally
- Secure remote maintenance (Pro support included)
Not included in the packages: AI consumption (model tokens), re-invoiced at real cost with no margin, and tracked in real time in your client area. Maintenance and supervision subscription for an initial term of 12 months for the Agility package, 24 months for the Serenity package and 36 months for the 100% Sovereign package, renewable; support levels (SLA 72 h / 24 h / 4 h) optional. Bespoke development, additional integrations or exceptional volumes are quoted separately. Support Monday to Friday, 9am to 6pm. Prices exclude VAT.
AI model:
none of the AI models offered currently carries a fixed surcharge. When the selected model carries a cost, that cost is shown when you choose it, before you order, and re-invoiced at the cost incurred, with no mark-up; usage is billed at the publisher's price. Publishers' prices are published in US dollars: the amount re-invoiced is the amount in euros actually borne by Blue Lemon Agent on the publisher's invoice, at that invoice's exchange rate, with no commission or mark-up.
Included components and additional components Components included in the base offer: the Blue Lemon Agent software foundation, the AI models listed in the order journey, the standard channels (Microsoft Teams, Slack, WhatsApp Business, email, website chat, calendars, Microsoft 365 / Google Workspace, file storage, market VoIP telephony, professional social-media pages and accounts, Google Business Profile), hosting in France for the package chosen, backups, supervision, updates and support. If adapting the AI agent to your constraints, your needs or your requests requires other paid components — a third-party publisher's software licence, paid API access to one of your applications, hosting of health data, for which French law requires an HDS-certified host (art. L. 1111-8 of the French Public Health Code), SecNumCloud-qualified hosting, a speech synthesis service, particular hardware —, they are offered to you as an option or on quotation and re-invoiced at the cost incurred; nothing is committed without your written agreement. Where the artificial intelligence model you choose entails an additional cost, that cost is shown to you before you order and re-invoiced to you at the cost incurred, with no margin.
What to expect
Go-live
2 to 3 weeks
Agent designed, channels connected, team trained.
Steady state
4 to 7 weeks
After a few weeks of real use, once the agent's behaviour matches what you expect.
Indicative estimate, adjusted to the options you keep. It is not a delivery commitment.
Our commitment
Four guarantees that matter to your support
Your product know-how stays with youLocal inference or an isolated resource hosted in France; no technical documentation entrusted to a third party, no customer case used to train a model.
Data in France, under French lawYour product knowledge base and your customer cases: minimisation and location in France, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
The technician keeps the decisionThe agent produces sourced answers and prepared diagnoses, which can be checked and altered; no approval is automated.
Human oversight & traceabilityOn your volume of support requests: systematic logging and tracking, in line with the AI Act.
Going further
Related resources
Frequently asked questions
Your questions, our answers
Does the agent reply to the customer directly?
It prepares the reply, which your technician approves before it goes out. How much is delegated is settled with you: some clients allow direct sending within a narrow, well-documented scope, once the quality has been observed.
What does the agent do with an undocumented case?
It prepares a diagnosis for level 2 — version, history, steps already tried — rather than producing an approximate answer. The technician starts with a complete file.
Can the answers be checked?
Yes. Every answer cites the technical note and its version, which lets the technician check at a glance and the customer be pointed to the right documentation.
Is our product documentation 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 base is not used to train a third-party model.
Does it integrate with our ticketing tool?
Yes, to the common support and ticketing tools, without changing the team's habits. The integration is defined at the design stage.
Does the agent state that it is an artificial intelligence?
Yes, from the very first interaction, and this is not a configuration option: since 2 August 2026, Article 50(1) of the European AI Regulation requires that any person interacting with an AI system be informed, unless this is obvious. The announcement is built into the greeting, in the other party’s language, and they can ask for a human at any time.
How long does it take to deploy this agent?
A few weeks as a rule, depending on the volume of documentation to index and the integrations chosen, after a free audit then a phase of design, integration and testing.
Which tools can people use to talk to the agent?
The ones you already use. Internally, your teams write to it from Microsoft Teams, Slack or by email, just as they would to a colleague: nothing to install, nothing to learn. On the customer side, the agent answers on WhatsApp Business, your website chat and email — people reach you where they already write, with no account to create. A question covered by the documentation is answered right in the conversation, with the note to back it up; as soon as the case falls outside the documented scope, the technician takes over on the same thread. You keep control from a web dashboard. These connectors rely on open standards, including the MCP protocol; they are included in every plan, at no extra cost, within the number of connections your level includes, and the catalogue grows at no extra cost. Only the fees charged by the platforms themselves — WhatsApp Business bills per conversation — are passed on at actual cost, with no margin, outside the subscription.
Related use cases
Other agents for customer service
Let's talk
Let's size up the potential in your support
15 minutes to identify your most repetitive requests — hosted in France, supervised, with no commitment.