● B2B offer — Calendars & organisation
Scheduling assistant: your recurrences, your constraints
Setting up a recurring appointment rarely takes one exchange: availability to cross-check, travel constraints, periods to avoid. Your agent proposes slots that fit the rules you have set and prepares the reminders. Hosted in France — local inference or an isolated resource — your teams' and your clients' calendars stay with you. No invitation goes out without your agreement.
Hosted in France
Calendars never exposed
GDPR & AI Act: governed deployment
Human oversight
Updated on
Deployed in a few weeks
Scheduling · hosted in France
Propose the slots for the monthly review with this client, for the quarter.
Slots proposed for the three months, compatible with the availability declared and your rules: no Friday afternoons, no closing weeks.
The reminders are prepared according to your usual notice periods.
Nothing has been sent: the proposals are waiting for your agreement.
✎ Action · slots proposed — no invitation sent
The reminders are prepared according to your usual notice periods.
Nothing has been sent: the proposals are waiting for your agreement.
✎ Action · slots proposed — no invitation sent
February is busy — can you force a slot?
February is constrained. I set out the possible slots, stating for each one the rule that would have to be relaxed — closing week or Friday afternoon.
You decide in full knowledge, rather than discovering the clash after the invitation has gone out.
✎ Action · informed decision, before sending
You decide in full knowledge, rather than discovering the clash after the invitation has gone out.
✎ Action · informed decision, before sending
Local inference · no data outside the EU
Calendars 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 scheduling manager decidesThe agent prepares, never rules
✦ In brief
A Blue Lemon Agent scheduling agent proposes the slots for your recurring appointments, respecting the constraints you have set — availability, periods to avoid, notice periods — and prepares the reminders. Where no option meets every rule, it says so instead of quietly ignoring one. It runs on local inference or is hosted in France: your teams' and your clients' calendars 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
scheduling 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 the number of recurrences to manage is confirmed by a pilot.
The context
What does an AI agent bring to keeping your calendars?
Every recurring appointment takes back-and-forth to find a slot. But giving a third-party service access to the calendars reveals the whole organisation's activity.
! The issue
Finding a slot that suits everyone takes repeated exchanges, and the forgotten constraint surfaces after the invitation has gone out. Yet entrusting the scheduling to a consumer service amounts to exposing your teams' calendars, your clients' identities and the rhythm of your exchanges to a third party subject to the Cloud Act — a calendar says a great deal about a business.
✓ Our answer
Assisted scheduling is only of interest if it is sovereign and respects your rules. Local inference or an isolated resource hosted in France, constraints applied with no silent exception, no invitation sent without agreement: you save the back-and-forth without losing control of your calendars or your rules.
The decisive point
Your teams' and your clients' availability: sovereignty & compliance
A calendar reveals who you work with and at what rhythm. Here is how the architecture of our agents protects it.
Local inference
The agent can run on a machine belonging to your organisation: no calendar leaves the network, no client availability passes through a public cloud.
Hosting in France
Otherwise, a dedicated and isolated resource hosted in France, under French law — your calendars and your constraints: processing and access within the European Union targeted by the architecture.
Reduced extraterritorial exposure
For your teams' and your clients' availability, the architecture aims to reduce exposure to the Cloud Act and FISA 702; being located in France or in the European Union does not, on its own, guarantee immunity.
Isolated resource
No pooling: an environment strictly dedicated to your organisation and its calendars.
Constraints applied with no silent exception
Your scheduling rules are respected; where no option satisfies them all, the agent says so instead of setting one aside. Every proposal is logged.
AI Act: governed deployment
The agent is strictly in support; no invitation is sent 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 events logged, their content, their retention period and who may access them are defined for the deployment chosen.
For executive calendars or appointments tied to a confidential transaction, SecNumCloud and reinforced hosting are options depending on your requirements. A single architecture is designed to answer both the GDPR and extraterritorial exposure. Designed for deployment in line with the GDPR and the AI Act, after the processing, roles and context-specific risks have been assessed.
Demonstration
See the agent at work
4 real situations, taken from those that come up most often. Pick one: the exchange unfolds as it would in your organisation.
A scripted demonstration. These exchanges show how the agent behaves — its sources, its refusals, what it leaves to your teams. Nothing is sent from this page, no model is queried here, and the matters named are fictional. That is precisely what we promise your data.
The behaviours shown here — monitoring, automation rules, routing and reminders — are configured with you during deployment, from your tools, your rules and your thresholds.
The architecture points named in these exchanges — location, local execution, isolation, encryption, role-based access, logging — are not a guarantee attached to the demonstration: they are those of the architecture set out in your quotation, and verified before commissioning.
Scheduling · hosted in France
Four flags this morning on your recurring meetings.
· A weekly meeting has run for eight months for a closed project. Thirty-four occurrences, eleven participants.
· One recurring slot is never accepted by four participants. Across twenty-two occurrences. I do not look for why.
· A move under consideration would shift forty future occurrences, six of which would clash.
· Two series have no original participant left. They have been handed on three times. morning-watch_4-flags.pdf34 occurrences for a closed project · 4 systematic declines
⛓ Source · 87 series, 2,940 occurrences, response logs
· A weekly meeting has run for eight months for a closed project. Thirty-four occurrences, eleven participants.
· One recurring slot is never accepted by four participants. Across twenty-two occurrences. I do not look for why.
· A move under consideration would shift forty future occurrences, six of which would clash.
· Two series have no original participant left. They have been handed on three times. morning-watch_4-flags.pdf34 occurrences for a closed project · 4 systematic declines
⛓ Source · 87 series, 2,940 occurrences, response logs
A meeting that continues after the project ended?
Yes, and nobody did anything wrong: a recurring series is a decision taken once and applied a hundred times.
What I record: this meeting was created for a project whose last task closed eight months ago. Since then, 34 occurrences, eleven people invited, and an acceptance rate that fell from 96% to 41%.
Why nobody stopped it: because stopping it takes a decision, leaving it takes none. Each week the question is put to nobody — it is already in the calendar.
What I have prepared, and what is left to decide: the cancellation of the series is written, with the message to the eleven participants — it goes out the second I am told. The signature stays with whoever created the series, because a meeting can change purpose without changing name: I have seen two cases here where that was exactly it, and a cancellation cannot be undone.
What I do: I send the finding to whoever created it — not to the participants — with three facts: the project's closing date, the number of occurrences since, and the trend in acceptance.
What I add, because it is the figure that decides: eleven people, one hour, thirty-four times: three hundred and seventy-four hours. Nobody had counted them, and they appear nowhere. 34-occurrences_374-hours.pdfStopping it takes a decision, leaving it takes none
⛓ Source · 34 occurrences, acceptance 96% → 41%, 374 hours
What I record: this meeting was created for a project whose last task closed eight months ago. Since then, 34 occurrences, eleven people invited, and an acceptance rate that fell from 96% to 41%.
Why nobody stopped it: because stopping it takes a decision, leaving it takes none. Each week the question is put to nobody — it is already in the calendar.
What I have prepared, and what is left to decide: the cancellation of the series is written, with the message to the eleven participants — it goes out the second I am told. The signature stays with whoever created the series, because a meeting can change purpose without changing name: I have seen two cases here where that was exactly it, and a cancellation cannot be undone.
What I do: I send the finding to whoever created it — not to the participants — with three facts: the project's closing date, the number of occurrences since, and the trend in acceptance.
What I add, because it is the figure that decides: eleven people, one hour, thirty-four times: three hundred and seventy-four hours. Nobody had counted them, and they appear nowhere. 34-occurrences_374-hours.pdfStopping it takes a decision, leaving it takes none
⛓ Source · 34 occurrences, acceptance 96% → 41%, 374 hours
How do you work, and who do you tell?
I look at the series, never at the people.
What I look at: the meeting series, their accepted, declined or unanswered responses, the clashes produced, and the gap between the stated purpose and what is still active in your systems.
Routing follows who can decide: a series with no active purpose goes to whoever created it; a slot never accepted by the same people to the organiser, naming nobody; a move that would produce clashes to whoever is considering it, before they do it; an inherited series with no original participant to its current holder.
With a monthly chase. Then a quarterly summary: series with no active purpose, hours accumulated per series, and structurally unworkable slots.
Three operating rules, and the second is the strictest. Moving, cancelling or creating a meeting is signed — I prepare everything that comes before: the simulation, the dated clashes, the replacement slots, the message to participants already drafted. The reason for an unavailability does not interest me and is not inferred: unavailability is a fact, and that is what lets a time be fixed without anyone having to explain themselves — here, acceptance went from 5 out of 9 to 9 out of 9. And a calendar you have not opened to me, I say so rather than assume the person free: an external participant is flagged as such, never counted present.
✎ Framework · no meeting moved · no reason for unavailability
What I look at: the meeting series, their accepted, declined or unanswered responses, the clashes produced, and the gap between the stated purpose and what is still active in your systems.
Routing follows who can decide: a series with no active purpose goes to whoever created it; a slot never accepted by the same people to the organiser, naming nobody; a move that would produce clashes to whoever is considering it, before they do it; an inherited series with no original participant to its current holder.
With a monthly chase. Then a quarterly summary: series with no active purpose, hours accumulated per series, and structurally unworkable slots.
Three operating rules, and the second is the strictest. Moving, cancelling or creating a meeting is signed — I prepare everything that comes before: the simulation, the dated clashes, the replacement slots, the message to participants already drafted. The reason for an unavailability does not interest me and is not inferred: unavailability is a fact, and that is what lets a time be fixed without anyone having to explain themselves — here, acceptance went from 5 out of 9 to 9 out of 9. And a calendar you have not opened to me, I say so rather than assume the person free: an external participant is flagged as such, never counted present.
✎ Framework · no meeting moved · no reason for unavailability
Four people who always decline — do you know why?
No, and I will not look. What I do know is enough to fix it.
What I record: this recurring slot has never been accepted by four of the nine participants, across 22 occurrences. That is not chance: it is zero out of twenty-two, four times over.
What I look for instead of the cause, and it is what settles the problem: the slots where all nine are free. Over the four months ahead I found three, accepted by all nine across the same period. The cause does not need to be known for the slot to move — part-time hours, childcare, a commute, treatment, another series: the list of possible reasons is almost entirely made of things nobody should have to justify to appear in a calendar. It is the one case where not knowing costs nothing.
What I report to the organiser: "this slot is never accepted by four participants out of nine", without saying which, and three alternative slots accepted by all nine over the same period.
Why not name them, when the organiser already sees the responses: because seeing an occasional decline and reading "those four never come" do not produce the same conversation. The second wording creates a people problem where there is a timing problem.
What that gave: the slot was moved. Acceptance went from 5 of 9 to 9 of 9, without any of the four having to explain anything. 22-occurrences_4-of-9.pdfUnavailability is a fact; its reason does not belong in the calendar
⛓ Source · 22 occurrences, 4 systematic declines, 3 alternative slots
What I record: this recurring slot has never been accepted by four of the nine participants, across 22 occurrences. That is not chance: it is zero out of twenty-two, four times over.
What I look for instead of the cause, and it is what settles the problem: the slots where all nine are free. Over the four months ahead I found three, accepted by all nine across the same period. The cause does not need to be known for the slot to move — part-time hours, childcare, a commute, treatment, another series: the list of possible reasons is almost entirely made of things nobody should have to justify to appear in a calendar. It is the one case where not knowing costs nothing.
What I report to the organiser: "this slot is never accepted by four participants out of nine", without saying which, and three alternative slots accepted by all nine over the same period.
Why not name them, when the organiser already sees the responses: because seeing an occasional decline and reading "those four never come" do not produce the same conversation. The second wording creates a people problem where there is a timing problem.
What that gave: the slot was moved. Acceptance went from 5 of 9 to 9 of 9, without any of the four having to explain anything. 22-occurrences_4-of-9.pdfUnavailability is a fact; its reason does not belong in the calendar
⛓ Source · 22 occurrences, 4 systematic declines, 3 alternative slots
And people who never respond?
I count non-responses as non-responses, not as acceptances.
What I record: of 2,940 occurrences, 38% received no response at all. Your systems show them as "pending", and the organiser reads them as probable attendance.
Why that is a practical problem: a meeting planned for nine people of whom four never responded is not a nine-person meeting. The format, the room and the agenda were chosen for a headcount that does not exist.
Why the figure rather than the chase: a chase on a recurring invitation arrives every week and becomes noise people filter out — which makes worse exactly what it claims to fix.
What I do: I give the organiser, before the occurrence, three figures: accepted, declined, no response. And for the series, the actual attendance observed where it is available, which is the only figure that does not lie.
What I never produce: a response rate per person. It would measure who answers invitations, not who comes to meetings. 38-percent-no-response.pdfA non-response is not an acceptance
⛓ Source · 2,940 occurrences, 38% with no response
What I record: of 2,940 occurrences, 38% received no response at all. Your systems show them as "pending", and the organiser reads them as probable attendance.
Why that is a practical problem: a meeting planned for nine people of whom four never responded is not a nine-person meeting. The format, the room and the agenda were chosen for a headcount that does not exist.
Why the figure rather than the chase: a chase on a recurring invitation arrives every week and becomes noise people filter out — which makes worse exactly what it claims to fix.
What I do: I give the organiser, before the occurrence, three figures: accepted, declined, no response. And for the series, the actual attendance observed where it is available, which is the only figure that does not lie.
What I never produce: a response rate per person. It would measure who answers invitations, not who comes to meetings. 38-percent-no-response.pdfA non-response is not an acceptance
⛓ Source · 2,940 occurrences, 38% with no response
And when no slot works at all, what do you propose?
I say so, and I name the constraint that closes it. Flagging dead ends is exactly that: a dead end announced can be loosened, a dead end left unsaid repeats every month.
Your monthly steering committee: twelve participants, six constraints — all twelve free, a twelve-seat room with video, outside the Tuesday-morning production window, seven days' notice because the committee calls for papers, between 09:00 and 17:00, and not Friday afternoon. Across the next four months, 664 one-hour slots examined: not one meets all six.
Where each constraint cuts, and it is this table that makes the dead end useful: 664 working slots; −68 Friday afternoons → 596; −68 Tuesday production mornings → 528; −40 inside seven days' notice → 488; twelve-seat room with video: 41 left; all twelve participants together: 0.
The constraint that closes it, named: it is the twelve participants together, not the room. Of the 41 slots that clear the other five constraints, the best brings ten participants out of twelve, and two of them share no slot at all with the other ten across the four months. I do not look for why, and I do not say which two: this is a timetable problem, not a people problem.
Three ways to loosen it, costed, and only one is good:
· The room — accept an eight-seat room with video for the other four: 214 slots instead of 41, of which 27 bring all twelve together. That is the cheapest loosening, by a distance;
· The notice period — cut from seven days to four: 40 slots returned, of which 2 clear the room constraint and none brings all twelve. It settles nothing, and I say so, so that it is not attempted;
· The headcount — hold the committee with ten of twelve: 3 slots available from the current 41, with the decision note to the two absentees and their items taken first at the following committee.
The figure that does not flatter me: across my first 26 dead-end flags, 7 were false dead ends — 26.9%. I counted as busy every calendar you had not opened to me, and two outside participants were enough to close slots that were genuinely free.
What I changed: a calendar that is not opened counts as unknown, neither free nor busy, and it appears in plain words in the flag, with the question to put to the person. Across the next 40 flags: 0 false dead ends, and 5 flags carrying an unknown calendar named as such — three were settled with a message. dead-end_664-slots_6-constraints.pdfThe constraint that closes it, named · 3 costed loosenings
⛓ Sourced · 664 slots, 6 constraints, 41 then 0 · 7 false dead ends out of 26, then 0 out of 40
Your monthly steering committee: twelve participants, six constraints — all twelve free, a twelve-seat room with video, outside the Tuesday-morning production window, seven days' notice because the committee calls for papers, between 09:00 and 17:00, and not Friday afternoon. Across the next four months, 664 one-hour slots examined: not one meets all six.
Where each constraint cuts, and it is this table that makes the dead end useful: 664 working slots; −68 Friday afternoons → 596; −68 Tuesday production mornings → 528; −40 inside seven days' notice → 488; twelve-seat room with video: 41 left; all twelve participants together: 0.
The constraint that closes it, named: it is the twelve participants together, not the room. Of the 41 slots that clear the other five constraints, the best brings ten participants out of twelve, and two of them share no slot at all with the other ten across the four months. I do not look for why, and I do not say which two: this is a timetable problem, not a people problem.
Three ways to loosen it, costed, and only one is good:
· The room — accept an eight-seat room with video for the other four: 214 slots instead of 41, of which 27 bring all twelve together. That is the cheapest loosening, by a distance;
· The notice period — cut from seven days to four: 40 slots returned, of which 2 clear the room constraint and none brings all twelve. It settles nothing, and I say so, so that it is not attempted;
· The headcount — hold the committee with ten of twelve: 3 slots available from the current 41, with the decision note to the two absentees and their items taken first at the following committee.
The figure that does not flatter me: across my first 26 dead-end flags, 7 were false dead ends — 26.9%. I counted as busy every calendar you had not opened to me, and two outside participants were enough to close slots that were genuinely free.
What I changed: a calendar that is not opened counts as unknown, neither free nor busy, and it appears in plain words in the flag, with the question to put to the person. Across the next 40 flags: 0 false dead ends, and 5 flags carrying an unknown calendar named as such — three were settled with a message. dead-end_664-slots_6-constraints.pdfThe constraint that closes it, named · 3 costed loosenings
⛓ Sourced · 664 slots, 6 constraints, 41 then 0 · 7 false dead ends out of 26, then 0 out of 40
Moving a series by an hour is simple, surely?
On one occurrence, yes. On a series, it touches forty future meetings.
What I record when simulating the requested move: 40 future occurrences would shift, and 6 would clash with a meeting already accepted by at least one participant. Two of those six clashes involve meetings with people outside the company.
Why that simulation does not exist in the tools: because they apply the move and let each person discover their own clash. The cost is real but distributed, so invisible to whoever decides.
What I hand back before the move: the number of occurrences touched, the six clashes with their dates, a note of those involving external people, and the neighbouring slots that would produce none.
What is left to do, and it takes one click: the move itself. A reschedule touches eleven calendars: it is signed by whoever organises it — and it executes the second after, the forty occurrences and the six clashes handled in one pass.
What I also flag: when a move would make the slot unworkable for participants who accepted it until now. Here, two. Without saying which. 40-occurrences_6-clashes.pdfA reschedule cost is real but distributed, so invisible
⛓ Source · simulation over 40 occurrences, 6 clashes, 2 external
What I record when simulating the requested move: 40 future occurrences would shift, and 6 would clash with a meeting already accepted by at least one participant. Two of those six clashes involve meetings with people outside the company.
Why that simulation does not exist in the tools: because they apply the move and let each person discover their own clash. The cost is real but distributed, so invisible to whoever decides.
What I hand back before the move: the number of occurrences touched, the six clashes with their dates, a note of those involving external people, and the neighbouring slots that would produce none.
What is left to do, and it takes one click: the move itself. A reschedule touches eleven calendars: it is signed by whoever organises it — and it executes the second after, the forty occurrences and the six clashes handled in one pass.
What I also flag: when a move would make the slot unworkable for participants who accepted it until now. Here, two. Without saying which. 40-occurrences_6-clashes.pdfA reschedule cost is real but distributed, so invisible
⛓ Source · simulation over 40 occurrences, 6 clashes, 2 external
Two series with no original participant?
They have changed hands three times, and nobody knows any more what they were for.
What I record: two weekly series where none of the current participants was there at creation. The organiser is the third in succession. The written purpose has not changed in four years.
Why this is a case apart: a series whose purpose has been lost cannot be questioned by anybody — each assumes the others know. On a meeting handed on three times, that assumption is wrong for everybody.
What I looked for before concluding anything: a real use nobody ever wrote down — that is the commonest case. I compared the stated purpose against active projects, documents opened during the slot, and minutes produced: one of the two series still feeds a weekly tracking sheet; the other has left no trace in eleven months. So the two are not handled the same way.
What I do: I report three facts to the current holder: the series has run for four years, no original participant remains, and the written purpose no longer matches any active project in your systems.
What I propose: a question to put in the meeting, once. "What would happen if this one did not exist?" — it is the one thing I cannot establish, and the only one that settles it. 2-series_handed-on-three-times.pdfEach assumes the others know
⛓ Source · 2 series, 3 changes of organiser, purpose unchanged for 4 years
What I record: two weekly series where none of the current participants was there at creation. The organiser is the third in succession. The written purpose has not changed in four years.
Why this is a case apart: a series whose purpose has been lost cannot be questioned by anybody — each assumes the others know. On a meeting handed on three times, that assumption is wrong for everybody.
What I looked for before concluding anything: a real use nobody ever wrote down — that is the commonest case. I compared the stated purpose against active projects, documents opened during the slot, and minutes produced: one of the two series still feeds a weekly tracking sheet; the other has left no trace in eleven months. So the two are not handled the same way.
What I do: I report three facts to the current holder: the series has run for four years, no original participant remains, and the written purpose no longer matches any active project in your systems.
What I propose: a question to put in the meeting, once. "What would happen if this one did not exist?" — it is the one thing I cannot establish, and the only one that settles it. 2-series_handed-on-three-times.pdfEach assumes the others know
⛓ Source · 2 series, 3 changes of organiser, purpose unchanged for 4 years
Can you book the slots automatically?
Yes, and it is the setting that removes the back-and-forth. It opens by type of appointment.
What I place alone as soon as you open it: occurrences of an already approved series, conflict-free moves — the target slot is free for everyone —, cancellations of occurrences whose purpose has ended, and meetings where all participants share a free slot. Across your 2,940 occurrences, most fall into those four cases.
What still needs somebody's approval: creating a new series — a recurrence is a decision taken once and applied a hundred times —, any move producing a conflict, and any cancellation of a whole series.
What I simulate before placing: the requested move touched 40 future occurrences and produced 6 conflicts. On one occurrence it is simple; on a series it never is — and that is exactly what the calendar does not show at the moment of clicking.
What I do in every case, even on automatic placement: I flag a series continuing after its purpose has ended. Yours had run for eight months on a closed project: 34 occurrences, eleven participants. Nobody did anything wrong. automatic-placement_4-cases.pdfWhat places itself · what stays approved · the simulation before placing
⛓ Source · 2,940 occurrences, simulated move at 40 occurrences and 6 conflicts
What I place alone as soon as you open it: occurrences of an already approved series, conflict-free moves — the target slot is free for everyone —, cancellations of occurrences whose purpose has ended, and meetings where all participants share a free slot. Across your 2,940 occurrences, most fall into those four cases.
What still needs somebody's approval: creating a new series — a recurrence is a decision taken once and applied a hundred times —, any move producing a conflict, and any cancellation of a whole series.
What I simulate before placing: the requested move touched 40 future occurrences and produced 6 conflicts. On one occurrence it is simple; on a series it never is — and that is exactly what the calendar does not show at the moment of clicking.
What I do in every case, even on automatic placement: I flag a series continuing after its purpose has ended. Yours had run for eight months on a closed project: 34 occurrences, eleven participants. Nobody did anything wrong. automatic-placement_4-cases.pdfWhat places itself · what stays approved · the simulation before placing
⛓ Source · 2,940 occurrences, simulated move at 40 occurrences and 6 conflicts
What do you keep?
What describes the series and lets you correct them — nothing that describes people.
What is kept: the series, their purpose, their age and their owner, the number of occurrences and the hours they represent, acceptance, refusal and no-reply rates per series, the conflicts produced, and the series whose purpose has ended.
Why no-replies are counted as such: across 2,940 occurrences, 38 % received no reply at all. Your tools show them as acceptances. An acceptance rate of 96 % that becomes 58 % once you separate the two is not the same meeting — and it is the figure that decides whether a series deserves to continue.
What it enabled: spotting a slot never accepted by four participants of nine, across 22 occurrences, and two weekly series where no current participant was there at creation. They had changed hands three times.
What I do not look for: why a person refuses. It is not discretion: the slot is fixed without that information, and looking for it would turn a calendar problem into a file on somebody. what-you-keep_scheduling.pdf5 items kept · the rate that decides whether a series continues
⛓ Source · 38 % no-replies counted as such, 96 % brought down to 58 %
What is kept: the series, their purpose, their age and their owner, the number of occurrences and the hours they represent, acceptance, refusal and no-reply rates per series, the conflicts produced, and the series whose purpose has ended.
Why no-replies are counted as such: across 2,940 occurrences, 38 % received no reply at all. Your tools show them as acceptances. An acceptance rate of 96 % that becomes 58 % once you separate the two is not the same meeting — and it is the figure that decides whether a series deserves to continue.
What it enabled: spotting a slot never accepted by four participants of nine, across 22 occurrences, and two weekly series where no current participant was there at creation. They had changed hands three times.
What I do not look for: why a person refuses. It is not discretion: the slot is fixed without that information, and looking for it would turn a calendar problem into a file on somebody. what-you-keep_scheduling.pdf5 items kept · the rate that decides whether a series continues
⛓ Source · 38 % no-replies counted as such, 96 % brought down to 58 %
And the reminders before each occurrence — do you handle those?
Reminder preparation follows your own notice periods, not mine — and I read them out of your eight months of history.
Your three real notice periods, measured: 7 days before a committee that requires documents, 48 hours before a team meeting, 24 hours before a short check-in. These are not conventions I invented: they are the notice your organisers already give, in 84 % of cases.
What the preparation produces: for every upcoming occurrence, a written reminder with the subject, the room or the link, the documents expected and the name of whoever is expecting them. Across the 40 occurrences the postponement would move, all 40 reminders are rewritten with the new date, and the 6 clashes are named in the same message rather than discovered the day before.
The channel follows the person: e-mail for participants in your directory; SMS when the person is in none of your tools — an outside speaker, a supplier, a client — because a reminder sent to an address you do not administer proves nothing. Of the 11 participants in the weekly meeting, 2 are in that position.
The figure that does not flatter me: of my first 260 reminders, 18 went out on a Saturday or a public holiday — 6.9 %. Three participants only saw them on the Monday, which for two of them was after the meeting. I was counting the notice period in hours where you count it in working days. I now count as you do and move to the last useful working day: over the next 400 reminders, none went out outside working days.
⛓ Sourced · 3 notice periods measured over 8 months, 40 reminders rewritten, 18 out-of-hours sends fixed
Your three real notice periods, measured: 7 days before a committee that requires documents, 48 hours before a team meeting, 24 hours before a short check-in. These are not conventions I invented: they are the notice your organisers already give, in 84 % of cases.
What the preparation produces: for every upcoming occurrence, a written reminder with the subject, the room or the link, the documents expected and the name of whoever is expecting them. Across the 40 occurrences the postponement would move, all 40 reminders are rewritten with the new date, and the 6 clashes are named in the same message rather than discovered the day before.
The channel follows the person: e-mail for participants in your directory; SMS when the person is in none of your tools — an outside speaker, a supplier, a client — because a reminder sent to an address you do not administer proves nothing. Of the 11 participants in the weekly meeting, 2 are in that position.
The figure that does not flatter me: of my first 260 reminders, 18 went out on a Saturday or a public holiday — 6.9 %. Three participants only saw them on the Monday, which for two of them was after the meeting. I was counting the notice period in hours where you count it in working days. I now count as you do and move to the last useful working day: over the next 400 reminders, none went out outside working days.
⛓ Sourced · 3 notice periods measured over 8 months, 40 reminders rewritten, 18 out-of-hours sends fixed
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 forms of recurring scheduling. All these uses work in support, subject to your approval.
Included in your agent
The 3 capabilities essential to this promise are included, at no extra cost.
From 474 € excl. VAT / month
Proposing slots
Proposes slots compatible with your availability and the rules you have declared.
Preparing the reminders
Prepares the reminders according to your usual notice periods. By email, or by text message when the person is not in your tools.
Flagging dead ends
States when no option meets every constraint, naming the one that blocks it.
Controls and safeguards
These 3 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
Data protection, rights and human oversight
What the agent must be connected to
This connection is required for the agent to work. It concerns your information system and is scoped during the audit.
Integration with existing tools without double entry
Need to go further?
These agents handle a different business process, with their own owner and their own price. They are added to this one.
Does your need fall outside this?
Book the free audit →
Build your agent
In 15 minutes we identify the most relevant agent — without oversizing the project.
The gain
How much back-and-forth can a team avoid?
By proposing slots compatible with every constraint from the outset, the scheduling exchanges and the invitations to redo both come down. How large the gain is depends on your volume and remains to be confirmed by a pilot.
Finding a common slot
Checking the constraints
Sending the reminders
Qualitative, non-contractual comparison: the proportions shown illustrate the shift of the work towards review, they represent no measurement. Every output of the agent is reviewed and approved by a competent person.
How it works
The stages of your AI agent project
1
Audit & scoping
15 minutes to target the use case with the best return.
2
Quote or direct sign-up
A catalogue offer is bought online; a specific need gets a costed quote.
3
Design
We design the agent and its guardrails.
4
Integration & testing
We connect your tools to the agent, which is itself hosted in France.
5
Rollout
Going live and training your team.
6
Operation
Continuous supervision and improvement.
Pricing
One package, one agent
A scheduling assistant (calendars, constraints, reminders), installed and operated for you.
Agility
Setup + controlled subscription
3,710 € excl. VAT setup
then 474 € 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
679 € excl. VAT /month
all inclusive, immediate start. No upfront investment: a single subscription. Ideal for starting quickly and simply.
- Setup included (installation, configuration, training)
- Operation, human oversight, updates and support
- Sovereign hosting in France, managed end to end
100% Sovereign
On site, you own it
6,950 € excl. VAT setup
then 674 € excl. VAT/month · + hardware from 1,058 € (one-off purchase, in addition) — a sovereign computer installed on your premises, maintained remotely. Models run locally, your data returned at the end of the contract. 36-month commitment.
- Hardware installed on your premises (you own it)
- French / European AI models run locally
- Secure remote maintenance (Pro support included)
Not included in the packages: AI consumption (model tokens), re-invoiced at real cost with no margin, and tracked in real time in your client area. Maintenance and supervision subscription for an initial term of 12 months for the Agility package, 24 months for the Serenity package and 36 months for the 100% Sovereign package, renewable; support levels (SLA 72 h / 24 h / 4 h) optional. Bespoke development, additional integrations or exceptional volumes are quoted separately. Support Monday to Friday, 9am to 6pm. Prices exclude VAT.
AI model:
none of the AI models offered currently carries a fixed surcharge. When the selected model carries a cost, that cost is shown when you choose it, before you order, and re-invoiced at the cost incurred, with no mark-up; usage is billed at the publisher's price. Publishers' prices are published in US dollars: the amount re-invoiced is the amount in euros actually borne by Blue Lemon Agent on the publisher's invoice, at that invoice's exchange rate, with no commission or mark-up.
Included components and additional components Components included in the base offer: the Blue Lemon Agent software foundation, the AI models listed in the order journey, the standard channels (Microsoft Teams, Slack, WhatsApp Business, email, website chat, calendars, Microsoft 365 / Google Workspace, file storage, market VoIP telephony, professional social-media pages and accounts, Google Business Profile), hosting in France for the package chosen, backups, supervision, updates and support. If adapting the AI agent to your constraints, your needs or your requests requires other paid components — a third-party publisher's software licence, paid API access to one of your applications, hosting of health data, for which French law requires an HDS-certified host (art. L. 1111-8 of the French Public Health Code), SecNumCloud-qualified hosting, a speech synthesis service, particular hardware —, they are offered to you as an option or on quotation and re-invoiced at the cost incurred; nothing is committed without your written agreement. Where the artificial intelligence model you choose entails an additional cost, that cost is shown to you before you order and re-invoiced to you at the cost incurred, with no margin.
What to expect
Go-live
2 to 3 weeks
Agent designed, channels connected, team trained.
Steady state
4 to 7 weeks
After a few weeks of real use, once the agent's behaviour matches what you expect.
Indicative estimate, adjusted to the options you keep. It is not a delivery commitment.
Our commitment
Four guarantees that matter to your calendars
Your calendars do not leave the companyLocal inference or an isolated resource hosted in France; no team or client availability entrusted to a third party, no data used to train a model.
Data in France, under French lawYour teams' and your clients' availability: minimisation and location in France, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
The scheduling manager keeps the decisionThe agent produces proposed slots, which can be checked and altered; no approval is automated.
Human oversight & traceabilityOn the number of recurrences to manage: systematic logging and tracking, in line with the AI Act.
Going further
Related resources
Frequently asked questions
Your questions, our answers
Does the agent send the invitations itself?
No. It proposes slots and prepares the reminders; sending remains a human act. An invitation sent in error is hard to take back with a client.
What does the agent do if no date works?
It says so, and can show the slots that break a constraint, naming which one. It never chooses to ignore a rule on your behalf.
Which calendars does the agent access?
Only the ones you name, at the level of access you choose. Every consultation is logged and the access can be revoked.
Is our clients' availability 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 calendars are not used to train a third-party model.
Does it connect to our existing calendars?
Yes, to the common professional calendars, with no change of tool for your teams. The integration is defined at the design stage.
How long does it take to deploy this assistant?
A few weeks as a rule, depending on the number of calendars and how detailed your scheduling rules are, after a free audit then a phase of design, integration and testing.
Can the agent notify participants by text message?
Yes, as an option. The agent prepares the reminder for the coming meeting by text message, according to your usual notice periods. A text message is an outbound notification channel, not a conversation channel: no one writes back to the agent there — the conversation stays on WhatsApp Business, your website chat or email. The message announces without detailing, it carries your registered sender name, and it never contains a payment link, a login or a password: the recipient reaches your account area the way they usually do. Delivery goes through a gateway established in the European Union; the messages sent are passed on to you at actual cost, with no margin, and the channel itself is an optional module, set out on the pricing page.
Related use cases
Other agents for organisation
Let's talk
Let's size up the potential in your recurring appointments
15 minutes to frame your recurrences and your constraints — hosted in France, supervised, with no commitment.