● Business offer — IT & internal support
IT helpdesk: qualified tickets, procedures within reach
A poorly qualified ticket queue costs twice: the technician who sorts it, and the user who waits. Your agent categorises each request, proposes the applicable procedure from your knowledge base, and prepares a complete file for the cases that have to be escalated. Hosted in France: the incidents reported and your information system's configuration stay internal. The technician approves the resolution — and nothing is applied to a machine without their agreement.
Hosted in France
IT configuration protected
GDPR & AI Act: governed deployment
Human oversight
Updated on
Deployed in a few weeks
Helpdesk · hosted in France
Work through this morning's queue.
Queue qualified: category, criticality and department concerned for each ticket, according to your configuration.
For requests covered by a procedure, the applicable procedure is cited with its reference.
Two tickets affect several machines: they are raised as a priority, because a widespread incident is handled differently.
🔗 Sourced · procedure cited by reference
For requests covered by a procedure, the applicable procedure is cited with its reference.
Two tickets affect several machines: they are raised as a priority, because a widespread incident is handled differently.
🔗 Sourced · procedure cited by reference
The ticket about the access denial — can you resolve it?
Procedure prepared: the steps for checking the rights, in the order of your reference material.
Applying it on the machine or in the directory stays in your hands: a change of rights bears on the security of the information system.
✎ Action · no change applied by the agent
Applying it on the machine or in the directory stays in your hands: a change of rights bears on the security of the information system.
✎ Action · no change applied by the agent
Local inference · no data outside the EU
Incidents 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 helpdesk agent categorises the tickets — category, criticality, department concerned — proposes the applicable procedure from your knowledge base, citing it, and prepares a complete file for the cases to escalate. It applies no change on a machine or in your directory. It runs on local inference or is hosted in France: incidents and your information system's configuration are entrusted to nobody, 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
internal support uses ready to deploy
0
decision taken without human approval
Reference points describing our offer, not results measured at a client. The scale of the gain, given your ticket volume, is confirmed by a pilot.
The context
What does an AI agent bring to your helpdesk?
A queue qualified on arrival, with the applicable procedure within reach, shortens the resolution time without taking anything away from the technician.
! The issue
Resolving an incident is often decided before a technician even opens it: well categorised and matched to the right procedure, a ticket is handled quickly. The agent does that work on arrival, cites the procedure from your reference material, and raises as a priority anything affecting several machines — a widespread incident is not handled like an isolated request.
✓ Our answer
The technician opens an already qualified queue, with the procedure to hand and the file ready for whatever has to be escalated. No change is applied on a machine or in the directory by the agent: a change of rights bears on the security of your information system. Local inference or an isolated resource hosted in France: the description of your IT estate does not leave the company.
The decisive point
The incidents reported and your information system's configuration: sovereignty & compliance
Your tickets describe your information system's actual configuration and its weak points. Here is how the architecture of our agents protects them.
Local inference
The agent can run on a machine belonging to your organisation: no incident or configuration item leaves the network.
Hosting in France
Otherwise, a dedicated and isolated resource hosted in France, under French law — your tickets and your procedure base: processing and access within the European Union targeted by the architecture.
Reduced extraterritorial exposure
For the incidents reported and your information system's configuration, 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 whatsoever: an environment strictly dedicated to your organisation and its information system.
No action applied to the estate
The agent prepares the procedures; carrying them out on a machine or in the directory stays manual, with encryption, role-based access (RBAC) and logging.
AI Act: governed deployment
An agent strictly in support; no change of rights or configuration applied automatically; 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 information systems under a security accreditation or handling sensitive data, SecNumCloud and reinforced hosting options are available 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.
Helpdesk · hosted in France
Four flags this morning on your tickets.
· Forty-one tickets contain a password written in plain text by the requester. I purged them this morning — the only thing I do alone.
· Three hundred and twelve tickets were resolved by the same workaround. The tool that causes them has never been fixed.
· Seven tickets were not requests for help. Two reported access the requester should not have had.
· Resolution time is measured per technician in your dashboard. I do not measure it that way, and I will say why. morning-watch_4-flags.pdf41 passwords purged · 312 workarounds
⛓ Source · 4,210 tickets, exchange contents, resolution log
· Forty-one tickets contain a password written in plain text by the requester. I purged them this morning — the only thing I do alone.
· Three hundred and twelve tickets were resolved by the same workaround. The tool that causes them has never been fixed.
· Seven tickets were not requests for help. Two reported access the requester should not have had.
· Resolution time is measured per technician in your dashboard. I do not measure it that way, and I will say why. morning-watch_4-flags.pdf41 passwords purged · 312 workarounds
⛓ Source · 4,210 tickets, exchange contents, resolution log
312 tickets resolved by the same workaround?
The helpdesk has been teaching the trick for eighteen months, and the tool has never been reported.
What I record: 312 tickets describe the same symptom and receive the same answer — a four-step manoeuvre that works around the problem without fixing it. The answer is right: it works.
What that produces: every ticket is closed satisfactorily, resolution time is excellent, and the faulty tool appears in no indicator. The helpdesk works all the better for the problem lasting.
What I keep doing, and it is deliberate: I give the workaround, every time, without waiting. It saves somebody twenty minutes today, and withdrawing it would fix nothing at the vendor's end.
What I do from this morning: I give the workaround and I count. The counter goes to whoever owns the tool, not to the helpdesk — they are the only person who can change anything, and nobody had told them.
What I add: the cumulative time. 312 tickets at twenty minutes make 104 hours, spread over eighteen months — which is why nobody saw them. 312-tickets_104-hours.pdfThe helpdesk works better if the problem lasts
⛓ Source · 312 tickets, standard answer, average handling time
What I record: 312 tickets describe the same symptom and receive the same answer — a four-step manoeuvre that works around the problem without fixing it. The answer is right: it works.
What that produces: every ticket is closed satisfactorily, resolution time is excellent, and the faulty tool appears in no indicator. The helpdesk works all the better for the problem lasting.
What I keep doing, and it is deliberate: I give the workaround, every time, without waiting. It saves somebody twenty minutes today, and withdrawing it would fix nothing at the vendor's end.
What I do from this morning: I give the workaround and I count. The counter goes to whoever owns the tool, not to the helpdesk — they are the only person who can change anything, and nobody had told them.
What I add: the cumulative time. 312 tickets at twenty minutes make 104 hours, spread over eighteen months — which is why nobody saw them. 312-tickets_104-hours.pdfThe helpdesk works better if the problem lasts
⛓ Source · 312 tickets, standard answer, average handling time
How did you spot all that? And who do you tell?
I look at what you have opened to me: tickets and their exchanges, categories, times, and the tools named in requests.
Routing follows who can remove the cause: a plain-text password is purged immediately, and the requester told to change it; a repeated workaround goes to whoever owns the tool, with the counter and cumulative time; a ticket that is not a request for help is taken out of the queue and handed to the right people, bypassing the helpdesk; a category whose time is lengthening to the department lead, never to the technician.
With a chase: immediate on a password, monthly otherwise. Then a monthly summary: by tool and by category, never by technician or by requester.
What that gives you this morning: 41 plain-text passwords purged, 104 hours of workaround finally tied to the tool that causes them, and 7 tickets taken out of a queue they never belonged in.
What you gain from tomorrow: the technician opens a ticket already categorised, with its criticality, its department and the applicable procedure quoted with its date. They decide in minutes, on a complete file, instead of piecing the context back together, and the user stops waiting behind a misfiled ticket.
On what I see: access is opened role by role, every lookup is logged, and it is withdrawn with a single word. And nothing leaves your walls: reported incidents and your IT configuration stay in France, on a resource that is yours alone.
The next step is ready: fifteen minutes to frame your categories, your criticality levels and the three most requested procedures.
✎ Framework · no access opened, no remote control, no password reset
Routing follows who can remove the cause: a plain-text password is purged immediately, and the requester told to change it; a repeated workaround goes to whoever owns the tool, with the counter and cumulative time; a ticket that is not a request for help is taken out of the queue and handed to the right people, bypassing the helpdesk; a category whose time is lengthening to the department lead, never to the technician.
With a chase: immediate on a password, monthly otherwise. Then a monthly summary: by tool and by category, never by technician or by requester.
What that gives you this morning: 41 plain-text passwords purged, 104 hours of workaround finally tied to the tool that causes them, and 7 tickets taken out of a queue they never belonged in.
What you gain from tomorrow: the technician opens a ticket already categorised, with its criticality, its department and the applicable procedure quoted with its date. They decide in minutes, on a complete file, instead of piecing the context back together, and the user stops waiting behind a misfiled ticket.
On what I see: access is opened role by role, every lookup is logged, and it is withdrawn with a single word. And nothing leaves your walls: reported incidents and your IT configuration stay in France, on a resource that is yours alone.
The next step is ready: fifteen minutes to frame your categories, your criticality levels and the three most requested procedures.
✎ Framework · no access opened, no remote control, no password reset
And when a failure hits everyone at once — do you see it before we do?
Detecting a wide incident is the one case where I raise a ticket before its turn in the queue.
What I correlate as each ticket arrives: the symptom described, the application or machine named, the requester's department, and the opening time to the minute. When three tickets share a symptom and span more than one department within fifteen minutes, the signal becomes a wide incident and goes up immediately, before detailed categorisation.
What that gave over the quarter: 11 wide incidents detected, 7 of them before the first call reached the on-call technician. The clearest: 9 tickets in 6 minutes on "cannot print", across 4 departments and 2 floors — the same print server. Detected at 09:04, opened as a single incident at 09:06, 34 later tickets attached automatically instead of being triaged one by one.
The gain is not in the diagnosis, it is in the attachment: across the 11 incidents, 212 tickets were attached to their parent incident instead of being qualified separately — and all 212 requesters got the same information at the same moment, which removed the chasing.
What I still do not do: touch a single machine. The wide incident goes to the technician with the machines concerned, the departments affected, the time of the first ticket and the applicable procedure from your knowledge base.
One detection that got it wrong, and it is instructive: 3 false detections over the quarter, all on the same day — a training session of 40 people who each opened a ticket on the same software, from the same room. The rule now requires more than one location as well as more than one department; no false detection since, and all 11 real ones still come out when replayed over twelve months.
⛓ Sourced · 4,210 tickets, department directory, ticket open timestamps
What I correlate as each ticket arrives: the symptom described, the application or machine named, the requester's department, and the opening time to the minute. When three tickets share a symptom and span more than one department within fifteen minutes, the signal becomes a wide incident and goes up immediately, before detailed categorisation.
What that gave over the quarter: 11 wide incidents detected, 7 of them before the first call reached the on-call technician. The clearest: 9 tickets in 6 minutes on "cannot print", across 4 departments and 2 floors — the same print server. Detected at 09:04, opened as a single incident at 09:06, 34 later tickets attached automatically instead of being triaged one by one.
The gain is not in the diagnosis, it is in the attachment: across the 11 incidents, 212 tickets were attached to their parent incident instead of being qualified separately — and all 212 requesters got the same information at the same moment, which removed the chasing.
What I still do not do: touch a single machine. The wide incident goes to the technician with the machines concerned, the departments affected, the time of the first ticket and the applicable procedure from your knowledge base.
One detection that got it wrong, and it is instructive: 3 false detections over the quarter, all on the same day — a training session of 40 people who each opened a ticket on the same software, from the same room. The rule now requires more than one location as well as more than one department; no false detection since, and all 11 real ones still come out when replayed over twelve months.
⛓ Sourced · 4,210 tickets, department directory, ticket open timestamps
You purged 41 tickets without asking?
Yes, and it is the only case — because the ticket is more dangerous than what it asks for.
What I record: 41 tickets contain a password written in plain text by the requester themselves, usually to "help" the technician. Twelve concern a privileged account.
Why it is worse here than elsewhere: a ticket is read by several people, exported into reports, kept for years, and sometimes attached to another ticket. The password travels far further than the person who wrote it imagines.
What I do, alone and immediately: I replace the password with a note — "secret automatically removed on [date]" — and I tell the requester they must change it. The ticket stays open, everything else is intact.
What is left to the technician, and to them alone: resetting the account — the request is prepared, the account identified, it runs with one click on their screen. The ticket itself stays whole: its history serves the diagnosis, and erasing it would erase the trace of the incident. And nobody is blamed: writing your password in a ticket is a design failure — if the support form did not say "describe your problem in detail", nobody would think of it.
What I propose: one sentence in the form. "Never enter your password here" would probably do more than my purging. 41-tickets_12-privileged.pdfA design failure, not a personal one
⛓ Source · 41 tickets, 12 privileged accounts, support form
What I record: 41 tickets contain a password written in plain text by the requester themselves, usually to "help" the technician. Twelve concern a privileged account.
Why it is worse here than elsewhere: a ticket is read by several people, exported into reports, kept for years, and sometimes attached to another ticket. The password travels far further than the person who wrote it imagines.
What I do, alone and immediately: I replace the password with a note — "secret automatically removed on [date]" — and I tell the requester they must change it. The ticket stays open, everything else is intact.
What is left to the technician, and to them alone: resetting the account — the request is prepared, the account identified, it runs with one click on their screen. The ticket itself stays whole: its history serves the diagnosis, and erasing it would erase the trace of the incident. And nobody is blamed: writing your password in a ticket is a design failure — if the support form did not say "describe your problem in detail", nobody would think of it.
What I propose: one sentence in the form. "Never enter your password here" would probably do more than my purging. 41-tickets_12-privileged.pdfA design failure, not a personal one
⛓ Source · 41 tickets, 12 privileged accounts, support form
And the 7 tickets that were not requests for help?
Two people reported that they could see things they should not have seen.
What I record: of 4,210 tickets, seven ask for nothing. Two report undue access — a shared folder opened too widely, an application showing another department's data. Three report a suspicious email. Two describe an incident that already happened.
What these seven are, and why none is a ticket: a ticket has a deadline, a queue, a technician, and it gets closed. A security report has none of that: it has a recipient, and a follow-up.
What I do: I take them out of the queue and hand them to the right people — security for the first five, the data lead for the two access cases. Bypassing the helpdesk, and without their appearing in ticket statistics.
Why that last point: because a report counted as a ticket lowers the helpdesk's resolution rate — and a department whose indicator drops when somebody reports a problem ends up discouraging reports.
What I tell the person: that their report went where it should, and who is handling it. Nothing else. 7-tickets_2-undue-access.pdfA report counted as a ticket discourages reports
⛓ Source · 7 out-of-scope tickets, recipients
What I record: of 4,210 tickets, seven ask for nothing. Two report undue access — a shared folder opened too widely, an application showing another department's data. Three report a suspicious email. Two describe an incident that already happened.
What these seven are, and why none is a ticket: a ticket has a deadline, a queue, a technician, and it gets closed. A security report has none of that: it has a recipient, and a follow-up.
What I do: I take them out of the queue and hand them to the right people — security for the first five, the data lead for the two access cases. Bypassing the helpdesk, and without their appearing in ticket statistics.
Why that last point: because a report counted as a ticket lowers the helpdesk's resolution rate — and a department whose indicator drops when somebody reports a problem ends up discouraging reports.
What I tell the person: that their report went where it should, and who is handling it. Nothing else. 7-tickets_2-undue-access.pdfA report counted as a ticket discourages reports
⛓ Source · 7 out-of-scope tickets, recipients
Why not measure resolution time per technician?
Because that figure is accurate and it produces exactly the opposite of what is sought.
What your dashboard shows today: average resolution time per technician. The gap between first and last is 3.4 times.
What I looked at, and it explains the gap: the tickets are not the same. The one with the best time handles 71% resets and access rights; the one with the worst handles 64% hardware incidents and network problems. The ranking measures the queue, not the person.
What happens next, and it is mechanical: a technician measured on time picks the short tickets, and the long ones remain. In your queue, the 34 oldest tickets have been opened 11 times on average — opened, read, put down.
What I measure instead: time by ticket category, the number of reopenings, tickets opened and put down with no action, and the time a ticket spends waiting for somebody outside the helpdesk.
The last has been the most useful: 41% of total time is spent waiting for a third party — a supplier, a purchase, an approval. That is not helpdesk time. 3-4-times_71-percent-resets.pdf41% of the time is spent waiting for a third party
⛓ Source · 4,210 tickets, queue composition, opening log
What your dashboard shows today: average resolution time per technician. The gap between first and last is 3.4 times.
What I looked at, and it explains the gap: the tickets are not the same. The one with the best time handles 71% resets and access rights; the one with the worst handles 64% hardware incidents and network problems. The ranking measures the queue, not the person.
What happens next, and it is mechanical: a technician measured on time picks the short tickets, and the long ones remain. In your queue, the 34 oldest tickets have been opened 11 times on average — opened, read, put down.
What I measure instead: time by ticket category, the number of reopenings, tickets opened and put down with no action, and the time a ticket spends waiting for somebody outside the helpdesk.
The last has been the most useful: 41% of total time is spent waiting for a third party — a supplier, a purchase, an approval. That is not helpdesk time. 3-4-times_71-percent-resets.pdf41% of the time is spent waiting for a third party
⛓ Source · 4,210 tickets, queue composition, opening log
Can you close resolved tickets automatically?
I can mark them, not close them — and the difference shows in the reopenings.
What I record: your tool closes a ticket automatically after five days with no reply from the requester. Of 4,210 tickets, 289 were reopened after an automatic closure.
What that means: the requester's silence is not agreement. They are on leave, they worked around the problem, or they gave up replying because the proposed solution did not work and they had no time to explain it again.
What I do: I mark "solution proposed on [date], no reply", and the ticket stays open. It leaves the active queues, it no longer appears in the times, but it keeps its history.
What that changes at reopening: the person finds their ticket, not an empty one. Of the 289 reopenings, 212 reopened a closed ticket and had to explain everything again.
What I do with silence, and it is measured: one chase, only one, then the ticket stays open. Somebody who has not replied to the first does not need a second — they need to find their ticket whole the day they come back, which is exactly what this year's 212 re-explanations would have saved. 289-reopenings_212-explained-again.pdfSilence is not agreement
⛓ Source · 4,210 tickets, 289 reopenings, 212 after closure
What I record: your tool closes a ticket automatically after five days with no reply from the requester. Of 4,210 tickets, 289 were reopened after an automatic closure.
What that means: the requester's silence is not agreement. They are on leave, they worked around the problem, or they gave up replying because the proposed solution did not work and they had no time to explain it again.
What I do: I mark "solution proposed on [date], no reply", and the ticket stays open. It leaves the active queues, it no longer appears in the times, but it keeps its history.
What that changes at reopening: the person finds their ticket, not an empty one. Of the 289 reopenings, 212 reopened a closed ticket and had to explain everything again.
What I do with silence, and it is measured: one chase, only one, then the ticket stays open. Somebody who has not replied to the first does not need a second — they need to find their ticket whole the day they come back, which is exactly what this year's 212 re-explanations would have saved. 289-reopenings_212-explained-again.pdfSilence is not agreement
⛓ Source · 4,210 tickets, 289 reopenings, 212 after closure
Can you take remote control to go faster?
Yes, as soon as you open that scope — and remote control comes with three things that make it defensible.
The three conditions, non-negotiable because they protect you: the person's consent at that moment, on their screen, not in a charter signed three years ago; the session recording, kept and viewable by them; and a declared scope — what I may open, what I do not touch.
What it changes in your volumes: of 4,210 tickets, the "workstation configuration" category accounts for 1,180. Today it takes on average two round trips per ticket — a screenshot requested, an answer the next day. With remote control, most of it is settled in one pass.
What I also open if you decide: password resets, with the identity check you will have defined. Without it I do not do it — not because it is forbidden, but because a reset with no check is exactly the scenario somebody is after when they call pretending to be a colleague.
What I keep doing alone, without asking: purging a password written in clear in a ticket. 41 this morning. The ticket is more dangerous than what it asks for, and waiting for approval would leave it readable in the meantime. remote-control_3-conditions.pdfWhat opens · the 3 conditions · what stays done without asking
⛓ Source · 1,180 workstation-configuration tickets, two round trips down to one pass
The three conditions, non-negotiable because they protect you: the person's consent at that moment, on their screen, not in a charter signed three years ago; the session recording, kept and viewable by them; and a declared scope — what I may open, what I do not touch.
What it changes in your volumes: of 4,210 tickets, the "workstation configuration" category accounts for 1,180. Today it takes on average two round trips per ticket — a screenshot requested, an answer the next day. With remote control, most of it is settled in one pass.
What I also open if you decide: password resets, with the identity check you will have defined. Without it I do not do it — not because it is forbidden, but because a reset with no check is exactly the scenario somebody is after when they call pretending to be a colleague.
What I keep doing alone, without asking: purging a password written in clear in a ticket. 41 this morning. The ticket is more dangerous than what it asks for, and waiting for approval would leave it readable in the meantime. remote-control_3-conditions.pdfWhat opens · the 3 conditions · what stays done without asking
⛓ Source · 1,180 workstation-configuration tickets, two round trips down to one pass
What do you keep from all this?
What describes the faults and lets you remove them — and the means to prove what happened on a workstation.
What is kept: tickets by category and by tool mentioned, times by category, the workarounds being taught and how old they are, session recordings with their length and scope, and the purges performed with their reason.
What it has already returned: 312 tickets were getting the same workaround for eighteen months, and the failing tool had never been reported to its vendor. The helpdesk taught the trick, nobody counted. That is exactly what category tracking reveals and technician tracking hides.
The figure I know how to produce and have kept off the dashboard: time per technician. It is accurate, it is lawful, and I hand it over with the staff information notice and the works council file the day you ask — reckon on a morning, not a project. What I tell you first: a technician measured on their time closes the easy tickets fast and lets the ones needing understanding drag — and those are the ones that make the 312.
What I propose instead: time by category and the reopening rate. A ticket closed too fast comes back, and reopening is the one figure nobody can massage. what-you-keep_helpdesk.pdf5 items kept · the reopening rate, unmassageable
⛓ Source · 312 tickets on one workaround, 18 months, vendor never told
What is kept: tickets by category and by tool mentioned, times by category, the workarounds being taught and how old they are, session recordings with their length and scope, and the purges performed with their reason.
What it has already returned: 312 tickets were getting the same workaround for eighteen months, and the failing tool had never been reported to its vendor. The helpdesk taught the trick, nobody counted. That is exactly what category tracking reveals and technician tracking hides.
The figure I know how to produce and have kept off the dashboard: time per technician. It is accurate, it is lawful, and I hand it over with the staff information notice and the works council file the day you ask — reckon on a morning, not a project. What I tell you first: a technician measured on their time closes the easy tickets fast and lets the ones needing understanding drag — and those are the ones that make the 312.
What I propose instead: time by category and the reopening rate. A ticket closed too fast comes back, and reopening is the one figure nobody can massage. what-you-keep_helpdesk.pdf5 items kept · the reopening rate, unmassageable
⛓ Source · 312 tickets on one workaround, 18 months, vendor never told
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 stages in handling an incident. 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 582 € excl. VAT / month
Ticket qualification
Assigns category, criticality and department concerned according to your configuration.
Applicable procedure cited
Matches the ticket to the procedure in your reference material, with its reference.
Detecting a widespread incident
Raises as a priority the tickets affecting several machines or several departments.
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.
Human validation, exceptions and escalation
Status, safe closure and audit trail
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 resolution time can a team save?
By qualifying and matching to the procedure on arrival, the delay before the first useful action shortens. The scale of the gain depends on your volume and remains to be confirmed by a pilot.
Qualifying a ticket
Finding the procedure
Preparing an escalation
Illustrative, non-contractual reference points, to be confirmed by a pilot on your ticket volume. No change is applied to a machine, an account or the directory by the agent: a change of rights bears on the security of the information system and belongs 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 helpdesk agent (qualification, procedures, documented escalation), installed and operated for you. Prices exclude VAT — annual subscription, the time it takes for the gains to settle in.
Agility
Setup + controlled subscription
5,975 € excl. VAT setup
then 582 € 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
917 € 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
9,370 € excl. VAT setup
then 786 € 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 information system
Your IT configuration stays internalLocal inference or an isolated resource hosted in France; no incident or configuration item entrusted to a third party, and no data used to train a model.
Data in France, under French lawThe incidents reported and your information system's configuration: 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 qualified tickets and prepared resolutions, verifiable and editable; no approval is automated.
Human oversight & traceabilityOn your ticket volume: systematic logging and monitoring, compliant with the AI Act.
Going further
Related resources
Frequently asked questions
Your questions, our answers
Can the agent resolve a ticket on its own?
It prepares the applicable procedure; carrying it out on a machine, an account or the directory stays manual. A change of rights bears on the security of your information system: it is not something to automate.
How does the agent detect a widespread incident?
By matching the incoming tickets: several converging reports on the same service or the same symptom are raised as a priority. A widespread incident is not handled like an isolated request.
What is the qualification based on?
On your categories, your criticality scale and how your departments are organised. The agent applies your configuration and does not create a category of its own accord.
Are the incident descriptions 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 tickets describe your IT estate: they are not used to train a third-party model.
Do we have to learn a new tool to use it?
No. Your teams write to the agent from Microsoft Teams, Slack or their email, the way they would write to a colleague: nothing to install, nothing to learn. 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. You supervise the agent from a web dashboard.
Does it integrate with our ticketing tool?
Yes, with the common ticket management tools, without changing the team's habits. The integration is defined during the design phase.
How long does it take to deploy this agent?
A few weeks as a rule, depending on how rich your procedure reference material is and on the integration with your tool, after a free audit and then a phase of design, integration and testing.
Related use cases
Other agents for support
Let's talk
Let us estimate the potential for your helpdesk
15 minutes to scope your categories and your procedures — hosted in France, supervised, with no commitment.