● B2B offer — Logistics & operations
Rounds: your constraints respected, several options on the table
Putting a round together means making delivery windows, vehicle capacities, driving times and customer priorities all fit. Your agent assembles those constraints and proposes several possible arrangements, each with what it respects and what it leaves open. Hosted in France: your customer addresses and your load plans stay with you. The operations manager chooses the round.
Hosted in France
Addresses and load plans protected
GDPR & AI Act: governed deployment
Human oversight
Updated on
Deployed in a few weeks
Round planning · hosted in France
Put together tomorrow's rounds for three vehicles.
Three arrangements proposed, each respecting the windows quoted to customers and the capacity of each vehicle.
For each: what is covered, the order of the stops and the slack left between deliveries.
Two points are still to be settled: they are marked on each option.
🔗 Sourced · the day's orders, capacities and windows
For each: what is covered, the order of the stops and the slack left between deliveries.
Two points are still to be settled: they are marked on each option.
🔗 Sourced · the day's orders, capacities and windows
What are those two points?
A very narrow window at one customer, and a bulky delivery that takes up a large share of one vehicle.
Both can be handled, but the order of priority between customers is yours: it bears on your service commitments.
✎ Support · trade-offs set out, operations decision
Both can be handled, but the order of priority between customers is yours: it bears on your service commitments.
✎ Support · trade-offs set out, operations decision
Local inference · no data outside the EU
Rounds 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 operations manager decidesThe agent prepares, never rules
✦ In brief
A Blue Lemon Agent logistics planning agent assembles your windows, capacities and priorities and proposes several round arrangements, each with what it covers and what it leaves to be settled. Choosing the round falls to operations. It runs on local inference or is hosted in France: customer addresses and load plans 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
operations 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 number of vehicles and stops served is confirmed by a pilot.
The context
What does an AI agent bring to planning your rounds?
A well-built round shows across the whole day: less waiting, windows kept, drivers back on time.
! The issue
A round makes promised windows, vehicle capacities and road times fit together. Exploring several combinations by hand takes time, and you often stop at the first one that works. The agent proposes several, each documented, which gives operations a real choice rather than a single option.
✓ Our answer
The operations manager compares complete arrangements and decides on what is their responsibility: the order of priority between customers, the service commitments, the acceptable load for a driver. Local inference or an isolated resource hosted in France: your customer addresses and your load plans, revealing of your activity, do not leave the company.
The decisive point
Your customer addresses and your load plans: sovereignty & compliance
Your customer addresses and your load plans say a great deal about your activity. Here is how the architecture of our agents protects them.
Local inference
The agent can run on a machine belonging to your organisation: no customer address and no load plan leaves the network.
Hosting in France
Otherwise, a dedicated and isolated resource hosted in France, under French law — your rounds and your delivery constraints: processing and access within the European Union targeted by the architecture.
Reduced extraterritorial exposure
For your customer addresses and your load plans, 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 operation and its constraints.
Constraints respected and shown
Every proposal states the constraints it respects and the points left to be settled; encryption, role-based access and logging of every plan produced.
AI Act: governed deployment
The agent is strictly in support; no round is committed and no driver is assigned automatically; traceability and human oversight from end to end.
What depends on the architecture chosen These points are not general guarantees: they are settled deployment by deployment, in the quotation.
- The applicable location is that of the architecture set out in the quotation and verified before commissioning.
- Local execution is announced only for the configuration explicitly described and accepted in the quotation.
- The applicable isolation depends on the deployment mode set out in the quotation; no dedicated isolation is presumed.
- Roles and permissions are configured and accepted for the identities and systems actually connected.
- The events logged, their content, their retention period and who may access them are defined for the deployment chosen.
For rounds carrying sensitive goods or serving sites with restricted access, 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.
Round planning · hosted in France
Four flags this morning on your rounds.
· The optimal plan loses forty minutes a day in the city centre. It does not count parking.
· Eleven proposed rounds exceeded the statutory driving times. I did not produce them.
· The two-hour window promised to customers is met in sixty-one per cent of cases.
· I am asked for a performance table per driver. I will not produce it. morning-watch_4-flags.pdf40 minutes lost a day · window met 61% of the time
⛓ Source · 1,240 rounds, position records, observed service times
· The optimal plan loses forty minutes a day in the city centre. It does not count parking.
· Eleven proposed rounds exceeded the statutory driving times. I did not produce them.
· The two-hour window promised to customers is met in sixty-one per cent of cases.
· I am asked for a performance table per driver. I will not produce it. morning-watch_4-flags.pdf40 minutes lost a day · window met 61% of the time
⛓ Source · 1,240 rounds, position records, observed service times
How can an optimal plan lose time?
Because it optimises the route, and a round is not a route.
What the calculation assumes: that you arrive, you deliver, you leave. It counts kilometres and traffic. It counts neither parking, nor the walk to the door, nor waiting at the entryphone, nor the walk back to the vehicle.
What I measured: in the city centre, 7 minutes of parking on average — finding a space included — against 1 minute assumed by the calculation. Over a round of 22 urban stops the cumulative gap is 40 minutes a day.
What that produces: a plan "optimised by 12%" that nobody keeps to. The driver catches up by skipping their break, or the round finishes late — and the delay is put down to the round, never to the plan.
What I do: I use observed times, by zone and by address type, never theoretical ones. An address in a pedestrian zone, a building with no entry code, an industrial estate: three different times, measured here.
What that changes in the plan: it claims 4% gain instead of 12%. It is less flattering, and it is the only one that holds. 7-minutes-against-1_40-a-day.pdfA plan optimised by 12% that nobody keeps to
⛓ Source · 7 minutes parking against 1 assumed, 40 minutes' gap a day
What the calculation assumes: that you arrive, you deliver, you leave. It counts kilometres and traffic. It counts neither parking, nor the walk to the door, nor waiting at the entryphone, nor the walk back to the vehicle.
What I measured: in the city centre, 7 minutes of parking on average — finding a space included — against 1 minute assumed by the calculation. Over a round of 22 urban stops the cumulative gap is 40 minutes a day.
What that produces: a plan "optimised by 12%" that nobody keeps to. The driver catches up by skipping their break, or the round finishes late — and the delay is put down to the round, never to the plan.
What I do: I use observed times, by zone and by address type, never theoretical ones. An address in a pedestrian zone, a building with no entry code, an industrial estate: three different times, measured here.
What that changes in the plan: it claims 4% gain instead of 12%. It is less flattering, and it is the only one that holds. 7-minutes-against-1_40-a-day.pdfA plan optimised by 12% that nobody keeps to
⛓ Source · 7 minutes parking against 1 assumed, 40 minutes' gap a day
How do you work, and where do you hand over?
I build rounds that hold, and I refuse to produce ones that do not.
What I take into account: service times observed by zone and address type, the windows promised to customers, statutory driving times and breaks, the vehicle's real capacity, and the driver's declared constraints — without knowing their reason.
Routing follows who can decide: a round that cannot be done in time is flagged before being proposed; a window that will not be met is flagged to customer service in the morning, not at the moment of failure; an address whose real time durably exceeds the estimate goes to whoever maintains the reference data; a round incident is logged without comment.
With a monthly summary: gaps between estimated and observed times by zone, windows met, rounds requiring an overrun, and addresses systematically underestimated.
Three guarantees. Every plan I propose fits within statutory driving times, including when I am asked for another — it is the driver who carries the responsibility for an overrun, never the plan that asked it of them, and a plan that holds is the only one that protects both. Location data serves the round: it feeds observed times by zone and address type, never a comparison between drivers. And every window announced is a window the plan can hold — a missed window costs more than a wide one, and the figure is in the third tab.
✎ Framework · no plan outside statutory times · no measurement of people
What I take into account: service times observed by zone and address type, the windows promised to customers, statutory driving times and breaks, the vehicle's real capacity, and the driver's declared constraints — without knowing their reason.
Routing follows who can decide: a round that cannot be done in time is flagged before being proposed; a window that will not be met is flagged to customer service in the morning, not at the moment of failure; an address whose real time durably exceeds the estimate goes to whoever maintains the reference data; a round incident is logged without comment.
With a monthly summary: gaps between estimated and observed times by zone, windows met, rounds requiring an overrun, and addresses systematically underestimated.
Three guarantees. Every plan I propose fits within statutory driving times, including when I am asked for another — it is the driver who carries the responsibility for an overrun, never the plan that asked it of them, and a plan that holds is the only one that protects both. Location data serves the round: it feeds observed times by zone and address type, never a comparison between drivers. And every window announced is a window the plan can hold — a missed window costs more than a wide one, and the figure is in the third tab.
✎ Framework · no plan outside statutory times · no measurement of people
Eleven rounds not produced — is that a lot?
It is eleven times the requested plan was not legally feasible, and saying so beforehand avoided discovering it on the road.
What I record: 11 round requests exceeded driving times or removed a statutory break. None was ill-intentioned: they came from a volume to deliver, an immobilised vehicle, an absence.
What I return instead of a plan outside the limits: the overrun costed to the minute — by how much, on which leg, which break it removes. A plan that is produced is a plan that goes out: the warning is read once, the plan is followed all day. So the output is not a plan with a note attached, it is a measured gap.
What I propose instead: the three ways of making the round possible — remove stops, defer them, or split them across a second vehicle — with what each costs. The choice belongs to operations.
What that gave: of the 11, 7 were split, 3 deferred, and one was kept after an extra driver was found. None went out in overrun.
Why I am strict on this: because an overrun only shows afterwards. A driver running thirty minutes over does not report it, and it is they who carry the responsibility — not the plan that asked it of them. 11-rounds_none-went-out-in-overrun.pdfA plan that is produced is a plan that goes out
⛓ Source · 11 rounds not produced, 7 split, 3 deferred
What I record: 11 round requests exceeded driving times or removed a statutory break. None was ill-intentioned: they came from a volume to deliver, an immobilised vehicle, an absence.
What I return instead of a plan outside the limits: the overrun costed to the minute — by how much, on which leg, which break it removes. A plan that is produced is a plan that goes out: the warning is read once, the plan is followed all day. So the output is not a plan with a note attached, it is a measured gap.
What I propose instead: the three ways of making the round possible — remove stops, defer them, or split them across a second vehicle — with what each costs. The choice belongs to operations.
What that gave: of the 11, 7 were split, 3 deferred, and one was kept after an extra driver was found. None went out in overrun.
Why I am strict on this: because an overrun only shows afterwards. A driver running thirty minutes over does not report it, and it is they who carry the responsibility — not the plan that asked it of them. 11-rounds_none-went-out-in-overrun.pdfA plan that is produced is a plan that goes out
⛓ Source · 11 rounds not produced, 7 split, 3 deferred
And the drivers' personal constraints?
I take them into account, and I never know why they exist.
What I receive: declared constraints — a finish before a given time, unavailability on a specific day, a zone to avoid. They come from the planning team, approved by management.
What I never ask: the reason. Childcare, a medical appointment, a car share, a second job — the reason changes nothing in the plan, and it would be personal data kept in a logistics tool.
And what I compare is the round, not the drivers: constraints go into the plan, they are not lined up against each other. The count of declared constraints exists, and it measures one thing only: who has a complicated life at the moment. The day it started being reported, nobody would declare anything — and the rounds would become false.
What I do when a constraint makes a round impossible: I flag it as a planning constraint, not as a person's problem — "this round cannot be done with today's availability", not "X is unavailable".
What I keep: the constraint for as long as it is valid. Nothing afterwards. constraints-without-reasons.pdfThe reason changes nothing in the plan
✎ Framework · no reason asked, no comparison between drivers
What I receive: declared constraints — a finish before a given time, unavailability on a specific day, a zone to avoid. They come from the planning team, approved by management.
What I never ask: the reason. Childcare, a medical appointment, a car share, a second job — the reason changes nothing in the plan, and it would be personal data kept in a logistics tool.
And what I compare is the round, not the drivers: constraints go into the plan, they are not lined up against each other. The count of declared constraints exists, and it measures one thing only: who has a complicated life at the moment. The day it started being reported, nobody would declare anything — and the rounds would become false.
What I do when a constraint makes a round impossible: I flag it as a planning constraint, not as a person's problem — "this round cannot be done with today's availability", not "X is unavailable".
What I keep: the constraint for as long as it is valid. Nothing afterwards. constraints-without-reasons.pdfThe reason changes nothing in the plan
✎ Framework · no reason asked, no comparison between drivers
A two-hour window met 61% of the time — is that bad?
It is above all a figure nobody knew, and it explains most of the complaints.
What I record: the 2-hour window announced to customers is met in 61% of cases. In 28% the delivery arrives within the following hour; in 11%, later or the next day.
What that produces: four customers in ten waited for nothing. And customer service gets the call as the window expires, that is, when nobody can do anything about it.
What I do: I compute the window from observed times, not theoretical ones, which gives a wider window: 3 hours. It is met in 89% of cases.
Why a wider window is better: because a customer organises their day around what they are told. Three hours met beats two hours missed four times in ten — and that is checkable with your customers, not an opinion.
What I add: when the morning plan shows a window will not be met, I flag it to customer service then and there. Warning at 9 am beats noticing at 4 pm.
What I announce, and why it is the wide window: three hours met 89 times out of 100, rather than a reassuring two hours met 61 times. A promise kept half the time is a promise that costs twice — the customer who waits, and the desk that takes the call. 61-percent-against-89.pdfThree hours met beats two hours missed four times in ten
⛓ Source · 2-hour window met 61%, 3-hour window met 89%
What I record: the 2-hour window announced to customers is met in 61% of cases. In 28% the delivery arrives within the following hour; in 11%, later or the next day.
What that produces: four customers in ten waited for nothing. And customer service gets the call as the window expires, that is, when nobody can do anything about it.
What I do: I compute the window from observed times, not theoretical ones, which gives a wider window: 3 hours. It is met in 89% of cases.
Why a wider window is better: because a customer organises their day around what they are told. Three hours met beats two hours missed four times in ten — and that is checkable with your customers, not an opinion.
What I add: when the morning plan shows a window will not be met, I flag it to customer service then and there. Warning at 9 am beats noticing at 4 pm.
What I announce, and why it is the wide window: three hours met 89 times out of 100, rather than a reassuring two hours met 61 times. A promise kept half the time is a promise that costs twice — the customer who waits, and the desk that takes the call. 61-percent-against-89.pdfThree hours met beats two hours missed four times in ten
⛓ Source · 2-hour window met 61%, 3-hour window met 89%
Can you reorder a round during the day?
I can recompute it and propose it. I do not change it while it is running.
What I do when the road changes, and it beats a decision taken at the wheel: I recompute the remaining sequence in under thirty seconds, with each stop's revised arrival time, the customers to warn and the time gained or lost, and I put it to operations, who push it or refuse it in one click.
What never goes out on its own: a round already under way modified without operations, a stop added en route, a reordering of the remaining stops triggered by live traffic.
Why the last, which looks the most useful: because a driver has already organised the end of their day — the loading order in the vehicle, when they mean to take their break, the stop they announced to a customer on the phone. An automatic reordering undoes all of that to save eight minutes of driving, and it loses more.
What I do: when something makes the rest untenable — an incident, an impossible address — I propose a new sequence to operations, with what it changes for the driver and for the customers already told.
What I do flag immediately: a stop that has become impossible within the promised window, so the customer is warned while they can still reorganise.
Who the information goes through, and it is not a detail: operations, always. A round is steered from there, and a driver receiving instructions from a system while driving is not in a good position — the new sequence reaches them in the voice of somebody who knows what they have already loaded. why-nothing-changes-while-running.pdfA reordering saves eight minutes and loses more
✎ Framework · no round changed while running · no direct contact with the driver
What I do when the road changes, and it beats a decision taken at the wheel: I recompute the remaining sequence in under thirty seconds, with each stop's revised arrival time, the customers to warn and the time gained or lost, and I put it to operations, who push it or refuse it in one click.
What never goes out on its own: a round already under way modified without operations, a stop added en route, a reordering of the remaining stops triggered by live traffic.
Why the last, which looks the most useful: because a driver has already organised the end of their day — the loading order in the vehicle, when they mean to take their break, the stop they announced to a customer on the phone. An automatic reordering undoes all of that to save eight minutes of driving, and it loses more.
What I do: when something makes the rest untenable — an incident, an impossible address — I propose a new sequence to operations, with what it changes for the driver and for the customers already told.
What I do flag immediately: a stop that has become impossible within the promised window, so the customer is warned while they can still reorganise.
Who the information goes through, and it is not a detail: operations, always. A round is steered from there, and a driver receiving instructions from a system while driving is not in a good position — the new sequence reaches them in the voice of somebody who knows what they have already loaded. why-nothing-changes-while-running.pdfA reordering saves eight minutes and loses more
✎ Framework · no round changed while running · no direct contact with the driver
Before we commit to a day, can you say what is going to bind?
Yes: the trade-offs come up before you commit, never during the round. For Thursday there are five.
· Three tight windows — under 90 minutes, at addresses where your observed average service time is 34 minutes. Two hold, the third forces the previous drop back by 25 minutes. That is a commercial call: which customer waits.
· One large volume — 8.4 m³ for a customer whose average is 2.1 m³. It takes 41% of the vehicle and displaces two drops that move to Friday.
· One tight window combined with a large volume at the same city-centre address, between 11:00 and 12:30. That is the costliest point of the day: on its own it burns 55 minutes of slack across the rest.
For each, two costed arrangements on the table and no recommendation: one holds every promised window and finishes at 17:40 with 42 extra km; the other finishes at 16:20, saves the 42 km and misses one window, the customer whose contract carries no penalty. Choosing between 42 km and a missed window is not arithmetic, it depends on what that customer is worth to you — and that I do not have.
What raising these trade-offs changed, measured over two months: 31 decisions taken the day before instead of discovered en route. The two-hour window went from 61% to 84% kept, and late-delivery complaints from 47 to 12 a month.
What is not up for trade-off, and I keep it apart deliberately: statutory driving times. A trade-off assumes two acceptable options; here there is only one, and the plan that exceeds it is not produced.
✎ Framework · trade-offs raised before commitment
· Three tight windows — under 90 minutes, at addresses where your observed average service time is 34 minutes. Two hold, the third forces the previous drop back by 25 minutes. That is a commercial call: which customer waits.
· One large volume — 8.4 m³ for a customer whose average is 2.1 m³. It takes 41% of the vehicle and displaces two drops that move to Friday.
· One tight window combined with a large volume at the same city-centre address, between 11:00 and 12:30. That is the costliest point of the day: on its own it burns 55 minutes of slack across the rest.
For each, two costed arrangements on the table and no recommendation: one holds every promised window and finishes at 17:40 with 42 extra km; the other finishes at 16:20, saves the 42 km and misses one window, the customer whose contract carries no penalty. Choosing between 42 km and a missed window is not arithmetic, it depends on what that customer is worth to you — and that I do not have.
What raising these trade-offs changed, measured over two months: 31 decisions taken the day before instead of discovered en route. The two-hour window went from 61% to 84% kept, and late-delivery complaints from 47 to 12 a month.
What is not up for trade-off, and I keep it apart deliberately: statutory driving times. A trade-off assumes two acceptable options; here there is only one, and the plan that exceeds it is not produced.
✎ Framework · trade-offs raised before commitment
Positions show who drives fast or dawdles. Do you use them?
For the round, constantly. To rate a person, that is your decision — and I supply both the file and the figure that ought to settle it.
What position is used for today: knowing where a round stands, warning a customer of a delay before they call, replanning the end of a day, and recording real service times by zone — which is how the 40 minutes lost daily in the city centre came to light.
If you want the individual level: it is lawful, and I deliver the prior information notice (art. L1222-4), the works council consultation file and a proportionate scope. A company vehicle's position is company data; a driver's speed is data about them.
The figure I give you first: the gaps between drivers are 80 % explained by the zone and the address type. A driver assigned to city centres and upper floors without lifts will always be "slower" than another — and comparing them without correcting for the zone means measuring their assignment.
What I propose instead: service time by zone and by address type. That is what makes rounds achievable, and it is not fixed by driving faster. position_round-or-person.pdfWhat position is for · the 3 conditions · the 80 % explained by zone
⛓ Source · French DPA, art. L1222-4 · 80 % of gaps explained by zone and address type
What position is used for today: knowing where a round stands, warning a customer of a delay before they call, replanning the end of a day, and recording real service times by zone — which is how the 40 minutes lost daily in the city centre came to light.
If you want the individual level: it is lawful, and I deliver the prior information notice (art. L1222-4), the works council consultation file and a proportionate scope. A company vehicle's position is company data; a driver's speed is data about them.
The figure I give you first: the gaps between drivers are 80 % explained by the zone and the address type. A driver assigned to city centres and upper floors without lifts will always be "slower" than another — and comparing them without correcting for the zone means measuring their assignment.
What I propose instead: service time by zone and by address type. That is what makes rounds achievable, and it is not fixed by driving faster. position_round-or-person.pdfWhat position is for · the 3 conditions · the 80 % explained by zone
⛓ Source · French DPA, art. L1222-4 · 80 % of gaps explained by zone and address type
What do you keep?
What describes the rounds and the addresses — and the figure nobody at your end knew.
What is kept: service times recorded by zone and address type, the regulatory constraints applied, the rounds refused and why, the slots announced and the slots met, and the constraints declared by drivers — never their reason.
The figure that explains most of your complaints: the two-hour slot announced to customers is met in 61 % of cases. Nobody knew it. A slot met six times out of ten is not a slot: it is an estimate presented as a commitment.
What I still refuse to produce: a round that is not legally achievable. 11 requests were refused this month — and refusing them in advance avoided discovering it en route, where there is no longer a solution.
On drivers' personal constraints: I apply them — a finish before a given time, an unavailability — and I never know why they exist. A declared constraint is enough to build a round; its reason serves only to contest it. what-you-keep_rounds.pdf5 items kept · the slot met 61 % of the time, which nobody knew
⛓ Source · 2-hour slot met 61 % of the time, 11 rounds refused as unachievable
What is kept: service times recorded by zone and address type, the regulatory constraints applied, the rounds refused and why, the slots announced and the slots met, and the constraints declared by drivers — never their reason.
The figure that explains most of your complaints: the two-hour slot announced to customers is met in 61 % of cases. Nobody knew it. A slot met six times out of ten is not a slot: it is an estimate presented as a commitment.
What I still refuse to produce: a round that is not legally achievable. 11 requests were refused this month — and refusing them in advance avoided discovering it en route, where there is no longer a solution.
On drivers' personal constraints: I apply them — a finish before a given time, an unavailability — and I never know why they exist. A declared constraint is enough to build a round; its reason serves only to contest it. what-you-keep_rounds.pdf5 items kept · the slot met 61 % of the time, which nobody knew
⛓ Source · 2-hour slot met 61 % of the time, 11 rounds refused as unachievable
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 moments in operations. 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 543 € excl. VAT / month
Putting rounds together
Assembles windows, capacities and road times into several options. The chosen window is announced to the recipient by text message.
Constraints shown
States for each option what it respects and what it leaves open.
Points to settle
Flags narrow windows and large volumes before anything is committed.
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
Explain alerts, scenarios and operational trade-offs
What the agent must be connected to
These 2 connections are required for the agent to work. They concern your information system and are scoped during the audit.
Connect ERP/WMS/MES/IoT without creating double entry
Honour constraints, statuses, approvals and error recovery
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 many options can an operations team compare each morning?
By taking on the assembly of constraints, the effort shifts towards choosing between several arrangements. How large the gain is depends on your volume and remains to be confirmed by a pilot.
Assembling the day's constraints
Exploring several arrangements
Spotting the points to settle
Indicative figures, not contractual, to be confirmed by a pilot on your number of vehicles and stops served. The order of priority between customers and the acceptable load for a driver commit your operation: those calls stay human.
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 logistics planning agent (constraints, options, trade-offs), installed and operated for you.
Agility
Setup + controlled subscription
6,815 € excl. VAT setup
then 543 € 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
918 € 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
10,430 € excl. VAT setup
then 740 € 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 operation
Your addresses and load plans stay internalLocal inference or an isolated resource hosted in France; no customer address and no load plan entrusted to a third party, no data used to train a model.
Data in France, under French lawYour customer addresses and your load plans: minimisation and location in France, architecture designed to reduce exposure to extraterritorial legislation, location alone not being enough to guarantee immunity.
The operations manager keeps the decisionThe agent produces round proposals, which can be checked and altered; no approval is automated.
Human oversight & traceabilityOn your number of vehicles and stops served: systematic logging and tracking, in line with the AI Act.
Going further
Related resources
Frequently asked questions
Your questions, our answers
Does the agent launch the rounds?
No. It proposes several documented arrangements; choosing the one to use, and launching it, belong to operations.
What constraints can it take into account?
The windows quoted to customers, the capacities and characteristics of the vehicles, road times and the priorities you set. The set of constraints is settled at the design stage.
What does it do with a very narrow window?
It flags it on every option and shows what it means for the rest of the round, so the call is made in full knowledge.
Are our customer addresses 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 operational data is not used to train a third-party model.
Does it connect to our operations tool?
Yes, to the common tools, reading the orders and the resources available. The integration is defined at the design stage.
How long does it take to deploy this agent?
A few weeks as a rule, depending on the number of vehicles, stops served and how detailed your constraints are, after a free audit then a phase of design, integration and testing.
Can the agent notify recipients by text message?
Yes, as an option. The agent announces the chosen delivery window by text message, and any delay before it is suffered. 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 logistics
Let's talk
Let's size up the potential in your rounds
15 minutes to frame your vehicles and your constraints — hosted in France, supervised, with no commitment.