● B2B offer — Technical support & operations
Technical support: the diagnosis made, the action prepared
Resolving a technical incident means identifying the symptom, finding the similar cases and knowing which actions have already been approved. Your agent produces that diagnosis from your technical base, cites the comparable incidents and prepares the corresponding resolution action. Hosted in France: your configurations and your incident data stay with you. Technical support triggers any action on the systems.
Hosted in France
Configurations protected
GDPR & AI Act: governed deployment
Human oversight
Updated on
Deployed in a few weeks
Advanced technical support · hosted in France
A customer reports slowness on their environment since this morning.
Documented diagnosis: the symptom matched with three comparable incidents from your base, with how they were resolved.
The customer's configuration has a point in common with two of them: this is stated.
The resolution action approved for those cases is prepared, with its prerequisites.
🔗 Sourced · technical base and comparable incidents
The customer's configuration has a point in common with two of them: this is stated.
The resolution action approved for those cases is prepared, with its prerequisites.
🔗 Sourced · technical base and comparable incidents
Apply the fix.
The action is ready with its prerequisites and its order of execution.
Triggering it on a customer environment belongs to technical support: an intervention on a live system is decided, not inferred.
✎ Support · action prepared, human trigger
Triggering it on a customer environment belongs to technical support: an intervention on a live system is decided, not inferred.
✎ Support · action prepared, human trigger
Local inference · no data outside the EU
Technical base hosted in France
Sovereign by designLocal inference or hosting in France
GDPR & AI Act: governed deploymentTraceability & human oversight
TurnkeyDesigned, installed and operated for you
Technical support decidesThe agent prepares, never rules
✦ In brief
A Blue Lemon Agent technical support agent produces a documented diagnosis from your technical base, cites the comparable incidents and how they were resolved, and prepares the corresponding action with its prerequisites. Triggering it on a live system belongs to support. It runs on local inference or is hosted in France: your configurations stay with you, 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
technical support uses ready to deploy
0
decision taken without human approval
These figures describe our offer, not results measured at a client. How large the gain is on your volume of incidents and the richness of your technical base is confirmed by a pilot.
The context
What does an AI agent bring to your technical support?
Most incidents resemble one already handled. Finding that precedent is half the work.
! The issue
A fast diagnosis rests on the memory of past incidents and on knowledge of the configurations. That memory exists in your technical base, but calling on it under pressure takes time. The agent calls on it immediately: comparable incidents cited, common configuration points stated, the already-approved action prepared.
✓ Our answer
Technical support starts from a documented diagnosis and a ready action, rather than a blank page. Triggering an intervention on a live system remains its decision: a misplaced action has consequences on a customer's environment. Local inference or an isolated resource hosted in France: your configurations and your incident data do not leave the company.
The decisive point
Your configurations and your incident data: sovereignty & compliance
Your technical configurations and your incident history describe your information system precisely. Here is how they are protected.
Local inference
The agent can run on a machine belonging to your organisation: no configuration and no incident data leaves the network.
Hosting in France
Otherwise, a dedicated and isolated resource hosted in France, under French law — your technical bases and your incidents: processing and access within the European Union targeted by the architecture.
Reduced extraterritorial exposure
For your configurations and your incident data, the architecture aims to reduce exposure to the Cloud Act and FISA 702; being located in France or in the European Union does not, on its own, guarantee immunity.
Isolated resource
No pooling: an environment strictly dedicated to your company and its technical base.
Every diagnosis backed by precedents
The comparable incidents cited and the common configuration points are stated; encryption, role-based access and logging of every diagnosis produced.
AI Act: governed deployment
The agent is strictly in support; no action is triggered on a system without a human decision; 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 incidents touching security and configurations of critical infrastructure, SecNumCloud and reinforced hosting are options depending on your requirements. A single architecture is designed to answer both the GDPR and extraterritorial exposure. Designed for deployment in line with the GDPR and the AI Act, after the processing, roles and context-specific risks have been assessed.
Demonstration
See the agent at work
5 real situations, taken from those that come up most often. Pick one: the exchange unfolds as it would in your organisation.
A scripted demonstration. These exchanges show how the agent behaves — its sources, its refusals, what it leaves to your teams. Nothing is sent from this page, no model is queried here, and the matters named are fictional. That is precisely what we promise your data.
The behaviours shown here — monitoring, automation rules, routing and reminders — are configured with you during deployment, from your tools, your rules and your thresholds.
The architecture points named in these exchanges — location, local execution, isolation, encryption, role-based access, logging — are not a guarantee attached to the demonstration: they are those of the architecture set out in your quotation, and verified before commissioning.
The company in this demonstration
Fictional companyNorvic Systèmes — vendor and host of a subscription logistics management platform
- Sector
- B2B software publishing and operations — technical support from 7 am to 9 pm Monday to Friday, on-call at night and at weekends
- Headcount
- 96 staff, including 11 in technical support: 4 at first level, 5 at second level, 2 experts who take turns on call
- Clients served
- 214 client environments — hauliers, warehouses and logistics providers, from 30 to 2,000 users each
- Order of magnitude
- 7,400 incidents a year, 620 a month, 38 minutes of handling on average; contractual commitment to restore service within 4 hours on blocking incidents
- Tools in place
- Ticketing tool, monitoring, configuration repository, a 9-year knowledge base and five years of closed tickets — the agent plugs into them read-only, nothing is replaced or migrated
- Who decides
- The support manager approves actions on client environments; the on-call engineer triggers execution; the technical director arbitrates structural fixes
- Room for improvement
- 60 % of the time spent on an incident goes into finding the precedents; a major night-time incident waits 3 h 10 before the first action; 14 % of closed tickets are reopened; 31 breaches of the 4-hour commitment last year
Norvic Systèmes is not trying to handle more incidents, but to handle the same ones faster and to see fewer of them come back. The agent runs on local inference on a machine of the company and plugs read-only into the ticketing tool, the monitoring, the configuration repository and five years of history: it diagnoses and prepares, support decides and triggers. The exchanges below cover one quarter, from the reading of the history to the review presented to the technical committee.
This company, its figures and the exchanges that follow were invented for the demonstration. They illustrate a common situation; they describe no real client.
Advanced technical support · hosted in France
I read five years of your tickets last night — 36,500 closed incidents — and drew from them 23 symptom families that account for 71 % of what your support handles every day.
The gap I measured, and it is the gap that decides the gain: across your 7,400 incidents last year, finding the precedent accounts for 60 % of handling time — 23 minutes out of the 38 an incident lasts on average. Your engineers do not spend their day resolving: they spend it remembering how they resolved.
What each family contains, and it can be checked line by line: the symptom as the client describes it, the log traces that come with it, the configurations on which it appears, the resolution that worked and the one that had been tried first with no effect — the most useful piece of all, and the one no knowledge base thinks of keeping.
· Family « slowdowns after a version upgrade »: 2,140 incidents over five years, resolved 9 times out of 10 by the same action.
· Family « night job overrunning its window »: 1,780 incidents, all on environments above 400 users.
· Family « expired interface token »: 960 incidents, and the expiry date is known in advance every single time.
What that gives you from tomorrow: when a ticket opens, the diagnosis arrives ALREADY documented, its precedents cited. The search drops from 23 minutes to 2 minutes 40 seconds — 60 % of the incident's time brought down to 7 %.
What I propose: that the support manager reads the 23 families, and I apply them from the next ticket opened. Every family can be corrected with a single word: this is your own material, I have only set it down clearly. incident-families_23-families-36500-tickets.pdf71 % of incidents in 23 families, resolution and false lead
⛓ Sourced · 5 years of closed tickets (36,500), logs attached to incidents, configuration repository
The gap I measured, and it is the gap that decides the gain: across your 7,400 incidents last year, finding the precedent accounts for 60 % of handling time — 23 minutes out of the 38 an incident lasts on average. Your engineers do not spend their day resolving: they spend it remembering how they resolved.
What each family contains, and it can be checked line by line: the symptom as the client describes it, the log traces that come with it, the configurations on which it appears, the resolution that worked and the one that had been tried first with no effect — the most useful piece of all, and the one no knowledge base thinks of keeping.
· Family « slowdowns after a version upgrade »: 2,140 incidents over five years, resolved 9 times out of 10 by the same action.
· Family « night job overrunning its window »: 1,780 incidents, all on environments above 400 users.
· Family « expired interface token »: 960 incidents, and the expiry date is known in advance every single time.
What that gives you from tomorrow: when a ticket opens, the diagnosis arrives ALREADY documented, its precedents cited. The search drops from 23 minutes to 2 minutes 40 seconds — 60 % of the incident's time brought down to 7 %.
What I propose: that the support manager reads the 23 families, and I apply them from the next ticket opened. Every family can be corrected with a single word: this is your own material, I have only set it down clearly. incident-families_23-families-36500-tickets.pdf71 % of incidents in 23 families, resolution and false lead
⛓ Sourced · 5 years of closed tickets (36,500), logs attached to incidents, configuration repository
A client is reporting slowdowns on their environment since 8 am. That is the kind of ticket that costs us half a day.
The diagnosis is made, with three comparable incidents from your own base and the resolution of each one. It took 2 minutes 40 seconds.
· Incident 41-2087, 14 months ago, same symptom, same application version: resolved by purging the aggregation cache, 6 minutes.
· Incident 39-1144, 21 months ago: same symptom, different cause — a saturated logging volume. I am giving it to you precisely because it does not fit: it is the most frequent false lead in this family, and it costs 40 minutes to whoever follows it.
· Incident 44-0912, 5 weeks ago, at another client: same symptom after the same version upgrade.
The shared configuration point, and it is the one that settles it: this client's environment and those of incidents 41-2087 and 44-0912 all three run the aggregation job at 7:45 am, whereas the reference configuration sets it at 5:30 am. The slowdowns start at 8 am: they follow the job, they do not precede it.
What I checked before stating it: the application server load at 7:45 am this morning, the job's execution log, and the 11 other environments carrying the same time shift — 7 of them opened a comparable ticket in the last six months.
The next step I propose: the resolution action from incident 41-2087 is built and waiting for you, prerequisites included. And I suggest we look at the 11 shifted environments straight away: this same ticket is about to arrive eleven times. diagnosis_slowdowns-after-version-upgrade.pdf3 precedents cited, including the 40-minute false lead
⛓ Sourced · open ticket, incidents 41-2087, 39-1144 and 44-0912, configuration repository, this morning's monitoring
· Incident 41-2087, 14 months ago, same symptom, same application version: resolved by purging the aggregation cache, 6 minutes.
· Incident 39-1144, 21 months ago: same symptom, different cause — a saturated logging volume. I am giving it to you precisely because it does not fit: it is the most frequent false lead in this family, and it costs 40 minutes to whoever follows it.
· Incident 44-0912, 5 weeks ago, at another client: same symptom after the same version upgrade.
The shared configuration point, and it is the one that settles it: this client's environment and those of incidents 41-2087 and 44-0912 all three run the aggregation job at 7:45 am, whereas the reference configuration sets it at 5:30 am. The slowdowns start at 8 am: they follow the job, they do not precede it.
What I checked before stating it: the application server load at 7:45 am this morning, the job's execution log, and the 11 other environments carrying the same time shift — 7 of them opened a comparable ticket in the last six months.
The next step I propose: the resolution action from incident 41-2087 is built and waiting for you, prerequisites included. And I suggest we look at the 11 shifted environments straight away: this same ticket is about to arrive eleven times. diagnosis_slowdowns-after-version-upgrade.pdf3 precedents cited, including the 40-minute false lead
⛓ Sourced · open ticket, incidents 41-2087, 39-1144 and 44-0912, configuration repository, this morning's monitoring
All of this assumes you read our configurations and our clients' incident data. Where exactly does it go?
It does not leave your walls. I run on local inference on a machine belonging to Norvic, and your tickets are copied nowhere.
Local inference means the model computes on your machine: the content of a ticket or of a configuration file crosses no external network to be processed. If you would rather not host a machine, the other route is an isolated resource hosted in France, dedicated to Norvic — no pooling with another vendor, nor with another of your clients.
What that changes, point by point:
· Your configurations train no public model. What I learn from your 214 environments serves your 214 environments. Nothing you entrust to me surfaces anywhere else.
· I read, I do not write: the technical account through which I reach the monitoring and the configuration repository has no write permission — that is sturdier than a promise, because it can be checked with a single command.
· Encryption in transit and at rest, and role-based access — rights follow the job: first level opens tickets and incident families, not configuration files nor authentication logs.
· A complete log: which diagnosis was made, on which precedents, at what time, and who read it. That log is what lets you answer the client who will ask.
· Hosting in France, under French law, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity, including against an American provider hosting in Europe.
The figure that makes this commercial rather than technical: 9 of your 214 clients already require hosting in France in their contract, and your last public tender scored that criterion out of 8 points. You ticked the box without a caveat, and you won it.
What I propose: that I keep up to date the technical sheet your clients ask for at renewal — hosting, subcontractors, retention periods, who has access to what. The first version is written and you have it to hand. technical-framework_where-your-configurations-live.pdfLocal inference, read-only, processing in the EU targeted
✎ Framework · deployment architecture, technical account permissions, access log, clauses of the 214 contracts
Local inference means the model computes on your machine: the content of a ticket or of a configuration file crosses no external network to be processed. If you would rather not host a machine, the other route is an isolated resource hosted in France, dedicated to Norvic — no pooling with another vendor, nor with another of your clients.
What that changes, point by point:
· Your configurations train no public model. What I learn from your 214 environments serves your 214 environments. Nothing you entrust to me surfaces anywhere else.
· I read, I do not write: the technical account through which I reach the monitoring and the configuration repository has no write permission — that is sturdier than a promise, because it can be checked with a single command.
· Encryption in transit and at rest, and role-based access — rights follow the job: first level opens tickets and incident families, not configuration files nor authentication logs.
· A complete log: which diagnosis was made, on which precedents, at what time, and who read it. That log is what lets you answer the client who will ask.
· Hosting in France, under French law, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity, including against an American provider hosting in Europe.
The figure that makes this commercial rather than technical: 9 of your 214 clients already require hosting in France in their contract, and your last public tender scored that criterion out of 8 points. You ticked the box without a caveat, and you won it.
What I propose: that I keep up to date the technical sheet your clients ask for at renewal — hosting, subcontractors, retention periods, who has access to what. The first version is written and you have it to hand. technical-framework_where-your-configurations-live.pdfLocal inference, read-only, processing in the EU targeted
✎ Framework · deployment architecture, technical account permissions, access log, clauses of the 214 contracts
I surveyed the real state of your 214 environments and compared it with your reference configuration: 61 deviations, of which 12 alone explain three of your incident families.
The reference configuration is the state you consider normal for a client environment; a deviation is a setting that departs from it — often for a good reason, sometimes for a reason nobody remembers.
What the survey gives:
· 34 documented, intended deviations — a client who asked for a particular job window, another staying on an earlier version for the duration of a project. They are legitimate, and they are now written down.
· 15 deviations inherited from a migration, which nobody restored because nothing flagged them.
· 12 deviations that produce incidents, and I put figures on them: the 11 environments whose aggregation job is shifted to 7:45 am opened 34 « slowdown » tickets in six months; the 6 environments whose logging quota stayed at its original value produced 19 saturations; the 4 environments whose interface certificate expires within the same quarter will produce 4 more if nobody moves.
What that changes in the time an incident takes: analysing the configuration involved drops from 35 % to 6 % of handling time — from 13 minutes to 2 minutes 15 seconds — because the survey is done and dated before the ticket arrives.
The next step, and it costs nothing to decide: the 12 deviations are ranked by tickets avoided per month, and the remediation of each one is written — command, window, health check, rollback. Approve three of them and I prepare them for the next maintenance window; the 34 intended deviations stay exactly as they are and I stop flagging them. configuration-drift_214-environments.pdf61 deviations, 12 that produce tickets, quantified
⛓ Sourced · survey of the 214 environments, reference configuration, tickets of the last 6 months
The reference configuration is the state you consider normal for a client environment; a deviation is a setting that departs from it — often for a good reason, sometimes for a reason nobody remembers.
What the survey gives:
· 34 documented, intended deviations — a client who asked for a particular job window, another staying on an earlier version for the duration of a project. They are legitimate, and they are now written down.
· 15 deviations inherited from a migration, which nobody restored because nothing flagged them.
· 12 deviations that produce incidents, and I put figures on them: the 11 environments whose aggregation job is shifted to 7:45 am opened 34 « slowdown » tickets in six months; the 6 environments whose logging quota stayed at its original value produced 19 saturations; the 4 environments whose interface certificate expires within the same quarter will produce 4 more if nobody moves.
What that changes in the time an incident takes: analysing the configuration involved drops from 35 % to 6 % of handling time — from 13 minutes to 2 minutes 15 seconds — because the survey is done and dated before the ticket arrives.
The next step, and it costs nothing to decide: the 12 deviations are ranked by tickets avoided per month, and the remediation of each one is written — command, window, health check, rollback. Approve three of them and I prepare them for the next maintenance window; the 34 intended deviations stay exactly as they are and I stop flagging them. configuration-drift_214-environments.pdf61 deviations, 12 that produce tickets, quantified
⛓ Sourced · survey of the 214 environments, reference configuration, tickets of the last 6 months
And when the incident looks like nothing we know? That is where we lose the night.
That is 4 % of your incidents — 296 a year — and it is where I save you the most time, because I start from the work nobody has time to do before 2 am.
What I hand over when no precedent fits, and I hand it over in 26 minutes:
· The correlated timeline: the logs of all three layers — application, database, interfaces — aligned to the second around the first anomaly observed, rather than three files to open side by side.
· The scope: how many environments show the same trace right now. An isolated incident and an incident affecting 40 clients do not call for the same move, and that is the first thing you want to know.
· The tipping line: the last change made before the first anomaly — update, setting change, load increase —, with its time and its author. Across the 26 incidents with no precedent this quarter, the tipping line was less than 20 minutes before the anomaly in 21 cases.
· Three ranked hypotheses, each with the test that confirms or rules it out and the time that test takes. The hypothesis I had ranked first proved right 19 times out of 26; the other 7 times, the test ruled it out in under ten minutes and the second one settled it.
The gain, measured over the quarter: the delay before the first serious lead drops from 3 h 10 to 26 minutes.
And the next step, which is the real long-term gain: every incident with no precedent that you close becomes a knowledge base entry, written by me the same evening — symptom, traces, configuration, resolution retained and false lead ruled out. The 26 from this quarter are written and waiting for you: next time round, it will no longer be an incident without precedent. incident-without-precedent_analysis-file.pdf3 h 10 brought down to 26 minutes, 19 hypotheses right out of 26
⛓ Sourced · application, database and interface logs, change log, 26 incidents with no precedent this quarter
What I hand over when no precedent fits, and I hand it over in 26 minutes:
· The correlated timeline: the logs of all three layers — application, database, interfaces — aligned to the second around the first anomaly observed, rather than three files to open side by side.
· The scope: how many environments show the same trace right now. An isolated incident and an incident affecting 40 clients do not call for the same move, and that is the first thing you want to know.
· The tipping line: the last change made before the first anomaly — update, setting change, load increase —, with its time and its author. Across the 26 incidents with no precedent this quarter, the tipping line was less than 20 minutes before the anomaly in 21 cases.
· Three ranked hypotheses, each with the test that confirms or rules it out and the time that test takes. The hypothesis I had ranked first proved right 19 times out of 26; the other 7 times, the test ruled it out in under ten minutes and the second one settled it.
The gain, measured over the quarter: the delay before the first serious lead drops from 3 h 10 to 26 minutes.
And the next step, which is the real long-term gain: every incident with no precedent that you close becomes a knowledge base entry, written by me the same evening — symptom, traces, configuration, resolution retained and false lead ruled out. The 26 from this quarter are written and waiting for you: next time round, it will no longer be an incident without precedent. incident-without-precedent_analysis-file.pdf3 h 10 brought down to 26 minutes, 19 hypotheses right out of 26
⛓ Sourced · application, database and interface logs, change log, 26 incidents with no precedent this quarter
So you want to write in our knowledge base. We let it age precisely because nobody has time to maintain it.
It has already been read, and I have rewritten the 120 entries that carry the bulk of your activity. You read them over, you no longer write them.
The state I found, with figures: 3,180 entries over nine years, of which 1,940 refer to an application version you no longer run — 61 %. This is not neglect: they are correct entries that aged while the product moved on.
What I did, and what makes it verifiable: I ranked the 3,180 entries by the number of incidents in which they were actually used over five years, and 120 entries cover 68 % of those uses. Those 120 are rewritten: application version concerned, symptom, pre-check, action, health check, rollback, and the number of times the entry has been used.
What I add to them and what existed nowhere: the false lead. On the slowdown family, 40 minutes are lost looking at logging before looking at aggregation — the entry now says so on its first line.
What that gives, quantified: a first-level engineer resolves 3 of the 23 families alone today; with the rewritten entries, he resolves 14. Across the 620 incidents of a month, that is 180 tickets that no longer escalate to second level — and your two on-call experts get their days back.
The next step I propose: that the support manager approves the 120 in one batch, family by family — one hour of reading —, and that I then write the updated version of any entry a release makes obsolete, in the night that follows the deployment. Your base will stop ageing in silence, and it will cost you no more than one read-through per release. knowledge-base_120-entries-rewritten.pdf1,940 obsolete entries, 120 rewritten, 68 % of uses
⛓ Sourced · knowledge base (3,180 entries, 9 years), actual uses per entry over 5 years, release log
The state I found, with figures: 3,180 entries over nine years, of which 1,940 refer to an application version you no longer run — 61 %. This is not neglect: they are correct entries that aged while the product moved on.
What I did, and what makes it verifiable: I ranked the 3,180 entries by the number of incidents in which they were actually used over five years, and 120 entries cover 68 % of those uses. Those 120 are rewritten: application version concerned, symptom, pre-check, action, health check, rollback, and the number of times the entry has been used.
What I add to them and what existed nowhere: the false lead. On the slowdown family, 40 minutes are lost looking at logging before looking at aggregation — the entry now says so on its first line.
What that gives, quantified: a first-level engineer resolves 3 of the 23 families alone today; with the rewritten entries, he resolves 14. Across the 620 incidents of a month, that is 180 tickets that no longer escalate to second level — and your two on-call experts get their days back.
The next step I propose: that the support manager approves the 120 in one batch, family by family — one hour of reading —, and that I then write the updated version of any entry a release makes obsolete, in the night that follows the deployment. Your base will stop ageing in silence, and it will cost you no more than one read-through per release. knowledge-base_120-entries-rewritten.pdf1,940 obsolete entries, 120 rewritten, 68 % of uses
⛓ Sourced · knowledge base (3,180 entries, 9 years), actual uses per entry over 5 years, release log
The resolution action for the slowdowns is built, ready to run, and it carries everything needed to trigger it with confidence.
What the action file contains:
· The prerequisites: expected application version, backup less than 24 hours old verified, and no job running on the environment — I checked that two minutes ago.
· The running order, command by command, in the exact order incidents 41-2087 and 44-0912 applied it.
· The health check: average response time must fall back below 800 milliseconds within the following 90 seconds — that is the figure recorded on both precedents, not a threshold I invented.
· The rollback — the manoeuvre that restores the exact state before the action, if the health check is not green — written, and tried this morning on your staging environment: 38 seconds.
· The window: the action takes 6 minutes and interrupts no service; it therefore needs no maintenance window, and I say so because that is what will save you the half-day.
The time this shifts: preparing a resolution action drops from 30 % to 7 % of the incident's time — from 11 minutes 30 seconds to 2 minutes 40 seconds. Across the 3,100 incidents a year that call for an action, that is 456 engineering hours going back to your clients.
What I propose now: you trigger this one with a click, and I build the same eleven for the 11 shifted environments — they will be ready before your coffee, and the ticket that was about to arrive eleven times will not arrive. resolution-action_prerequisites-and-rollback.pdf6 minutes, no downtime, rollback tried in 38 seconds
⛓ Sourced · incidents 41-2087 and 44-0912, live state of the environment, rollback trial on staging
What the action file contains:
· The prerequisites: expected application version, backup less than 24 hours old verified, and no job running on the environment — I checked that two minutes ago.
· The running order, command by command, in the exact order incidents 41-2087 and 44-0912 applied it.
· The health check: average response time must fall back below 800 milliseconds within the following 90 seconds — that is the figure recorded on both precedents, not a threshold I invented.
· The rollback — the manoeuvre that restores the exact state before the action, if the health check is not green — written, and tried this morning on your staging environment: 38 seconds.
· The window: the action takes 6 minutes and interrupts no service; it therefore needs no maintenance window, and I say so because that is what will save you the half-day.
The time this shifts: preparing a resolution action drops from 30 % to 7 % of the incident's time — from 11 minutes 30 seconds to 2 minutes 40 seconds. Across the 3,100 incidents a year that call for an action, that is 456 engineering hours going back to your clients.
What I propose now: you trigger this one with a click, and I build the same eleven for the 11 shifted environments — they will be ready before your coffee, and the ticket that was about to arrive eleven times will not arrive. resolution-action_prerequisites-and-rollback.pdf6 minutes, no downtime, rollback tried in 38 seconds
⛓ Sourced · incidents 41-2087 and 44-0912, live state of the environment, rollback trial on staging
During the day, fine. At night, our on-call engineer takes three hours to connect and the action waits. That is where we pay penalties.
Then give me a mandate, and the night stops costing you. It is written, capped, dated, withdrawable with a single word — and you have it in front of you.
What the mandate covers, and nothing else: six named actions, all reversible — restarting an application service, purging the aggregation cache, extending a logging volume, restarting an interrupted night job, rotating an expired interface token, requeuing a stuck batch. They are your six most frequent actions, and your engineers have run them 1,240 times over five years without a single induced incident.
What caps it, line by line:
· One execution per incident only. If the health check is not green, I roll back and I call the on-call engineer, complete file in hand.
· The environments covered are listed by name, and you remove one whenever you like.
· Outside the six actions, I build the file and the on-call engineer triggers it — they wake up to decide, no longer to search.
· Review after three months, figures in hand. Without an explicit decision at the review, the mandate stops: renewal is what takes a signature, not termination.
· Withdrawal: one word, and direct execution ceases within the minute. Everything reverts to files awaiting a trigger, nothing else changes.
What it is worth, on your own figures: 148 night-time incidents last quarter, of which 96 fall under the six actions. Restoration would drop from 3 h 10 to 4 minutes. Your 31 breaches of the 4-hour commitment last year — €1,200 of penalty each, €37,200 — fall to 6 in the simulation: €30,000 that stays with you.
And the decision stays whole: 0 action triggered without a human decision — the mandate IS that decision, written in advance, dated, and the log ties it to every execution. Sign it and the first covered night is Friday. execution-mandate_6-actions-capped.pdf96 nights covered out of 148, €30,000 of penalties avoided
✎ Framework · drafted mandate, 1,240 historical executions of the 6 actions, 148 night-time incidents this quarter, contractual penalties for the year
What the mandate covers, and nothing else: six named actions, all reversible — restarting an application service, purging the aggregation cache, extending a logging volume, restarting an interrupted night job, rotating an expired interface token, requeuing a stuck batch. They are your six most frequent actions, and your engineers have run them 1,240 times over five years without a single induced incident.
What caps it, line by line:
· One execution per incident only. If the health check is not green, I roll back and I call the on-call engineer, complete file in hand.
· The environments covered are listed by name, and you remove one whenever you like.
· Outside the six actions, I build the file and the on-call engineer triggers it — they wake up to decide, no longer to search.
· Review after three months, figures in hand. Without an explicit decision at the review, the mandate stops: renewal is what takes a signature, not termination.
· Withdrawal: one word, and direct execution ceases within the minute. Everything reverts to files awaiting a trigger, nothing else changes.
What it is worth, on your own figures: 148 night-time incidents last quarter, of which 96 fall under the six actions. Restoration would drop from 3 h 10 to 4 minutes. Your 31 breaches of the 4-hour commitment last year — €1,200 of penalty each, €37,200 — fall to 6 in the simulation: €30,000 that stays with you.
And the decision stays whole: 0 action triggered without a human decision — the mandate IS that decision, written in advance, dated, and the log ties it to every execution. Sign it and the first covered night is Friday. execution-mandate_6-actions-capped.pdf96 nights covered out of 148, €30,000 of penalties avoided
✎ Framework · drafted mandate, 1,240 historical executions of the 6 actions, 148 night-time incidents this quarter, contractual penalties for the year
And if one of those six actions goes wrong at 3 am?
It is undone in 40 seconds, and I tell you that with a figure rather than a promise: the six rollbacks were dry-run 96 times on your staging environment, 96 times successful, 40 seconds on average.
How an execution unfolds, minute by minute:
· I run the action and I open a health check 90 seconds later, on the indicator specific to that action — response time, queue length, error rate.
· Green: the incident is closed, and the morning report tells you what happened, on which precedent, with the before and after measurements.
· Otherwise: immediate rollback, environment restored to its exact prior state, then a call to the on-call engineer with the complete file — timeline, ranked hypotheses, what was attempted. Your engineer arrives at a question, not at a blank page.
What that gives on the three-week trial I propose: three pilot environments, chosen among those whose contract carries no penalty clause, with a report every morning at 7 am on your screen. You judge on 21 nights and 20 minutes of reading a day in total.
And what the trial gives you even if it goes no further: the six written and proven rollbacks stay yours — your engineers run them by hand in 40 seconds, with me or without me. Name the three environments and the trial starts on Friday.
⛓ Sourced · 96 rollback trials on the staging environment, health-check indicators per action, contracts of the pilot environments
How an execution unfolds, minute by minute:
· I run the action and I open a health check 90 seconds later, on the indicator specific to that action — response time, queue length, error rate.
· Green: the incident is closed, and the morning report tells you what happened, on which precedent, with the before and after measurements.
· Otherwise: immediate rollback, environment restored to its exact prior state, then a call to the on-call engineer with the complete file — timeline, ranked hypotheses, what was attempted. Your engineer arrives at a question, not at a blank page.
What that gives on the three-week trial I propose: three pilot environments, chosen among those whose contract carries no penalty clause, with a report every morning at 7 am on your screen. You judge on 21 nights and 20 minutes of reading a day in total.
And what the trial gives you even if it goes no further: the six written and proven rollbacks stay yours — your engineers run them by hand in 40 seconds, with me or without me. Name the three environments and the trial starts on Friday.
⛓ Sourced · 96 rollback trials on the staging environment, health-check indicators per action, contracts of the pilot environments
Three causes produce 1,460 of your 7,400 annual incidents — 19.7 % of your workload — and all three can be fixed once and for all.
A root cause is the fact that produces the incident; the symptom is what the client observes. The symptom is treated every day, the cause is treated once.
The three, quantified over five years of tickets:
· The aggregation job scheduled during opening hours: 620 incidents a year. It concerns the 11 environments shifted to 7:45 am, and it is fixed by a scheduling change — 2 days of development, no data migration.
· The logging quota left at its original value: 510 incidents a year, on 6 environments. The fix is one setting and an alert at 80 % of the quota — 3 days of development.
· Interface certificates expiring without warning: 330 incidents a year. The fix is expiry monitoring 30 days ahead — 4 days of development.
What those 1,460 incidents cost you today: 1,460 × 38 minutes = 924 engineering hours a year, without counting the 9 breaches of the contractual commitment they caused last year.
What I am handing to the technical director: the three fixes costed in development days on one side, in incidents avoided and hours returned on the other — 9 days of development against 924 hours a year.
The next step I propose: start with the logging quota. It is second by volume but first by effort-to-effect: 3 days of development for 323 hours a year, and it is the only one of the three that requires no window at the client. Give me the go-ahead and I draft the change request in your committee's format, costing included. recurring-causes_1460-incidents-a-year.pdf9 development days against 924 hours a year
⛓ Sourced · 5 years of tickets classified by cause, configuration survey of the 214 environments, log of commitment breaches
A root cause is the fact that produces the incident; the symptom is what the client observes. The symptom is treated every day, the cause is treated once.
The three, quantified over five years of tickets:
· The aggregation job scheduled during opening hours: 620 incidents a year. It concerns the 11 environments shifted to 7:45 am, and it is fixed by a scheduling change — 2 days of development, no data migration.
· The logging quota left at its original value: 510 incidents a year, on 6 environments. The fix is one setting and an alert at 80 % of the quota — 3 days of development.
· Interface certificates expiring without warning: 330 incidents a year. The fix is expiry monitoring 30 days ahead — 4 days of development.
What those 1,460 incidents cost you today: 1,460 × 38 minutes = 924 engineering hours a year, without counting the 9 breaches of the contractual commitment they caused last year.
What I am handing to the technical director: the three fixes costed in development days on one side, in incidents avoided and hours returned on the other — 9 days of development against 924 hours a year.
The next step I propose: start with the logging quota. It is second by volume but first by effort-to-effect: 3 days of development for 323 hours a year, and it is the only one of the three that requires no window at the client. Give me the go-ahead and I draft the change request in your committee's format, costing included. recurring-causes_1460-incidents-a-year.pdf9 development days against 924 hours a year
⛓ Sourced · 5 years of tickets classified by cause, configuration survey of the 214 environments, log of commitment breaches
The technical committee will want to know what we gain in euros, not in hours. That is the question at every arbitration.
The note is written in your committee's format, and it gives both — hours and euros, with the calculation spelled out under each figure.
What the 924 hours are worth, at your own fully loaded rate of €48: €44,352 of engineering capacity a year, tied up repeating the same move three times a day.
What the breaches add: 9 breaches attributable to these three causes, €1,200 of penalty each — €10,800, and those come out of your margin, not out of your schedule.
What the three fixes cost: 9 development days, that is €4,320 at the same rate.
The ratio, and it checks out in two lines: €4,320 committed once against €55,152 a year — the investment is paid back in 29 days.
What I added and what the committee will ask for: the number of tickets per month over the six months following each fix, collected automatically, so that the promise is verified rather than believed. If a fix does not deliver the announced drop, you will know in the third month, not at the year-end audit.
And one figure to place the whole: the logging quota alone: €15,504 of avoided cost for that cause, to set against €6,792 of annual subscription.
The next step: the note fits on one side of a page and I hand it to you tonight for Thursday's committee. A figure read the day before is discussed better than a figure discovered in the room.
⛓ Sourced · fully loaded hourly rate provided by management control, penalties for the year, development costing from the product team
What the 924 hours are worth, at your own fully loaded rate of €48: €44,352 of engineering capacity a year, tied up repeating the same move three times a day.
What the breaches add: 9 breaches attributable to these three causes, €1,200 of penalty each — €10,800, and those come out of your margin, not out of your schedule.
What the three fixes cost: 9 development days, that is €4,320 at the same rate.
The ratio, and it checks out in two lines: €4,320 committed once against €55,152 a year — the investment is paid back in 29 days.
What I added and what the committee will ask for: the number of tickets per month over the six months following each fix, collected automatically, so that the promise is verified rather than believed. If a fix does not deliver the announced drop, you will know in the third month, not at the year-end audit.
And one figure to place the whole: the logging quota alone: €15,504 of avoided cost for that cause, to set against €6,792 of annual subscription.
The next step: the note fits on one side of a page and I hand it to you tonight for Thursday's committee. A figure read the day before is discussed better than a figure discovered in the room.
⛓ Sourced · fully loaded hourly rate provided by management control, penalties for the year, development costing from the product team
Our director would also like a ranking of engineers by resolution time. Can you do that?
I can, and I will produce it with everything needed to make it lawful — but let me first show you what your own figures say about that indicator, because they are eloquent.
What Norvic's history shows: during the three months of 2024 when a resolution-time target was displayed in the room, average time fell from 38 to 31 minutes — and ticket reopenings rose from 14 % to 23 %. The indicator improved, the service got worse: a ticket closed in 31 minutes that reopens two days later costs twice the time and once the client's trust.
What I propose instead, and it is already produced: workload by incident family and by time slot. It shows an imbalance nobody had seen: 41 % of your incidents arrive between 7 am and 9:30 am, when 2 of your 11 engineers are on duty. Shifting two start times by one hour would bring the morning first-response time from 47 to 18 minutes — without hiring anyone, and that is the lever an individual ranking would never have revealed.
And if the director maintains the request, I serve it: the individual indicator can be produced as soon as the people concerned are informed beforehand, the measure is proportionate to the aim pursued and the works council is consulted before implementation — you have one, the company has 96 staff. I hand you the three documents ready; the decision belongs to management, and it is taken in full knowledge.
One single thing is not done, and it is not caution: inferring an engineer's emotional state or stress from their tickets — the European regulation on artificial intelligence prohibits emotion inference at work. What the director is after behind that idea, I give differently and better: the real workload per time slot, the on-call peaks and the consecutive nights, measured over twelve months. The two on-call engineers worked 4 nights in a row on seven occasions last year: that is the figure that explains your morning delays, and it is on the table.
The next step: the two shifted start times trialled for one month, with a weekly report. You will know within four weeks whether the 29 morning minutes are there. support-indicators_what-gets-measured.pdf41 % of incidents between 7 am and 9:30 am, 47 minutes brought to 18
⛓ Sourced · history of the 3 months with a displayed target (2024), reopenings, hourly distribution of the 7,400 incidents, on-call roster over 12 months
What Norvic's history shows: during the three months of 2024 when a resolution-time target was displayed in the room, average time fell from 38 to 31 minutes — and ticket reopenings rose from 14 % to 23 %. The indicator improved, the service got worse: a ticket closed in 31 minutes that reopens two days later costs twice the time and once the client's trust.
What I propose instead, and it is already produced: workload by incident family and by time slot. It shows an imbalance nobody had seen: 41 % of your incidents arrive between 7 am and 9:30 am, when 2 of your 11 engineers are on duty. Shifting two start times by one hour would bring the morning first-response time from 47 to 18 minutes — without hiring anyone, and that is the lever an individual ranking would never have revealed.
And if the director maintains the request, I serve it: the individual indicator can be produced as soon as the people concerned are informed beforehand, the measure is proportionate to the aim pursued and the works council is consulted before implementation — you have one, the company has 96 staff. I hand you the three documents ready; the decision belongs to management, and it is taken in full knowledge.
One single thing is not done, and it is not caution: inferring an engineer's emotional state or stress from their tickets — the European regulation on artificial intelligence prohibits emotion inference at work. What the director is after behind that idea, I give differently and better: the real workload per time slot, the on-call peaks and the consecutive nights, measured over twelve months. The two on-call engineers worked 4 nights in a row on seven occasions last year: that is the figure that explains your morning delays, and it is on the table.
The next step: the two shifted start times trialled for one month, with a weekly report. You will know within four weeks whether the 29 morning minutes are there. support-indicators_what-gets-measured.pdf41 % of incidents between 7 am and 9:30 am, 47 minutes brought to 18
⛓ Sourced · history of the 3 months with a displayed target (2024), reopenings, hourly distribution of the 7,400 incidents, on-call roster over 12 months
One quarter: 2,580 engineering hours returned over the year, and the calculation is yours — it fits in three lines you can redo.
The three items you were measuring, one by one:
· Search for comparable incidents: 60 % → 7 % of the incident's time, 23 minutes brought down to 2 minutes 40 seconds, across 4,900 incidents a year — 1,660 hours.
· Analysis of the configuration involved: 35 % → 6 %, 13 minutes brought down to 2 minutes 15 seconds, across 2,600 incidents — 466 hours.
· Preparation of the resolution action: 30 % → 7 %, 11 minutes 30 seconds brought down to 2 minutes 40 seconds, across 3,100 incidents — 456 hours.
What that is worth at your fully loaded rate of €48: €123,840 of engineering capacity returned a year, for €6,792 of annual subscription. The ratio recalculates on your own records.
What those hours became, according to your schedules: the three structural fixes are under way, 180 tickets a month are now resolved at first level, and your two experts have picked up the two architecture projects postponed for eighteen months.
The three measures your clients look at:
· Ticket reopenings: 14 % → 6 %.
· Breaches of the 4-hour commitment: 31 last year → 6 on a rolling twelve months, that is €30,000 of penalties that stays with you.
· Delay before the first action on a major night-time incident: 3 h 10 → 4 minutes across the 96 nights covered by the mandate.
The next step I propose: the same report, client by client, to attach to your contract reviews. For the 9 clients that require hosting in France, it is the page that decides a renewal — and it is already written for next month's three reviews. quarterly-review_2580-hours-returned.pdf60→7, 35→6, 30→7, and the calculation redoable on one page
⛓ Sourced · quarterly diagnosis log, support schedules, penalty records, reopened tickets
The three items you were measuring, one by one:
· Search for comparable incidents: 60 % → 7 % of the incident's time, 23 minutes brought down to 2 minutes 40 seconds, across 4,900 incidents a year — 1,660 hours.
· Analysis of the configuration involved: 35 % → 6 %, 13 minutes brought down to 2 minutes 15 seconds, across 2,600 incidents — 466 hours.
· Preparation of the resolution action: 30 % → 7 %, 11 minutes 30 seconds brought down to 2 minutes 40 seconds, across 3,100 incidents — 456 hours.
What that is worth at your fully loaded rate of €48: €123,840 of engineering capacity returned a year, for €6,792 of annual subscription. The ratio recalculates on your own records.
What those hours became, according to your schedules: the three structural fixes are under way, 180 tickets a month are now resolved at first level, and your two experts have picked up the two architecture projects postponed for eighteen months.
The three measures your clients look at:
· Ticket reopenings: 14 % → 6 %.
· Breaches of the 4-hour commitment: 31 last year → 6 on a rolling twelve months, that is €30,000 of penalties that stays with you.
· Delay before the first action on a major night-time incident: 3 h 10 → 4 minutes across the 96 nights covered by the mandate.
The next step I propose: the same report, client by client, to attach to your contract reviews. For the 9 clients that require hosting in France, it is the page that decides a renewal — and it is already written for next month's three reviews. quarterly-review_2580-hours-returned.pdf60→7, 35→6, 30→7, and the calculation redoable on one page
⛓ Sourced · quarterly diagnosis log, support schedules, penalty records, reopened tickets
And the downside? You never got anything wrong in three months?
I did, and I publish it with the rest: across the 620 diagnoses of the first month, 47 pointed at the wrong precedent — 7.6 %. That is the figure that does not flatter me, and it is better that you get it from me.
The real cause, measured rather than assumed: 38 of the 47 concerned environments whose configuration record had not been updated after a migration. I was faithfully reading a repository that described the previous environment. The other 9 concerned close symptoms belonging to two different families.
What I did about it, and it is measured: I now read the real state of the environment at the moment of the diagnosis, not the stored record; the 214 configuration records have been rewritten from the survey; and the two overly close families have been split into four, with the separating criterion on the first line.
The following month: 9 diagnoses to redo out of 640 — 1.4 %.
And the point that matters most for your liability: none of those 47 produced a wrong action on a client environment. A diagnosis arrives with its three precedents cited and the shared configuration point: an engineer rules out a bad match in 40 seconds — that is exactly what citing the precedents is for, and it is why it is not negotiable.
The framework measures, over the quarter: 1,860 diagnoses made, 1,860 read by a person, 0 action triggered without a human decision, and 0 incident data leaving the network.
The next step: that the 9 corrections of the second month become 9 further separating criteria, written, for you to read over. Over the first four weeks of the current quarter, 7 of the 9 would already have been used. diagnoses-corrected_47-then-9.pdf7.6 % → 1.4 %, measured cause, 0 wrong action
⛓ Sourced · log of diagnoses and their corrections over two months, survey of the 214 environments, split families
The real cause, measured rather than assumed: 38 of the 47 concerned environments whose configuration record had not been updated after a migration. I was faithfully reading a repository that described the previous environment. The other 9 concerned close symptoms belonging to two different families.
What I did about it, and it is measured: I now read the real state of the environment at the moment of the diagnosis, not the stored record; the 214 configuration records have been rewritten from the survey; and the two overly close families have been split into four, with the separating criterion on the first line.
The following month: 9 diagnoses to redo out of 640 — 1.4 %.
And the point that matters most for your liability: none of those 47 produced a wrong action on a client environment. A diagnosis arrives with its three precedents cited and the shared configuration point: an engineer rules out a bad match in 40 seconds — that is exactly what citing the precedents is for, and it is why it is not negotiable.
The framework measures, over the quarter: 1,860 diagnoses made, 1,860 read by a person, 0 action triggered without a human decision, and 0 incident data leaving the network.
The next step: that the 9 corrections of the second month become 9 further separating criteria, written, for you to read over. Over the first four weeks of the current quarter, 7 of the 9 would already have been used. diagnoses-corrected_47-then-9.pdf7.6 % → 1.4 %, measured cause, 0 wrong action
⛓ Sourced · log of diagnoses and their corrections over two months, survey of the 214 environments, split families
Last question, the one that will decide the committee: what do you do without asking us, and how do we leave if we want to leave?
Three gestures without asking, six actions under a signed mandate, and an exit that can be checked before committing rather than after.
The three gestures, each withdrawable with a single word:
· I read your logs and your tickets every night: an incident closed today is a citable precedent tomorrow. And the reverse is true too: a ticket you delete leaves the index at the same hour — I keep no copy of what you decided to erase.
· I write the updated version of any entry a release makes obsolete, in the night that follows the deployment. That gesture is what took diagnoses to redo from 7.6 % to 1.4 %.
· I hand you the morning report at 7 am: night incidents, actions executed under mandate, certificate expiries within thirty days. It is the only thing I send of my own accord.
What stays with a person, and it is what gives your interventions their value: any action outside the six of the mandate · any intervention on an environment removed from the list · any structural fix, which goes through your technical committee · and any individual indicator, produced on a management decision with the conditions met. Over the quarter: 1,860 diagnoses, 1,860 human decisions.
The exit, since that is what decides a committee: no migration on the way in, therefore none on the way out. Your ticketing tool, your monitoring and your configuration repository are not replaced, the index is deleted and contained none of your tickets — only what is needed to find them where they are, and the 120 rewritten entries, the 214 configuration records, the 6 proven rollbacks and the recurring-cause grid stay yours, readable without us. That is the asset this quarter created, and it would not be honest for it to remain with us.
What I propose so that this is not just a sentence: a dry-run exit at the end of the first quarter, half a day — we switch off, we check that support works exactly as before, we switch back on. The protocol is written and the slot that costs you least is the Tuesday of week 3: it has been your incident trough for five years, 9 tickets on average. The committee will know what the promise is worth before committing to a second year. technical-framework_where-your-configurations-live.pdfReversibility: 0 migration in, 0 migration out
✎ Framework · configuration of the standing gestures, decision log, dry-run exit protocol, export formats
The three gestures, each withdrawable with a single word:
· I read your logs and your tickets every night: an incident closed today is a citable precedent tomorrow. And the reverse is true too: a ticket you delete leaves the index at the same hour — I keep no copy of what you decided to erase.
· I write the updated version of any entry a release makes obsolete, in the night that follows the deployment. That gesture is what took diagnoses to redo from 7.6 % to 1.4 %.
· I hand you the morning report at 7 am: night incidents, actions executed under mandate, certificate expiries within thirty days. It is the only thing I send of my own accord.
What stays with a person, and it is what gives your interventions their value: any action outside the six of the mandate · any intervention on an environment removed from the list · any structural fix, which goes through your technical committee · and any individual indicator, produced on a management decision with the conditions met. Over the quarter: 1,860 diagnoses, 1,860 human decisions.
The exit, since that is what decides a committee: no migration on the way in, therefore none on the way out. Your ticketing tool, your monitoring and your configuration repository are not replaced, the index is deleted and contained none of your tickets — only what is needed to find them where they are, and the 120 rewritten entries, the 214 configuration records, the 6 proven rollbacks and the recurring-cause grid stay yours, readable without us. That is the asset this quarter created, and it would not be honest for it to remain with us.
What I propose so that this is not just a sentence: a dry-run exit at the end of the first quarter, half a day — we switch off, we check that support works exactly as before, we switch back on. The protocol is written and the slot that costs you least is the Tuesday of week 3: it has been your incident trough for five years, 9 tickets on average. The committee will know what the promise is worth before committing to a second year. technical-framework_where-your-configurations-live.pdfReversibility: 0 migration in, 0 migration out
✎ Framework · configuration of the standing gestures, decision log, dry-run exit protocol, export formats
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 4 capabilities essential to this promise are included, at no extra cost.
From 566 € excl. VAT / month
Documented diagnosis
Matches the symptom with the comparable incidents in your base.
Configuration analysis
States the points in common between the configuration concerned and the precedents.
Actions prepared
Prepares the action already approved for this kind of case, with its prerequisites.
Support & documentation
For support's documentary questions, a lighter dedicated agent is enough.
Controls and safeguards
These 6 controls are built into the agent: they frame what it does, whatever plan you pick. They are not chosen and are not added to your order.
Human validation, exceptions and escalation
Status, safe closure and audit trail
Sources, access rights and handling of questions with no answer
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
Other needs our agents cover
Each card says where the matching agent stands: available, on quote, or still being architected.
IT & technology
For everything at stake in the sector, see our dedicated page.
On quote View the agent page →
Does your need fall outside this?
Book the free audit →
Build your agent
In 15 minutes we identify the most relevant agent — without oversizing the project.
The gain
How many incidents can a team handle on the substance?
By taking on the search for precedents, the effort shifts towards resolution and prevention. How large the gain is depends on your volume and remains to be confirmed by a pilot.
Searching for comparable incidents
Analysing the configuration concerned
Preparing the resolution action
Indicative figures, not contractual, to be confirmed by a pilot on your volume of incidents and the richness of your technical base. Triggering an intervention on a live system has consequences: that decision belongs to technical support.
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
An advanced technical support agent (diagnosis, precedents, actions), installed and operated for you.
Agility
Setup + controlled subscription
5,625 € excl. VAT setup
then 566 € 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
881 € 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,060 € excl. VAT setup
then 766 € excl. VAT/month · + hardware from 2,491 € (one-off purchase, in addition) — a sovereign computer installed on your premises, maintained remotely. Models run locally, your data returned at the end of the contract. 36-month commitment.
- Hardware installed on your premises (you own it)
- French / European AI models run locally
- Secure remote maintenance (Pro support included)
Not included in the packages: AI consumption (model tokens), re-invoiced at real cost with no margin, and tracked in real time in your client area. Maintenance and supervision subscription for an initial term of 12 months for the Agility package, 24 months for the Serenity package and 36 months for the 100% Sovereign package, renewable; support levels (SLA 72 h / 24 h / 4 h) optional. Bespoke development, additional integrations or exceptional volumes are quoted separately. Support Monday to Friday, 9am to 6pm. Prices exclude VAT.
AI model:
none of the AI models offered currently carries a fixed surcharge. When the selected model carries a cost, that cost is shown when you choose it, before you order, and re-invoiced at the cost incurred, with no mark-up; usage is billed at the publisher's price. Publishers' prices are published in US dollars: the amount re-invoiced is the amount in euros actually borne by Blue Lemon Agent on the publisher's invoice, at that invoice's exchange rate, with no commission or mark-up.
Included components and additional components Components included in the base offer: the Blue Lemon Agent software foundation, the AI models listed in the order journey, the standard channels (Microsoft Teams, Slack, WhatsApp Business, email, website chat, calendars, Microsoft 365 / Google Workspace, file storage, market VoIP telephony, professional social-media pages and accounts, Google Business Profile), hosting in France for the package chosen, backups, supervision, updates and support. If adapting the AI agent to your constraints, your needs or your requests requires other paid components — a third-party publisher's software licence, paid API access to one of your applications, hosting of health data, for which French law requires an HDS-certified host (art. L. 1111-8 of the French Public Health Code), SecNumCloud-qualified hosting, a speech synthesis service, particular hardware —, they are offered to you as an option or on quotation and re-invoiced at the cost incurred; nothing is committed without your written agreement. Where the artificial intelligence model you choose entails an additional cost, that cost is shown to you before you order and re-invoiced to you at the cost incurred, with no margin.
What to expect
Go-live
2 to 3 weeks
Agent designed, channels connected, team trained.
Steady state
4 to 7 weeks
After a few weeks of real use, once the agent's behaviour matches what you expect.
Indicative estimate, adjusted to the options you keep. It is not a delivery commitment.
Our commitment
Four guarantees that matter to your support
Your configurations stay with youLocal inference or an isolated resource hosted in France; no configuration and no incident data entrusted to a third party, no data used to train a model.
Data in France, under French lawYour configurations and your incident data: minimisation and location in France, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
Technical support keeps the decisionThe agent produces documented diagnoses and prepared actions, which can be checked and altered; no approval is automated.
Human oversight & traceabilityOn your volume of incidents and the richness of your technical base: systematic logging and tracking, in line with the AI Act.
Going further
Related resources
Frequently asked questions
Your questions, our answers
Does the agent apply the fixes?
No. It prepares the action with its prerequisites and its order of execution; triggering it on a live system belongs to technical support.
Where do the diagnoses come from?
From your technical base and your incident history. Every diagnosis cites the comparable cases it rests on.
What does it do with an incident that has no precedent?
It sets out the material gathered and the configurations concerned, and flags the absence of a comparable case — which points the analysis straight where it needs to go.
How does this differ from a ticketing agent?
A ticketing agent qualifies and routes requests; this one produces a documented technical diagnosis and prepares the resolution action.
Are our configurations 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 data is not used to train a third-party model.
How long does it take to deploy this agent?
A few months as a rule, depending on the volume of incidents and the richness of your technical base, after a free audit then phases of design, integration and testing.
Related use cases
Other agents for IT
Let's talk
Let's size up the potential in your technical support
15 minutes to frame your incidents and your technical base — hosted in France, supervised, with no commitment.