Case study  // France · Meal delivery operator · 2025

From 37% error rate
to operational autonomy.

A meal delivery operator in France deployed Barmus across three modules in 72 hours. This is what changed — in numbers.

−98.6%
Allocation error rate
37% → 0.5%
97%
Customer tickets automated
Care+ · zero human intervention
+40%
Order volume growth
Zero additional headcount
72h
Contract to production
Full integration, no rebuild
Operator profile

The operator runs a subscription meal delivery service across Île-de-France — six production sites, ten active couriers, and a peak volume of 200 orders per week. A real-time, multi-site operation with tight delivery windows and a high-expectation customer base.

Before Barmus, four people managed all operational coordination — slot planning, courier dispatch, order modifications, and inbound customer requests. The workload was over 12 hours of active coordination per day, and the error rate on slot and resource assignments had reached 37%.

The constraint was clear: the operation couldn't scale without either increasing headcount substantially, or replacing manual coordination with software that could run it autonomously.

Type
Meal delivery · subscription model
Geography
France · multi-site
Production sites
6 sites · full-time staff
Active couriers
10
Peak weekly volume
200 orders / week
Ops team (pre-Barmus)
4 people · 12h+/day coordination
Existing stack
WooCommerce + custom logistics tooling
Before and after
Before Barmus
37%
Slot and resource allocation error rate. Manual assignment across 10 couriers, 6 sites, and 200 weekly orders generated constant rescheduling and delivery failures.
200+
Inbound customer tickets per week. Order status, modifications, delays — all handled manually by the ops team, adding hours of daily interruption load.
12h
Daily coordination minimum. 4 ops staff managing dispatch, planning, client requests, and error correction — with no capacity left for growth.
0
Headroom for scaling. Any increase in order volume required proportional increase in ops headcount. The model had no leverage.
After Barmus
0.5%
Allocation error rate. The APX engine runs every slot booking and courier assignment against live constraint state. Structural overcommit is impossible.
97%
Customer tickets resolved autonomously. Care+ handles status, modifications, and escalations directly from live system state — without human input.
3.5
Ops roles reassigned. Coordination is now handled by the software. Former ops staff were redeployed to client acquisition and business development.
+40%
Volume growth, zero new hires. Order volume increased 40% post-deployment. The operation absorbed the growth with the same team — minus the coordination overhead.
Deployment timeline
Hour 0
Technical scoping
30-minute call. Existing stack mapped. WooCommerce integration scope defined. Module configuration set.
Hour 4
API integration
Barmus connected to WooCommerce and logistics tooling. No migration. Existing order data preserved.
Hour 24
Parallel run
Logistics and Connect running alongside manual ops. Constraint engine live. Allocation errors drop immediately.
Hour 72
Full production
All three modules active. Manual coordination process retired. Care+ handling 100% of inbound from day one.
What required adjustment

Not everything runs perfectly on day one. Here is what required recalibration during the first two weeks of operation — and how it was resolved.

Week 1 · Routing edge case
Multi-zone distance model underestimated peak-hour travel times
During the first week, Connect's routing model was using off-peak Google Distance Matrix estimates for afternoon delivery windows. Routes in dense zones (Paris inner ring) were systematically 8–12 minutes tighter than actual.
Time-window constraints recalibrated per zone. Peak-hour profiles added to distance model. Resolved within 4 days, no delivery failures during the adjustment period.
Week 2 · Capacity model edge case
Same-day slot modification logic required constraint expansion
The initial APX configuration treated same-day slot modifications with the same feasibility rules as advance bookings. In practice, ~6% of modifications involved requests that were technically infeasible but operationally executable with manual courier coordination.
A secondary feasibility threshold introduced for same-day modifications. Ops team retains manual override capability for edge cases — used on average twice per week.
Ongoing · Human override
Manual override capability retained by design
Barmus does not remove human judgment from the operation — it removes the need for it in routine decisions. Dispatchers retain full override capability on any assignment or route. This is intentional: edge cases exist that no constraint model fully anticipates.
Override used 2–3× per week on average, down from constant manual intervention pre-deployment. Ops team now monitors rather than coordinates.
Ongoing · Care+ escalation
3% of tickets still require human resolution
97% automation is not 100%. Care+ escalates roughly 6 tickets per week to a human agent. These are predominantly complex multi-order account issues, billing disputes, or cases where system state alone is insufficient context for resolution.
Escalation packets include full conversation history, order state snapshot, and resolution path attempted. Human agents close these in under 4 minutes on average.
Modules deployed
L1 · Core
Logistics
Supply chain & production software
Eliminated slot overcommit entirely. Allocation error rate dropped from 37% to 0.5% within the first week of operation. Courier assignment now runs in real time against live availability and distance data.
L2 · AI
Connect
Routing & fleet optimization software
Delivery rounds planned and optimized automatically across 10 couriers and all of Île-de-France. Route recalculation in real time as new orders arrive and traffic conditions evolve. Dispatch team reduced to monitoring role.
L3 · AI
Care+
Customer operations software
97% of the 200+ weekly inbound tickets resolved autonomously, including order status, modification requests, and delivery updates. Answers derived from live system data — not scripts. 3% escalated with full context.
The operation grew 40% in volume
without a single new ops hire.
The 3.5 roles previously absorbed by manual coordination were redeployed to client acquisition and territorial expansion. The software runs the operation. The team builds the business.
Integration architecture

Barmus connected to the operator's existing WooCommerce stack and custom logistics tooling at the API and webhook level. No data migration. No schema changes. The existing order flow remained intact.

L1 (Logistics) subscribes to order events from WooCommerce via webhook. Each event triggers a constraint evaluation cycle — slot feasibility checked, resource scored and assigned, state committed atomically. L2 (Connect) receives committed assignments from L1 and enters them into the live routing graph. L3 (Care+) reads from both L1 and L2 state to resolve inbound queries.

The integration surface is intentionally minimal: three inbound webhook endpoints and two outbound API surfaces. The operator's stack did not change — Barmus layered on top of it.

// Integration surface — Barmus ↔ WooCommerce // Inbound (WooCommerce → Barmus) POST /api/v1/events/order.created POST /api/v1/events/order.modified POST /api/v1/events/order.cancelled // Outbound (Barmus → operator systems) GET /api/v1/slots/availability ← storefront GET /api/v1/delivery/eta/:orderId ← customer UI // Constraint evaluation cycle (L1) order.created → slot_feasibility_check(product, interval, site) → resource_score(availability_matrix, distance) → commit_atomic() | reject_at_boundary() → emit("assignment.committed") → L2

Your operation.
Same result.

Barmus deploys in under 72 hours at the API level — no migration, no rebuild. Our engineering team scopes your integration in a 30-minute technical call.

Request a technical evaluation

© 2026 Barmus Systems Ltd — All rights reserved

Case study published with operator consent. Identity withheld by mutual agreement.

All systems nominal