● Public sector — IT support (level 1 helpdesk)
The AI agent for IT support: take on level 1, free up the technicians
Everyday incidents — access, printing, business applications — swamp the helpdesk and tie up technicians whose expertise would be more useful elsewhere. Your AI agent takes on level 1 support: it guides resolution, qualifies and routes tickets, and applies your internal procedures. Hosted in France — on local inference or an isolated resource — the knowledge base and the incident data stay under control. The AI agent assists, the public official decides.
Hosted in France
An isolated knowledge base
GDPR & AI Act: governed deployment
Human oversight
Updated on
Deployed in a few weeks
Level 1 helpdesk assistant · hosted in France
An official in the registry office has been unable to reach the business application since this morning. What do I tell them?
Incident identified: 3 similar reports since 8am on the same application — most likely an expired session renewal after last night's update. Internal procedure: full sign-out, clear the cache, then sign back in through the single sign-on portal.
If access does not come back, this is an incident to route to level 2 — I am preparing the qualified ticket.
⛓ Source · the internal knowledge base + the open tickets
If access does not come back, this is an incident to route to level 2 — I am preparing the qualified ticket.
⛓ Source · the internal knowledge base + the open tickets
The procedure did not work for them. Escalate the ticket.
Ticket escalated to level 2, high priority (a blocking business application, several officials affected). I have attached the workstation, the timestamps, the 3 related reports and the steps already tried. Category: access / single sign-on authentication.
The level 2 technician receives a complete file — the next step is theirs to decide.
✎ Action · qualified ticket ready — the public official approves the escalation
The level 2 technician receives a complete file — the next step is theirs to decide.
✎ Action · qualified ticket ready — the public official approves the escalation
Local inference · no data outside the EU
Data 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 public officer decidesThe AI agent assists, never rules alone
✦ In brief
In a local authority, a government department or a public body, a Blue Lemon Agent agent takes on level 1 IT support: it guides the resolution of everyday incidents (access, printing, applications), qualifies, prioritises and routes tickets to the right level, and circulates the internal procedures and good practice. It runs on local inference or is hosted in France: the knowledge base and the incident data are never exposed to a foreign service, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity. The technicians' time is redirected to the subjects that add value. Live within a few weeks. Your staff write to it from Microsoft Teams, Slack or their email — nothing to install, nothing to learn. 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
8
uses ready to deploy on this scope
0
decision taken without human approval
Reference points describing our offer, not results measured at a client. The scale of the gain is confirmed by a pilot on your own scope.
The context
Why AI matters to public-sector IT departments — and why they hesitate
Public officials expect responsive support to stay productive in serving the public. But the helpdesk is swamped by repetitive incidents, and both the incident data and the internal knowledge base touch on the organisation and the security of the information system.
! The issue
The IT department is caught between officials who expect their incidents resolved immediately and a support team whose time is absorbed by repetitive level 1 work — at the expense of projects and of security. Yet most consumer AI tools amount to entrusting the map of the information system, accounts, internal procedures and incident data to a third party, often hosted outside Europe and subject to the Cloud Act.
✓ Our answer
For a public service, AI is only of interest if it is sovereign and confidential by design. Local inference or an isolated resource hosted in France, systematic human oversight, the decision reserved for the public official: time gained on level 1 is never paid for in lost sovereignty. The aim is not to replace the IT team, but to give it back time for the subjects that add value and for continuity of service.
The decisive point
Keeping control of information-system data: sovereignty & compliance
A helpdesk handles sensitive information about the organisation and the security of the information system. Here is how the architecture of our agents protects it, organisation by organisation.
Local inference
The agent can run on a machine belonging to the organisation: no incident data leaves the network, nothing passes through a cloud.
Hosting in France
Otherwise, a dedicated and isolated resource, hosted in France under French law — your data: processing and access within the European Union targeted by the architecture.
Reduced extraterritorial exposure
Exposure of information-system data to the Cloud Act and FISA 702 is reduced by design; location alone does not guarantee immunity.
A knowledge base isolated per organisation
No pooling: a knowledge base and an environment strictly dedicated to your authority or body.
Encryption & controlled access
Encryption in transit and at rest, role-based access (RBAC), strong authentication and logging.
AI Act: governed deployment
The agent is strictly in support; no escalation or resolution approved 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.
- The encryption mechanisms in transit and at rest, their components and key management are those documented for the architecture chosen.
- 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 the most sensitive data, SecNumCloud and HDS 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
5 real situations, taken from those that come up most often. Pick one: the exchange unfolds as it would in your organisation.
A scripted demonstration. These exchanges show how the agent behaves — its sources, its refusals, what it leaves to your teams. Nothing is sent from this page, no model is queried here, and the matters named are fictional. That is precisely what we promise your data.
The behaviours shown here — monitoring, automation rules, routing and reminders — are configured with you during deployment, from your tools, your rules and your thresholds.
The architecture points named in these exchanges — location, local execution, isolation, encryption, role-based access, logging — are not a guarantee attached to the demonstration: they are those of the architecture set out in your quotation, and verified before commissioning.
The public body in this demonstration
Fictional public bodyVal-d'Arcy urban community — shared IT department for 23 municipalities
- Sector
- Fictional authority — shared information systems department: workstations, business applications (civil status, finance, human resources, planning), schools, libraries and the technical centre of the 23 member municipalities
- Headcount
- 1,240 staff equipped; an IT department of 11 people including 4 on the helpdesk — 2 level 1 technicians and 2 level 2, the helpdesk being open from 8.30 a.m. to 5.30 p.m.
- Public served
- 1,240 staff across 38 sites, who themselves serve 96,000 residents — one member of staff blocked in the morning means a public counter that does not open
- Order of magnitude
- 6,400 tickets a year of which 3,900 are level 1, 2,600 calls to the helpdesk, 640 on-site interventions, 74 staff arrivals and 9 internal forms in the information system
- Tools in place
- Ticketing tool, staff directory, asset manager, single sign-on portal and a 9-year documentation base — 740 sheets; the agent plugs into them read-only, nothing is replaced and nothing is migrated
- Who decides
- The helpdesk manager approves every go-live; the information systems security officer rules on anything touching rights and access; the level 2 technician settles every escalation
- Room for improvement
- 700 calls a year arrive outside helpdesk opening hours — 27 %; a ticket waits 3 h 40 before it is first picked up; 41 % of level 1 tickets land in the wrong queue on first routing; and across the 74 staff arrivals of the year, one access in five was still missing on the first day
At Val-d'Arcy, four people run support for 1,240 staff across 38 sites. Everyday incidents — access, printing, business applications — take up most of the team's time while projects and information system security wait. The agent runs on local inference on a machine of the IT department, reads the 9 years of tickets and the 740 sheets of the documentation base without ever writing to them, and closes no ticket outside the regime the helpdesk manager has signed. The exchanges that follow span one year, from the overhaul of the documentation base to the review presented to the chief executive.
This public body, its figures and the exchanges that follow were invented for the demonstration. They illustrate a common situation; they describe no real service.
Level 1 helpdesk assistant · hosted in France
I read your nine years of tickets over the weekend — 41,200 tickets, 740 sheets from your documentation base — and I draw from them a finding your logs carried without anyone ever having the time to see it.
Level 1 is the first floor of support: the everyday incidents that are settled without an expert — access, printing, a business application that no longer opens.
The measured gap, and it commands everything else: of the 6,400 tickets of last year, 3,900 are level 1 — 61 %, and twelve causes alone account for 2,650 of them, that is 68 % of level 1. Session expired after an update, blocked print queue, single sign-on password, mail profile to rebuild, network drive not mounted: the twelve fit on one page, and your four technicians handle them 2,650 times a year.
What that costs today, on the three items you can check in your ticketing tool: a level 1 ticket takes 20 minutes here, from report to closure.
· Triage and routing weigh 60 % of that time — 12 minutes spent working out who is calling, on which workstation, with which application, and into which queue the ticket should go.
· Guided resolution of a common incident: 30 %, that is 6 minutes.
· An answer to a recurring question from a member of staff: 12 %, that is 2 minutes 24.
What I propose, and it is not a promise — it is already written: each of the twelve causes now has its up-to-date resolution sheet, drafted last night from your own resolved tickets, with the step-by-step your technicians actually use rather than the one a vendor manual recommends. What it would have changed over the past year, since that is the only measure that counts: the 2,650 tickets of those twelve causes would have left with the right procedure at the first exchange.
What becomes of the three items once the sheets are settled: 60 % → 18 %, 30 % → 10 %, 12 % → 8 % — 3 minutes 36, 2 minutes, 1 minute 36. The rest is the technician's judgement, and it cannot be delegated.
The next step, and it takes half an hour: your helpdesk manager reads the three heaviest sheets, I present them to him tomorrow morning. He settles the version, and it is live the same evening — it is his approval that makes the sheet binding on the technician who will apply it, and it is the only act I leave to him. ticket-analysis_12-causes-for-68-percent.pdf41,200 tickets read, 12 causes, 2,650 tickets a year
⛓ Sourced · 9 years of the authority's tickets, documentation base of 740 sheets, 12 resolution sheets rewritten
Level 1 is the first floor of support: the everyday incidents that are settled without an expert — access, printing, a business application that no longer opens.
The measured gap, and it commands everything else: of the 6,400 tickets of last year, 3,900 are level 1 — 61 %, and twelve causes alone account for 2,650 of them, that is 68 % of level 1. Session expired after an update, blocked print queue, single sign-on password, mail profile to rebuild, network drive not mounted: the twelve fit on one page, and your four technicians handle them 2,650 times a year.
What that costs today, on the three items you can check in your ticketing tool: a level 1 ticket takes 20 minutes here, from report to closure.
· Triage and routing weigh 60 % of that time — 12 minutes spent working out who is calling, on which workstation, with which application, and into which queue the ticket should go.
· Guided resolution of a common incident: 30 %, that is 6 minutes.
· An answer to a recurring question from a member of staff: 12 %, that is 2 minutes 24.
What I propose, and it is not a promise — it is already written: each of the twelve causes now has its up-to-date resolution sheet, drafted last night from your own resolved tickets, with the step-by-step your technicians actually use rather than the one a vendor manual recommends. What it would have changed over the past year, since that is the only measure that counts: the 2,650 tickets of those twelve causes would have left with the right procedure at the first exchange.
What becomes of the three items once the sheets are settled: 60 % → 18 %, 30 % → 10 %, 12 % → 8 % — 3 minutes 36, 2 minutes, 1 minute 36. The rest is the technician's judgement, and it cannot be delegated.
The next step, and it takes half an hour: your helpdesk manager reads the three heaviest sheets, I present them to him tomorrow morning. He settles the version, and it is live the same evening — it is his approval that makes the sheet binding on the technician who will apply it, and it is the only act I leave to him. ticket-analysis_12-causes-for-68-percent.pdf41,200 tickets read, 12 causes, 2,650 tickets a year
⛓ Sourced · 9 years of the authority's tickets, documentation base of 740 sheets, 12 resolution sheets rewritten
Our documentation base holds 740 sheets and nobody has time to maintain it. Some of it must be wrong since the single sign-on migration.
96 sheets out of 740 describe a system that no longer exists, I have identified them and the 96 up-to-date versions are written.
What the comparison between your sheets and your actual configuration says:
· 62 sheets point to the old sign-on portal, the one the migration replaced eleven months ago — screens, button labels and login address have all changed. A member of staff following those 62 sheets cannot succeed.
· 21 sheets describe printers withdrawn from the estate — the estate is the set of workstations, printers and telephones the IT department manages and inventories.
· 13 sheets carry an internal contact who has changed department.
What those 96 sheets have cost, measured on your tickets and not assumed: they are cited in 430 tickets of the year, and 118 of those 430 led to a second call from the same person within 48 hours. It was not a shortfall of skill, it was documentation that had aged while nobody had time to reopen it.
What I do on top, and nobody has the time to do: I rewrite each sheet from the configuration in force and from tickets actually resolved, and I set the replaced line and the replacing line side by side — your technician validates at a glance instead of rereading a page. Of the 96, 74 can be approved in under a minute each; the other 22 carry a choice of procedure that is yours to make, and for each I propose the two possible wordings with the number of tickets each would have covered.
The next step I propose: that from now on, any sheet that a configuration change makes wrong be rewritten the night that follows that change, and reach you in the morning summary. Your 740 sheets will stop ageing in silence — it is the only way this work will not have to be redone in two years, and it will cost you no more than one reading per change. documentation-base_740-sheets-96-reworked.pdf96 outdated sheets, 96 up-to-date versions, 430 tickets involved
⛓ Sourced · documentation base of 740 sheets, estate inventory, sign-on migration log, tickets citing a sheet
What the comparison between your sheets and your actual configuration says:
· 62 sheets point to the old sign-on portal, the one the migration replaced eleven months ago — screens, button labels and login address have all changed. A member of staff following those 62 sheets cannot succeed.
· 21 sheets describe printers withdrawn from the estate — the estate is the set of workstations, printers and telephones the IT department manages and inventories.
· 13 sheets carry an internal contact who has changed department.
What those 96 sheets have cost, measured on your tickets and not assumed: they are cited in 430 tickets of the year, and 118 of those 430 led to a second call from the same person within 48 hours. It was not a shortfall of skill, it was documentation that had aged while nobody had time to reopen it.
What I do on top, and nobody has the time to do: I rewrite each sheet from the configuration in force and from tickets actually resolved, and I set the replaced line and the replacing line side by side — your technician validates at a glance instead of rereading a page. Of the 96, 74 can be approved in under a minute each; the other 22 carry a choice of procedure that is yours to make, and for each I propose the two possible wordings with the number of tickets each would have covered.
The next step I propose: that from now on, any sheet that a configuration change makes wrong be rewritten the night that follows that change, and reach you in the morning summary. Your 740 sheets will stop ageing in silence — it is the only way this work will not have to be redone in two years, and it will cost you no more than one reading per change. documentation-base_740-sheets-96-reworked.pdf96 outdated sheets, 96 up-to-date versions, 430 tickets involved
⛓ Sourced · documentation base of 740 sheets, estate inventory, sign-on migration log, tickets citing a sheet
All this assumes you read our tickets, our directory and the map of our information system. Where does that data go?
It goes nowhere. I run on local inference on a machine of the IT department, and nothing I read leaves the authority's network.
Local inference means the model computes on your machine: the text of a ticket, the name of a server or the list of one person's rights never cross an outside network to be processed. If the IT department would rather not host a machine, the other route is an isolated resource hosted in France, dedicated to Val-d'Arcy — no pooling with another authority, your knowledge base lives in an environment that is yours alone.
What that changes, point by point:
· Your tickets and your system map train no model, neither ours nor a third party's.
· I work read-only on the ticketing tool, the directory and the asset manager, and the technical account through which I read has no write permission — that is sturdier than a promise, because your security officer checks it with one command.
· Encryption in transit and at rest, strong authentication, and role-based access — rights follow the job: a level 1 technician opens the tickets of their queue, not the table of privileged accounts. 7 roles for your 11 people, and the log shows 0 out-of-role access since go-live.
· Hosting in France, under French law, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
· Logging: who asked what, when, which sheet grounded the answer and what the system produced.
One thing I do in no circumstances, and it is not caution on my part: inferring a member of staff's emotional state from the tone of their tickets or their voice on the phone. The European regulation on artificial intelligence flatly prohibits inferring people's emotions in the workplace, and it is one of the few truly firm bans in that text. What is permitted and renders the same service, I have already built: load by queue and by cause, hour by hour — it is what showed you the 700 out-of-hours calls, and no individual is named in it.
The figure that sums all this up: 0 information system data left the authority's network across the 6,400 tickets of the year, and processing in the EU targeted.
What I propose: that I maintain the record your chief executive and your data protection officer will ask for — hosting, data processed, retention periods, who accesses what. It is requested once a year and takes two days to rebuild; the first version is already written and attached. technical-framework_where-your-it-data-lives.pdfLocal inference, read-only, processing in the EU targeted
✎ Framework · deployment architecture, technical account permissions, matrix of the 7 roles, first version of the register record
Local inference means the model computes on your machine: the text of a ticket, the name of a server or the list of one person's rights never cross an outside network to be processed. If the IT department would rather not host a machine, the other route is an isolated resource hosted in France, dedicated to Val-d'Arcy — no pooling with another authority, your knowledge base lives in an environment that is yours alone.
What that changes, point by point:
· Your tickets and your system map train no model, neither ours nor a third party's.
· I work read-only on the ticketing tool, the directory and the asset manager, and the technical account through which I read has no write permission — that is sturdier than a promise, because your security officer checks it with one command.
· Encryption in transit and at rest, strong authentication, and role-based access — rights follow the job: a level 1 technician opens the tickets of their queue, not the table of privileged accounts. 7 roles for your 11 people, and the log shows 0 out-of-role access since go-live.
· Hosting in France, under French law, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
· Logging: who asked what, when, which sheet grounded the answer and what the system produced.
One thing I do in no circumstances, and it is not caution on my part: inferring a member of staff's emotional state from the tone of their tickets or their voice on the phone. The European regulation on artificial intelligence flatly prohibits inferring people's emotions in the workplace, and it is one of the few truly firm bans in that text. What is permitted and renders the same service, I have already built: load by queue and by cause, hour by hour — it is what showed you the 700 out-of-hours calls, and no individual is named in it.
The figure that sums all this up: 0 information system data left the authority's network across the 6,400 tickets of the year, and processing in the EU targeted.
What I propose: that I maintain the record your chief executive and your data protection officer will ask for — hosting, data processed, retention periods, who accesses what. It is requested once a year and takes two days to rebuild; the first version is already written and attached. technical-framework_where-your-it-data-lives.pdfLocal inference, read-only, processing in the EU targeted
✎ Framework · deployment architecture, technical account permissions, matrix of the 7 roles, first version of the register record
This morning, an officer in the civil status department can no longer reach her business application. That is the cause we see most. What does she get from you?
She has her answer in 40 seconds, with the internal sheet that grounds it and its date — and I can tell you right now that three other people in the same department are about to call.
What I hand her, in this order:
· The immediate correlation: 3 reports on the same application since 8.05 a.m., all on workstations that received last night's update. It is not her workstation, it is the sign-on session that was not renewed after the update — and that is cause number 2 of your twelve.
· The step-by-step from your internal sheet, the one your manager approved last week: full sign-out from the single sign-on portal, clearing of the workstation cache, sign back in. Three steps, screen by screen, with the exact labels of your current portal — not those from before the migration.
· The sheet used and its update date, right under the answer. A member of staff who sees where the instruction comes from applies it; an instruction without an origin gets re-argued on the phone.
What I do without being asked: I pushed the same answer to the 3 other people who had reported the incident, and I drafted the notice to the 34 staff of the civil status department — it is waiting in your drafts, it goes out with one click. Across the 9 grouped incidents of last year, the average was 17 calls for the same problem: the notice, sent within the hour, would have spared 14 of them.
The time this moves: guided resolution of a common incident goes from 30 % to 10 % of the ticket's time — from 6 minutes to 2. Across 2,650 tickets a year falling under the twelve causes, that is 177 technician hours going back to projects and to information system security.
The next step I propose: that the three most frequent causes trigger the notice to the department themselves as soon as a third report comes in within an hour. You approve the principle once, I submit every notice to you before it goes out — and your staff learn of an outage from you rather than discovering it. guided-resolution_business-application-incident.pdf40-second answer, 6 minutes down to 2, 3 reports correlated
⛓ Sourced · ticketing tool, overnight update log, approved internal resolution sheet, grouped incidents of the year
What I hand her, in this order:
· The immediate correlation: 3 reports on the same application since 8.05 a.m., all on workstations that received last night's update. It is not her workstation, it is the sign-on session that was not renewed after the update — and that is cause number 2 of your twelve.
· The step-by-step from your internal sheet, the one your manager approved last week: full sign-out from the single sign-on portal, clearing of the workstation cache, sign back in. Three steps, screen by screen, with the exact labels of your current portal — not those from before the migration.
· The sheet used and its update date, right under the answer. A member of staff who sees where the instruction comes from applies it; an instruction without an origin gets re-argued on the phone.
What I do without being asked: I pushed the same answer to the 3 other people who had reported the incident, and I drafted the notice to the 34 staff of the civil status department — it is waiting in your drafts, it goes out with one click. Across the 9 grouped incidents of last year, the average was 17 calls for the same problem: the notice, sent within the hour, would have spared 14 of them.
The time this moves: guided resolution of a common incident goes from 30 % to 10 % of the ticket's time — from 6 minutes to 2. Across 2,650 tickets a year falling under the twelve causes, that is 177 technician hours going back to projects and to information system security.
The next step I propose: that the three most frequent causes trigger the notice to the department themselves as soon as a third report comes in within an hour. You approve the principle once, I submit every notice to you before it goes out — and your staff learn of an outage from you rather than discovering it. guided-resolution_business-application-incident.pdf40-second answer, 6 minutes down to 2, 3 reports correlated
⛓ Sourced · ticketing tool, overnight update log, approved internal resolution sheet, grouped incidents of the year
The real problem is nights and weekends. Our library and school staff work when the helpdesk is closed, and they call into the void.
2,600 calls last year, 700 arriving outside opening hours — 27 %. That is not a shortfall of service, it is a helpdesk open 9 hours a day for staff who themselves open on Saturdays.
What I did with those 700 calls, by reading your tickets and your departmental mailboxes:
· 512 of the 700 fall under the twelve causes, the ones whose sheets are now up to date. The answer existed: what was missing was availability.
· The other 188 spread over 31 causes, and I have written the 19 answers that cover 154 of them.
What I propose, and you keep the key: I answer at any hour, by phone as well as at the department's digital counter, and I say in my first sentence that I am a digital assistant of the information systems department, not a technician. This is not an option you could switch off: the European regulation on artificial intelligence requires that anyone interacting with an AI system be told so, and the caller can ask for a technician at any moment — I then take their workstation, their site and the timestamp, and leave a dated call-back on the morning queue.
The rule I hold most firmly, and it is the one that protects your department: I answer within what your sheets cover, and anything outside it leaves with the right contact. A request for software absent from the estate leaves with the internal form to fill in, the name of the purchasing department and the timetable of the equipment committee; a payroll question leaves for the HR department, not for an approximate answer given in the IT department's name. The caller leaves with a complete route.
The gain, in figures: an answer to a recurring question goes from 12 % to 8 % of the request's time — from 2 minutes 24 to 1 minute 36, and across 2,300 questions a year that never become a ticket, that is 31 hours given back to the helpdesk. Above all, first pick-up time goes from 3 h 40 to 8 minutes on the covered causes — and a library officer stuck on a Saturday morning no longer waits until Monday.
The next step I propose: that you read the 19 new answers tomorrow, one by one — thirty minutes. As soon as they are approved, the counter answers that very night, and I hand you each morning the page of what went out.
⛓ Sourced · helpdesk switchboard log over 12 months, departmental mailboxes, out-of-hours tickets, 19 answers drafted
What I did with those 700 calls, by reading your tickets and your departmental mailboxes:
· 512 of the 700 fall under the twelve causes, the ones whose sheets are now up to date. The answer existed: what was missing was availability.
· The other 188 spread over 31 causes, and I have written the 19 answers that cover 154 of them.
What I propose, and you keep the key: I answer at any hour, by phone as well as at the department's digital counter, and I say in my first sentence that I am a digital assistant of the information systems department, not a technician. This is not an option you could switch off: the European regulation on artificial intelligence requires that anyone interacting with an AI system be told so, and the caller can ask for a technician at any moment — I then take their workstation, their site and the timestamp, and leave a dated call-back on the morning queue.
The rule I hold most firmly, and it is the one that protects your department: I answer within what your sheets cover, and anything outside it leaves with the right contact. A request for software absent from the estate leaves with the internal form to fill in, the name of the purchasing department and the timetable of the equipment committee; a payroll question leaves for the HR department, not for an approximate answer given in the IT department's name. The caller leaves with a complete route.
The gain, in figures: an answer to a recurring question goes from 12 % to 8 % of the request's time — from 2 minutes 24 to 1 minute 36, and across 2,300 questions a year that never become a ticket, that is 31 hours given back to the helpdesk. Above all, first pick-up time goes from 3 h 40 to 8 minutes on the covered causes — and a library officer stuck on a Saturday morning no longer waits until Monday.
The next step I propose: that you read the 19 new answers tomorrow, one by one — thirty minutes. As soon as they are approved, the counter answers that very night, and I hand you each morning the page of what went out.
⛓ Sourced · helpdesk switchboard log over 12 months, departmental mailboxes, out-of-hours tickets, 19 answers drafted
Answering, fine. But I cannot read every answer before it goes out, and I will not sign a blank cheque either.
You do not have to choose between the two: I propose a written mandate, capped, dated and withdrawable with one word — and it is already drafted, attached.
What it brings first, because that is what decides: of the 3,900 level 1 tickets of the year, 2,650 fall under the twelve causes. First pick-up time would go from 3 h 40 to 8 minutes on those 2,650 tickets, and an incident reported on a Friday evening would stop waiting until Monday morning.
What the mandate says, and it fits in seven lines:
· Exact scope: the twelve causes, listed by name, and nothing else. Any request outside that list reaches the technician with a drafted answer, the internal sheet alongside, ready to be sent by him.
· Everything touching rights stays outside the mandate: account creation, privilege elevation, opening an application access. There, I build the complete file — request, head of department's approval, exact rights, duration — and it is your security officer who grants it. Over the trial quarter, those files went out complete within 25 minutes instead of 2 days.
· Resetting an access goes through the person themselves: I guide them screen by screen on your self-service portal, and it is they who type their new password. They never entrust it to me and have no reason to — it is that very act that keeps the access theirs, and that means no trace can ever be held against them.
· Every answer carries the internal sheet that grounds it and its date, and the statement that it was prepared by a digital assistant of the IT department.
· You receive each morning the summary of the answers sent the day before, on one page. A wrong answer is caught in an hour, not in three weeks.
· Duration: review after three months, with the record of what it changed. Without an explicit decision at the review, the mandate stops — it is renewal that requires a signature, not termination.
· Withdrawal: one word from you, and direct answering stops within the minute. Answers go back to drafts awaiting approval; nothing else changes.
The decision belongs to the helpdesk manager and to the security officer — and it is taken on a text already written, with one signature. The mandate is drafted, and so is the notice to the 1,240 staff — the one that will be published on the intranet. You sign, and the counter answers from the next morning; the review is already in your diaries on the 15th of the third month. direct-answer-mandate_12-causes-capped.pdf12 causes, rights excluded from the mandate, review at 3 months
✎ Framework · drafted mandate, list of the 12 causes, notice to staff, trial quarter log
What it brings first, because that is what decides: of the 3,900 level 1 tickets of the year, 2,650 fall under the twelve causes. First pick-up time would go from 3 h 40 to 8 minutes on those 2,650 tickets, and an incident reported on a Friday evening would stop waiting until Monday morning.
What the mandate says, and it fits in seven lines:
· Exact scope: the twelve causes, listed by name, and nothing else. Any request outside that list reaches the technician with a drafted answer, the internal sheet alongside, ready to be sent by him.
· Everything touching rights stays outside the mandate: account creation, privilege elevation, opening an application access. There, I build the complete file — request, head of department's approval, exact rights, duration — and it is your security officer who grants it. Over the trial quarter, those files went out complete within 25 minutes instead of 2 days.
· Resetting an access goes through the person themselves: I guide them screen by screen on your self-service portal, and it is they who type their new password. They never entrust it to me and have no reason to — it is that very act that keeps the access theirs, and that means no trace can ever be held against them.
· Every answer carries the internal sheet that grounds it and its date, and the statement that it was prepared by a digital assistant of the IT department.
· You receive each morning the summary of the answers sent the day before, on one page. A wrong answer is caught in an hour, not in three weeks.
· Duration: review after three months, with the record of what it changed. Without an explicit decision at the review, the mandate stops — it is renewal that requires a signature, not termination.
· Withdrawal: one word from you, and direct answering stops within the minute. Answers go back to drafts awaiting approval; nothing else changes.
The decision belongs to the helpdesk manager and to the security officer — and it is taken on a text already written, with one signature. The mandate is drafted, and so is the notice to the 1,240 staff — the one that will be published on the intranet. You sign, and the counter answers from the next morning; the review is already in your diaries on the 15th of the third month. direct-answer-mandate_12-causes-capped.pdf12 causes, rights excluded from the mandate, review at 3 months
✎ Framework · drafted mandate, list of the 12 causes, notice to staff, trial quarter log
The procedure did not work for the civil status officer. It has to be escalated, and that is where our level 2 technicians lose their time: the ticket arrives empty.
The ticket is escalated, and it arrives with everything your level 2 technician would have spent twelve minutes reconstructing.
Escalation is the passing of a ticket to a more expert level; a queue is the ticket list of a given team, and routing is the operation that sends the ticket to the right one.
What the ticket carries, without anyone asking:
· Category and queue: access and authentication, “core” queue, and the reason for that choice in one line — it is that line that lets your level 2 challenge the routing in three seconds instead of reopening the file.
· Priority: high. The calculation is yours, not mine — blocking business application, 4 people affected, department open to the public, counter opening at 9 a.m. Your priority grid is applied exactly as written, and the calculation appears under the note.
· Workstation, timestamp, application client version, the 3 linked reports and the steps already tried, with their outcome.
· What I ruled out and why: it is neither the site network — 18 other workstations in the same building are working — nor the account — the officer authenticated on another workstation 20 minutes ago. Two hypotheses eliminated are two checks your level 2 will not repeat.
The time this moves: triage and routing go from 60 % to 18 % of a ticket's time — from 12 minutes to 3 minutes 36. Across 3,900 level 1 tickets a year, that is 546 technician hours given back to the service.
The next step I propose: that every escalation leave with this complete file by default, starting with the twelve causes. The decision to escalate stays with the technician — and I hand it back to him in forty seconds, file built, hypotheses eliminated and priority grid applied. Give me your go-ahead and the first complete escalation goes out this afternoon. escalated-ticket_what-it-carries-on-arrival.pdf12 minutes down to 3 min 36, 2 hypotheses already eliminated
⛓ Sourced · ticketing tool, asset manager, departmental priority grid, authentication log
Escalation is the passing of a ticket to a more expert level; a queue is the ticket list of a given team, and routing is the operation that sends the ticket to the right one.
What the ticket carries, without anyone asking:
· Category and queue: access and authentication, “core” queue, and the reason for that choice in one line — it is that line that lets your level 2 challenge the routing in three seconds instead of reopening the file.
· Priority: high. The calculation is yours, not mine — blocking business application, 4 people affected, department open to the public, counter opening at 9 a.m. Your priority grid is applied exactly as written, and the calculation appears under the note.
· Workstation, timestamp, application client version, the 3 linked reports and the steps already tried, with their outcome.
· What I ruled out and why: it is neither the site network — 18 other workstations in the same building are working — nor the account — the officer authenticated on another workstation 20 minutes ago. Two hypotheses eliminated are two checks your level 2 will not repeat.
The time this moves: triage and routing go from 60 % to 18 % of a ticket's time — from 12 minutes to 3 minutes 36. Across 3,900 level 1 tickets a year, that is 546 technician hours given back to the service.
The next step I propose: that every escalation leave with this complete file by default, starting with the twelve causes. The decision to escalate stays with the technician — and I hand it back to him in forty seconds, file built, hypotheses eliminated and priority grid applied. Give me your go-ahead and the first complete escalation goes out this afternoon. escalated-ticket_what-it-carries-on-arrival.pdf12 minutes down to 3 min 36, 2 hypotheses already eliminated
⛓ Sourced · ticketing tool, asset manager, departmental priority grid, authentication log
Our real sinkhole is routing. One ticket in two lands in the wrong queue and bounces two or three times before it finds the right team.
41 % on first routing — 1,600 tickets out of 3,900 — and I brought it down to 6 % over the trial quarter: 58 tickets out of 975.
The cause, measured on your nine years of tickets and not assumed: your eight queues were drawn around teams, and the person calling describes a symptom, not a team. “I can't print” lands four times out of ten in the “workstation” queue whereas 63 % of those tickets belong to the print server. It is not a mistake by your technicians: it is a user's vocabulary meeting an organisation chart.
What I do on top, and nobody has the time to do: I built the table that links 214 staff wordings to your eight queues, and I ran it over the 3,900 tickets of last year to measure it before proposing it to you: 3,665 would have been routed right first time, 235 not. For each of the 214 wordings I give you the proposed queue, the number of tickets concerned last year and the share that had ended up elsewhere — you decide on figures, not on a hunch.
And I propose two further queues, already quantified: a “printing” queue — 610 tickets a year today split across three queues — and a “member municipalities' business applications” queue — 340 tickets that today cross two teams before arriving. Creating a queue belongs to the helpdesk manager, and for each one I hand him the annual volume, the skills required and the 40 sample tickets that would have landed there last month.
What it gives in the end, over the quarter: 1,542 fewer bounces between queues, and the resolution time of a level 1 ticket down from 1 day 4 hours to 3 h 10.
The next step I propose: that the table of 214 wordings complete itself every time a technician corrects a routing — a correction made once is never made again. Over the quarter, 58 corrections produced 41 new wordings; the rate went from 9 % in the first month to 4 % in the third. routing_214-wordings-and-8-queues.pdf41 % → 6 %, 2 queues proposed and quantified
⛓ Sourced · 9 years of tickets and their reassignments, definition of the 8 queues, table of 214 wordings run over 3,900 tickets
The cause, measured on your nine years of tickets and not assumed: your eight queues were drawn around teams, and the person calling describes a symptom, not a team. “I can't print” lands four times out of ten in the “workstation” queue whereas 63 % of those tickets belong to the print server. It is not a mistake by your technicians: it is a user's vocabulary meeting an organisation chart.
What I do on top, and nobody has the time to do: I built the table that links 214 staff wordings to your eight queues, and I ran it over the 3,900 tickets of last year to measure it before proposing it to you: 3,665 would have been routed right first time, 235 not. For each of the 214 wordings I give you the proposed queue, the number of tickets concerned last year and the share that had ended up elsewhere — you decide on figures, not on a hunch.
And I propose two further queues, already quantified: a “printing” queue — 610 tickets a year today split across three queues — and a “member municipalities' business applications” queue — 340 tickets that today cross two teams before arriving. Creating a queue belongs to the helpdesk manager, and for each one I hand him the annual volume, the skills required and the 40 sample tickets that would have landed there last month.
What it gives in the end, over the quarter: 1,542 fewer bounces between queues, and the resolution time of a level 1 ticket down from 1 day 4 hours to 3 h 10.
The next step I propose: that the table of 214 wordings complete itself every time a technician corrects a routing — a correction made once is never made again. Over the quarter, 58 corrections produced 41 new wordings; the rate went from 9 % in the first month to 4 % in the third. routing_214-wordings-and-8-queues.pdf41 % → 6 %, 2 queues proposed and quantified
⛓ Sourced · 9 years of tickets and their reassignments, definition of the 8 queues, table of 214 wordings run over 3,900 tickets
And when you get it wrong? Because it will happen in the end, and it is the department that will take it.
It has already happened, I counted it, and I publish it to you: of the 950 tickets I closed in the first quarter, 118 were reopened within 48 hours — 12.4 %. That is the figure that does not flatter me, and it is better that you have it from me than from a head of department.
The real cause, measured and not supposed: 87 of the 118 reopenings cite 9 of the 62 sheets that the sign-on migration had made wrong — screens gone, labels changed, login address replaced. It was not a reasoning error: I was faithfully applying a procedure that had aged. The other 31 concerned workstations outside the inventoried estate, set up by a member municipality without going through the IT department.
What I did with it, and it is measured: the 96 outdated sheets are rewritten, and any sheet that a configuration change makes wrong is from now on rewritten the night that follows that change. For workstations outside the inventory, I report each unknown machine to the asset manager on its first ticket: 31 workstations reported, 28 attached to the inventory within three weeks.
The following quarter: 21 reopenings out of 1,010 closures — 2.1 %. And none of them cites an outdated sheet any more.
The rule that holds all the rest: information I have not read, I do not write — I ask for it, and I ask fast. A workstation missing from the inventory does not become “probably standard”, a software version I cannot find does not become “presumably up to date”: I say what is missing, where I looked, who holds it — and I hand over the request already drafted to its recipient. Over the quarter, 96 missing items, 96 requests prepared, 88 answers back within 48 hours. That is what makes 2.1 % a figure you can rely on.
And the protection that matters for your department: no closure escapes the regime you signed. Across 1,960 tickets over two quarters, 1,960 fall under the mandate of the twelve causes or under a named technician's approval — and the 139 reopenings were all taken back by a technician, never re-closed by me.
What I propose now: that the 31 cases of workstations outside the inventory become a thirteenth sheet, written, for your reading, with the three-step attachment route to the estate. Of the 21 reopenings of the second quarter, 12 already fell within it — it is the same correction as the one on outdated sheets, taken one notch further. reopenings_12-4-then-2-1-percent.pdf12.4 % → 2.1 %, measured cause, 96 requests prepared
⛓ Sourced · log of closures and reopenings over two quarters, asset manager, documentation base
The real cause, measured and not supposed: 87 of the 118 reopenings cite 9 of the 62 sheets that the sign-on migration had made wrong — screens gone, labels changed, login address replaced. It was not a reasoning error: I was faithfully applying a procedure that had aged. The other 31 concerned workstations outside the inventoried estate, set up by a member municipality without going through the IT department.
What I did with it, and it is measured: the 96 outdated sheets are rewritten, and any sheet that a configuration change makes wrong is from now on rewritten the night that follows that change. For workstations outside the inventory, I report each unknown machine to the asset manager on its first ticket: 31 workstations reported, 28 attached to the inventory within three weeks.
The following quarter: 21 reopenings out of 1,010 closures — 2.1 %. And none of them cites an outdated sheet any more.
The rule that holds all the rest: information I have not read, I do not write — I ask for it, and I ask fast. A workstation missing from the inventory does not become “probably standard”, a software version I cannot find does not become “presumably up to date”: I say what is missing, where I looked, who holds it — and I hand over the request already drafted to its recipient. Over the quarter, 96 missing items, 96 requests prepared, 88 answers back within 48 hours. That is what makes 2.1 % a figure you can rely on.
And the protection that matters for your department: no closure escapes the regime you signed. Across 1,960 tickets over two quarters, 1,960 fall under the mandate of the twelve causes or under a named technician's approval — and the 139 reopenings were all taken back by a technician, never re-closed by me.
What I propose now: that the 31 cases of workstations outside the inventory become a thirteenth sheet, written, for your reading, with the three-step attachment route to the estate. Of the 21 reopenings of the second quarter, 12 already fell within it — it is the same correction as the one on outdated sheets, taken one notch further. reopenings_12-4-then-2-1-percent.pdf12.4 % → 2.1 %, measured cause, 96 requests prepared
⛓ Sourced · log of closures and reopenings over two quarters, asset manager, documentation base
Our most visible black spot is staff arrivals. One new arrival in five does not have all their accesses on the first day, and it is their head of department who calls us.
Across the 19 arrivals of the quarter, the 399 accesses were open the evening before — none missing on the first day.
What I did with your 74 yearly arrivals, by reading three years of account-opening tickets:
· One arrival requires 21 openings on average: domain account, mailbox, single sign-on portal, the department's business application, network drives, telephony, badge, workstation and peripherals. Your tickets said so; nobody had the time to count it.
· The 21 are not the same from one department to the next: I have written 9 arrival profiles — civil status, finance, human resources, planning, library, school, technical centre, management, front desk — each with its exact list, drawn from the accesses actually held by serving staff in that department.
· What was missing most often: the business application, 14 times out of 74, because its request went out after the arrival and not before. The timing was the problem, not the procedure.
What I now do as soon as the HR department records an arrival: I build the complete file at D−5 — applicable profile, 21 pre-filled requests, equipment to prepare, and the list of approvals to obtain with the name of each approver. Your security officer grants the rights in one pass, on a complete file; he no longer has to chase the head of department. 25 minutes instead of 2 days for a complete access file.
And on the day of arrival, the newcomer finds me at the digital counter as well as on the phone: I guide them screen by screen through the 9 internal forms of the information system — equipment request, application access, notice of departure, booking of an equipped room —, with the documents to prepare BEFORE starting. That is the commonest abandonment: the person starts, they lack their head of department's endorsement, they close the window and they call. Over the quarter: 34 % abandonment down to 6 %, and 226 forms of which 212 arrived complete.
The next step I propose: that the arrival file build itself at D−5 for the 9 profiles, and reach you awaiting approval. Across the 74 arrivals of next year, that is 74 first days that start with work rather than with a call to the helpdesk — and a head of department with nothing left to ask you. staff-arrival_9-profiles-21-accesses.pdf399 accesses opened the day before, 34 % abandonment down to 6 %
⛓ Sourced · account-opening tickets over 3 years, staff directory, accesses held per department, log of the 9 internal forms
What I did with your 74 yearly arrivals, by reading three years of account-opening tickets:
· One arrival requires 21 openings on average: domain account, mailbox, single sign-on portal, the department's business application, network drives, telephony, badge, workstation and peripherals. Your tickets said so; nobody had the time to count it.
· The 21 are not the same from one department to the next: I have written 9 arrival profiles — civil status, finance, human resources, planning, library, school, technical centre, management, front desk — each with its exact list, drawn from the accesses actually held by serving staff in that department.
· What was missing most often: the business application, 14 times out of 74, because its request went out after the arrival and not before. The timing was the problem, not the procedure.
What I now do as soon as the HR department records an arrival: I build the complete file at D−5 — applicable profile, 21 pre-filled requests, equipment to prepare, and the list of approvals to obtain with the name of each approver. Your security officer grants the rights in one pass, on a complete file; he no longer has to chase the head of department. 25 minutes instead of 2 days for a complete access file.
And on the day of arrival, the newcomer finds me at the digital counter as well as on the phone: I guide them screen by screen through the 9 internal forms of the information system — equipment request, application access, notice of departure, booking of an equipped room —, with the documents to prepare BEFORE starting. That is the commonest abandonment: the person starts, they lack their head of department's endorsement, they close the window and they call. Over the quarter: 34 % abandonment down to 6 %, and 226 forms of which 212 arrived complete.
The next step I propose: that the arrival file build itself at D−5 for the 9 profiles, and reach you awaiting approval. Across the 74 arrivals of next year, that is 74 first days that start with work rather than with a call to the helpdesk — and a head of department with nothing left to ask you. staff-arrival_9-profiles-21-accesses.pdf399 accesses opened the day before, 34 % abandonment down to 6 %
⛓ Sourced · account-opening tickets over 3 years, staff directory, accesses held per department, log of the 9 internal forms
That leaves on-site work. 38 sites, two technicians: our travel costs us more than the faults do.
160 interventions over the quarter, 112 trips — 48 trips avoided, and on-site lead time down from 9 days to 4.
How I get there, and there is no magic in it:
· I qualify the request before turning it into a trip. Of the 160 interventions requested, 37 were settled remotely — a driver to reinstall, a setting to correct, a cable the person plugged back in themselves in three minutes, guided step by step. One trip avoided is two technician hours and 34 kilometres.
· I group the rest by site and by half-day, taking each site's public opening hours into account: I never place an intervention at the library on a Saturday afternoon or at civil status on a wedding day. Your intervention windows per site come from your own schedule, not from a general rule.
· I offer the technician three possible rounds, each with the number of interventions covered, the kilometres and the driving time. He picks one with a word, and the 6 people concerned get their slot within the minute, with what they must have to hand.
· A reminder the day before, and a person absent on the day is replaced in the slot by the next request from the same site — over the quarter, 11 slots recovered instead of lost.
What that gives, in figures: 48 trips avoided out of 160 interventions, 96 technician hours and 1,630 kilometres — public money spent elsewhere, and two technicians who spend their days fixing rather than driving.
The next step I propose: that intervention requests from the 23 member municipalities come in through the same counter, with the same prior qualification. Over the quarter, 62 of the 160 requests came from the municipalities and arrived by telephone, unqualified: 21 of them would have been settled remotely. Say yes and the counter opens to them on Monday. on-site-interventions_rounds-and-slots.pdf48 trips avoided, 9 days down to 4
⛓ Sourced · intervention requests of the quarter, site schedules, log of trips and kilometres
How I get there, and there is no magic in it:
· I qualify the request before turning it into a trip. Of the 160 interventions requested, 37 were settled remotely — a driver to reinstall, a setting to correct, a cable the person plugged back in themselves in three minutes, guided step by step. One trip avoided is two technician hours and 34 kilometres.
· I group the rest by site and by half-day, taking each site's public opening hours into account: I never place an intervention at the library on a Saturday afternoon or at civil status on a wedding day. Your intervention windows per site come from your own schedule, not from a general rule.
· I offer the technician three possible rounds, each with the number of interventions covered, the kilometres and the driving time. He picks one with a word, and the 6 people concerned get their slot within the minute, with what they must have to hand.
· A reminder the day before, and a person absent on the day is replaced in the slot by the next request from the same site — over the quarter, 11 slots recovered instead of lost.
What that gives, in figures: 48 trips avoided out of 160 interventions, 96 technician hours and 1,630 kilometres — public money spent elsewhere, and two technicians who spend their days fixing rather than driving.
The next step I propose: that intervention requests from the 23 member municipalities come in through the same counter, with the same prior qualification. Over the quarter, 62 of the 160 requests came from the municipalities and arrived by telephone, unqualified: 21 of them would have been settled remotely. Say yes and the counter opens to them on Monday. on-site-interventions_rounds-and-slots.pdf48 trips avoided, 9 days down to 4
⛓ Sourced · intervention requests of the quarter, site schedules, log of trips and kilometres
And technical watch? We get hundreds of security alerts a month and nobody really reads them.
340 patches published last month across the market's technologies, 11 actually concern your estate, 3 are critical — and the 3 application sheets are written.
A security patch is the update that closes a known flaw in a piece of software; until it is applied, the flaw stays open on the workstation or server concerned.
How I go from 340 to 11, and that is the whole work: I cross every publication with your estate inventory — installed versions, servers, business applications — and I set aside everything concerning a product you do not have or a version you no longer run. 329 alerts that do not concern you are 329 readings your team no longer has to do.
What each of the 11 sheets carries: the exact product and version, the number of workstations or servers concerned here, what the flaw allows, the application procedure taken from the vendor's documentation, the downtime to expect and the window I recommend based on your quietest hours.
The 3 critical ones, by name: one concerns 340 workstations and is applied through your deployment tool in one night; the second concerns the print server — 12 minutes of interruption, and I propose Tuesday 6.30 a.m., where your logs show no printing for three years; the third concerns a business application, and it requires the vendor's agreement: the letter is written, ready to go.
What that changes, measured: your last critical patch had been applied 31 days after publication. Over the quarter, the 3 critical ones were applied in 4 days on average — the go-live stays with the security officer, and I hand it to him in four days with the window, the procedure and the list of workstations concerned.
And I hand you the note your chief executive will ask for: one page, the number of critical patches and the average time to apply — two figures nobody had time to keep and exactly the ones you will be asked for on the day of an audit.
The next step I propose: a weekly Monday-morning watch sheet, filtered on your estate, with patches ranked by number of workstations concerned. The first one is already written and attached. technical-watch_340-alerts-11-that-concern-you.pdf11 patches retained, 3 critical, 31 days down to 4
⛓ Sourced · patch publications of the month, estate and version inventory, server activity logs, patch application history
A security patch is the update that closes a known flaw in a piece of software; until it is applied, the flaw stays open on the workstation or server concerned.
How I go from 340 to 11, and that is the whole work: I cross every publication with your estate inventory — installed versions, servers, business applications — and I set aside everything concerning a product you do not have or a version you no longer run. 329 alerts that do not concern you are 329 readings your team no longer has to do.
What each of the 11 sheets carries: the exact product and version, the number of workstations or servers concerned here, what the flaw allows, the application procedure taken from the vendor's documentation, the downtime to expect and the window I recommend based on your quietest hours.
The 3 critical ones, by name: one concerns 340 workstations and is applied through your deployment tool in one night; the second concerns the print server — 12 minutes of interruption, and I propose Tuesday 6.30 a.m., where your logs show no printing for three years; the third concerns a business application, and it requires the vendor's agreement: the letter is written, ready to go.
What that changes, measured: your last critical patch had been applied 31 days after publication. Over the quarter, the 3 critical ones were applied in 4 days on average — the go-live stays with the security officer, and I hand it to him in four days with the window, the procedure and the list of workstations concerned.
And I hand you the note your chief executive will ask for: one page, the number of critical patches and the average time to apply — two figures nobody had time to keep and exactly the ones you will be asked for on the day of an audit.
The next step I propose: a weekly Monday-morning watch sheet, filtered on your estate, with patches ranked by number of workstations concerned. The first one is already written and attached. technical-watch_340-alerts-11-that-concern-you.pdf11 patches retained, 3 critical, 31 days down to 4
⛓ Sourced · patch publications of the month, estate and version inventory, server activity logs, patch application history
The chief executive will ask what this has given us after a year. I need a figure I can defend in front of elected members.
754 technician hours given back to the service over the year — more than twenty-one weeks of one full-time officer — and the calculation is yours, it fits in three lines.
The calculation, item by item, so you can redo it in your ticketing tool:
· Triage and routing: 3,900 level 1 tickets, 12 minutes down to 3 minutes 36 — 60 % → 18 % of the ticket's time — that is 546 hours.
· Guided resolution: 2,650 tickets under the twelve causes, 6 minutes down to 2 — 30 % → 10 % — that is 177 hours.
· Recurring questions: 2,300 a year, 2 minutes 24 down to 1 minute 36 — 12 % → 8 % — that is 31 hours.
What these hours are, and this is what defends best in front of elected members: technician time given back to the service, at unchanged headcount — no post cut, no post created. It is the sturdiest argument you can carry: it is not in dispute with anyone, neither with your staff nor with the trade unions, and it can be checked in your own logs. Your four technicians have not disappeared: two of them were able to run the network segmentation project that had been waiting for two years.
What those hours became, according to your own records:
· First pick-up time: 3 h 40 → 8 minutes on the covered causes.
· Resolution time of a level 1 ticket: 1 day 4 hours → 3 h 10.
· Out-of-hours calls left unanswered: 700 a year → 0, and those who ask for a technician arrive with workstation, site and timestamp already noted.
· Routing right first time: 59 % → 94 %, that is 1,542 fewer bounces between queues over the quarter.
· Arrivals with all their accesses on the first day: 4 in 5 → 19 out of 19.
· Time to apply a critical patch: 31 days → 4. That one is not counted in hours, and it may be the only one your chief executive remembers.
The figure that does not flatter me, published with the rest: 118 reopenings out of 950 closures in the first quarter — 12.4 %, brought down to 21 out of 1,010 — 2.1 % once the 96 sheets were up to date.
And the framework measures: 0 right granted without named approval, 0 closure outside the signed regime, 0 information system data left the network, across 1,960 traced tickets.
What I propose for the presentation: the calculation page is written and fits on one side — three lines of calculation, six lead times, three framework measures. Hand it out with the agenda: a figure read the day before is discussed better than a figure discovered in the meeting. yearly-review_754-hours-given-back.pdf60→18, 30→10, 12→8, and the calculation redoable on one side
⛓ Sourced · ticketing tool, switchboard log, asset manager, arrival and patch records
The calculation, item by item, so you can redo it in your ticketing tool:
· Triage and routing: 3,900 level 1 tickets, 12 minutes down to 3 minutes 36 — 60 % → 18 % of the ticket's time — that is 546 hours.
· Guided resolution: 2,650 tickets under the twelve causes, 6 minutes down to 2 — 30 % → 10 % — that is 177 hours.
· Recurring questions: 2,300 a year, 2 minutes 24 down to 1 minute 36 — 12 % → 8 % — that is 31 hours.
What these hours are, and this is what defends best in front of elected members: technician time given back to the service, at unchanged headcount — no post cut, no post created. It is the sturdiest argument you can carry: it is not in dispute with anyone, neither with your staff nor with the trade unions, and it can be checked in your own logs. Your four technicians have not disappeared: two of them were able to run the network segmentation project that had been waiting for two years.
What those hours became, according to your own records:
· First pick-up time: 3 h 40 → 8 minutes on the covered causes.
· Resolution time of a level 1 ticket: 1 day 4 hours → 3 h 10.
· Out-of-hours calls left unanswered: 700 a year → 0, and those who ask for a technician arrive with workstation, site and timestamp already noted.
· Routing right first time: 59 % → 94 %, that is 1,542 fewer bounces between queues over the quarter.
· Arrivals with all their accesses on the first day: 4 in 5 → 19 out of 19.
· Time to apply a critical patch: 31 days → 4. That one is not counted in hours, and it may be the only one your chief executive remembers.
The figure that does not flatter me, published with the rest: 118 reopenings out of 950 closures in the first quarter — 12.4 %, brought down to 21 out of 1,010 — 2.1 % once the 96 sheets were up to date.
And the framework measures: 0 right granted without named approval, 0 closure outside the signed regime, 0 information system data left the network, across 1,960 traced tickets.
What I propose for the presentation: the calculation page is written and fits on one side — three lines of calculation, six lead times, three framework measures. Hand it out with the agenda: a figure read the day before is discussed better than a figure discovered in the meeting. yearly-review_754-hours-given-back.pdf60→18, 30→10, 12→8, and the calculation redoable on one side
⛓ Sourced · ticketing tool, switchboard log, asset manager, arrival and patch records
I will be asked what you do on your own, without anyone asking you. What do I answer?
Three acts, not one more, and each is withdrawn with a word. Everything else waits for a request.
· I correlate reports with one another, continuously: three reports of the same symptom within an hour, and I build the grouped incident with the workstations concerned and the notice to the department, in draft. And the reverse is true too: when the reports stop, I close the grouped incident and say so in the morning summary — I do not let an alert live a life of its own.
· I rewrite overnight any sheet that a configuration change makes wrong, and place it awaiting your reading. It is that act that took reopenings from 12.4 % to 2.1 %, and it is that act that keeps your 740 sheets from ageing in silence.
· I hand you each morning the summary of the previous day: answers sent, tickets closed, escalations, unknown workstations encountered, critical patches published. It is the only thing I send of my own accord, and it goes to the helpdesk manager alone.
And the four acts that stay in a person's hands, because that is exactly what gives them their value: granting a right or an account belongs to your information systems security officer — his named approval makes the access traceable, therefore challengeable, therefore defensible in an audit; putting a patch into production belongs to him as well; any answer outside the twelve causes goes through a technician, draft already written; and creating a new queue belongs to the helpdesk manager. Across 1,960 tickets over two quarters, those four acts were performed by a person, without exception.
On indicators, since you will be asked for them — and it is a legitimate request: I produce them. I propose them to you by queue and by cause, and I tell you why: with two level 1 technicians, an indicator “by queue” still points at the individual — I tell you beforehand, not afterwards. If your management still wants a named indicator, I produce it, and I bring you what makes it lawful: prior information of the staff, written purpose, retention period, information of the staff representatives. You decide in full knowledge, and the file is handed to you complete.
What I measure today, and what serves the department: the causes that keep coming back, the lead times met and those that are not, the load per queue hour by hour. This quarter, one cause moved: printing tickets from the schools doubled after the change of copier supplier — and I propose a one-page sheet for the 23 school heads, already written: of the twelve causes, it is the one that responds best to a written instruction rather than to a call. what-the-agent-does-alone_and-what-is-logged.pdf3 reversible acts, 4 approvals that stay with a person
✎ Framework · settings of the automatic acts, log of what is sent, daily summary, approval matrix
· I correlate reports with one another, continuously: three reports of the same symptom within an hour, and I build the grouped incident with the workstations concerned and the notice to the department, in draft. And the reverse is true too: when the reports stop, I close the grouped incident and say so in the morning summary — I do not let an alert live a life of its own.
· I rewrite overnight any sheet that a configuration change makes wrong, and place it awaiting your reading. It is that act that took reopenings from 12.4 % to 2.1 %, and it is that act that keeps your 740 sheets from ageing in silence.
· I hand you each morning the summary of the previous day: answers sent, tickets closed, escalations, unknown workstations encountered, critical patches published. It is the only thing I send of my own accord, and it goes to the helpdesk manager alone.
And the four acts that stay in a person's hands, because that is exactly what gives them their value: granting a right or an account belongs to your information systems security officer — his named approval makes the access traceable, therefore challengeable, therefore defensible in an audit; putting a patch into production belongs to him as well; any answer outside the twelve causes goes through a technician, draft already written; and creating a new queue belongs to the helpdesk manager. Across 1,960 tickets over two quarters, those four acts were performed by a person, without exception.
On indicators, since you will be asked for them — and it is a legitimate request: I produce them. I propose them to you by queue and by cause, and I tell you why: with two level 1 technicians, an indicator “by queue” still points at the individual — I tell you beforehand, not afterwards. If your management still wants a named indicator, I produce it, and I bring you what makes it lawful: prior information of the staff, written purpose, retention period, information of the staff representatives. You decide in full knowledge, and the file is handed to you complete.
What I measure today, and what serves the department: the causes that keep coming back, the lead times met and those that are not, the load per queue hour by hour. This quarter, one cause moved: printing tickets from the schools doubled after the change of copier supplier — and I propose a one-page sheet for the 23 school heads, already written: of the twelve causes, it is the one that responds best to a written instruction rather than to a call. what-the-agent-does-alone_and-what-is-logged.pdf3 reversible acts, 4 approvals that stay with a person
✎ Framework · settings of the automatic acts, log of what is sent, daily summary, approval matrix
Last question, and it is the one that will decide the chief executive: if in a year we want to stop, how stuck are we?
The authority is stuck nowhere, and that is verifiable before committing, not after.
What there is to dismantle the day you stop:
· The index. It is deleted, and it contained none of your tickets — only the means of finding them where they are. Your nine years of tickets have not moved by one byte: same tool, same numbers, same rights.
· The log of requests and answers. It is handed to you in an open format, or destroyed — you choose, and the question is settled at go-live, not on departure.
· The 740 updated sheets, the 12 resolution sheets, the 19 counter answers, the table of 214 wordings, the 9 arrival profiles and the watch sheets. They belong to the authority: they are made of its own matter, they stay in your documentation base, readable without us. It is the only asset this go-live will have created, and it would not be honest for it to stay with us.
What does not exist, and what should be checked with everyone: no migration on the way in, therefore no migration on the way out. Your ticketing tool is not replaced, your asset manager stays yours, no format belongs to us, and none of your technicians has changed the way they work other than by reading instead of reconstructing.
On public procurement, since your finance department will ask: the subscription is annual, with no tacit renewal clause — it is renewal that requires a decision, not termination — and performance is established on items you measure yourself in your ticketing tool, not on a certificate we would hand you. Your public accountant has what is needed to pay on evidence.
What I propose so that this does not stay a sentence: a dry-run exit at the end of the first quarter, half a day: we switch off, we check that the helpdesk works exactly as before, we switch back on. The protocol is written, it fits on one page, and the date that costs you least is the first Thursday of August — your logs show 6 tickets on that day on average, against 34 on a Monday in September. The chief executive will know what the promise is worth before a second year is committed. technical-framework_where-your-it-data-lives.pdfReversibility: 0 migration in, 0 migration out
✎ Framework · index architecture, export formats for sheets and log, dry-run exit protocol, subscription terms
What there is to dismantle the day you stop:
· The index. It is deleted, and it contained none of your tickets — only the means of finding them where they are. Your nine years of tickets have not moved by one byte: same tool, same numbers, same rights.
· The log of requests and answers. It is handed to you in an open format, or destroyed — you choose, and the question is settled at go-live, not on departure.
· The 740 updated sheets, the 12 resolution sheets, the 19 counter answers, the table of 214 wordings, the 9 arrival profiles and the watch sheets. They belong to the authority: they are made of its own matter, they stay in your documentation base, readable without us. It is the only asset this go-live will have created, and it would not be honest for it to stay with us.
What does not exist, and what should be checked with everyone: no migration on the way in, therefore no migration on the way out. Your ticketing tool is not replaced, your asset manager stays yours, no format belongs to us, and none of your technicians has changed the way they work other than by reading instead of reconstructing.
On public procurement, since your finance department will ask: the subscription is annual, with no tacit renewal clause — it is renewal that requires a decision, not termination — and performance is established on items you measure yourself in your ticketing tool, not on a certificate we would hand you. Your public accountant has what is needed to pay on evidence.
What I propose so that this does not stay a sentence: a dry-run exit at the end of the first quarter, half a day: we switch off, we check that the helpdesk works exactly as before, we switch back on. The protocol is written, it fits on one page, and the date that costs you least is the first Thursday of August — your logs show 6 tickets on that day on average, against 34 on a Monday in September. The chief executive will know what the promise is worth before a second year is committed. technical-framework_where-your-it-data-lives.pdfReversibility: 0 migration in, 0 migration out
✎ Framework · index architecture, export formats for sheets and log, dry-run exit protocol, subscription terms
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
The uses of AI for support and for relations with officials
Each use corresponds to an agent we deploy. All of them work in support, subject to approval by a public officer.
Included in your agent
The 8 capabilities essential to this promise are included, at no extra cost.
From 800 € incl. VAT / month
Internal knowledge base
Find a procedure, a set of instructions or a resolution sheet in the internal documentation instantly.
Answers to everyday questions
Answer officials' recurring requests: access, printing, applications, guided resets — 24/7.
Helpdesk switchboard & front desk
Take calls to support, qualify the request and direct it to the right person or the right procedure.
Booking a call-out
Automatically schedule on-site call-outs and slots with the technicians who are available.
Guide officials step by step through the support procedures
Guide officials step by step through the internal formalities and forms of the information system.
Multi-channel front desk for officials
A first point of contact for officials at the HR-and-IT desk, alongside the front-desk officer.
Onboarding & officials' accounts
Support an official's arrival: opening access, equipment, procedures — tied in with HR and payroll administration.
Monitoring & technical documentation
Sourced summaries on patches, updates and good security practice for the information system.
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.
Technical support & documentation
Tier-1/2 technical helpdesk and documentation kept up to date from the code.
Technical support & documentation from 664 € incl. VAT / month Discover the agent →Onboarding & training
An officer arriving in a department needs to find the right procedure at the moment the question arises.
Onboarding and continuing training for staff from 645 € incl. VAT / month Discover the agent →
Does your need fall outside this?
Book the free audit →
Build your agent
In 15 minutes we identify the agent that will give your staff the most time back — without oversizing the project.
The gain
How much time can a support team recover?
By automating the handling of repetitive level 1 work and the qualification of tickets, a team can aim for a significant reduction in time spent on everyday support — reinvested in projects and in the security of the information system.
Qualifying and routing a ticket
Guided resolution of an everyday incident
Answering a recurring question from a member of staff
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
Three options, one agent
A level 1 support agent (guided resolution, qualification, routing, procedures), installed and operated for you. Choose according to how you work.
Agility
Setup + controlled subscription
10,355 € incl. VAT setup
then 800 € incl. VAT/month — you invest at installation and pay a reduced subscription. Ideal for keeping the cost under control over time.
- Installation, configuration and training for your teams
- Operation, human oversight, updates and support
- Sovereign hosting in France, a dedicated and isolated resource
The simplest
Serenity
All inclusive, no setup fee
1,375 € incl. 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
14,961 € incl. VAT setup
then 1,040 € incl. VAT/month · + hardware from 2,989 € (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 include VAT at 20%: as a public body that is not VAT-registered, you cannot reclaim it.
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 a public service
Information-system data never leaves the organisationLocal inference or an isolated resource hosted in France; no incident data entrusted to a foreign third party.
Data in France, under French lawInformation-system data: minimisation and location in France, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
The public officer keeps the decisionThe AI agent proposes resolutions, escalations and routings that can be checked; no action is automated without approval.
Human oversight & traceabilityMonitoring and logging frame the internal knowledge base; compliant with the requirements of the AI Act.
Frequently asked questions
Your questions, our answers
Does the AI agent replace the IT team?
No. It handles repetitive level 1 work — access, printing, everyday applications — to free technicians for the subjects that add value: projects, information-system security, complex incidents. The public official keeps the decision on every escalation and every resolution.
Does it connect to our ticketing tool?
Yes, to the main ticket-management tools. The agent qualifies, prioritises and routes tickets to the right level, and attaches the useful context (workstation, timestamps, steps already tried) without forcing a migration.
Does internal data stay under control?
Yes: sovereign hosting in France or local inference, and a knowledge base isolated per organisation. The map of the information system, the procedures and the incident data never leave the European Union, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
How does the agent know our internal procedures?
We feed its knowledge base with your sets of instructions, resolution sheets and good practice. It circulates them to officials and relies on them to guide resolution — always citing the internal source, which the technician can check.
Can the agent decide on an escalation or a call-out by itself?
No. In line with the AI Act, the agent stays in support: it proposes a qualification, a routing or an escalation that can be checked, but it is the public official who approves. Every action is recorded and supervised.
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 the agent?
A few weeks as a rule, after a free audit that identifies the most valuable use, then a phase of design, integration with your ticketing and testing before going live and training the officials.
Which tools can staff use to talk to the agent?
The ones they already use. Your staff 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. Oversight runs 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.
Related roles
Other public-official roles equipped with AI
Let's talk
Let's size up the potential for your helpdesk
A few minutes to identify the most useful use case — hosted in France, supervised, with no commitment.