Turn manual delivery changes into controlled, auditable automation.
When customer service teams modify routes directly in Route4Me, every change is a gamble — no standard process, no safety net, no record. This system replaces that with structured intake, deterministic logic, and a permanent audit trail.
The problem
Manual route edits carry three compounding risks.
Risk
Route edits made directly in Route4Me have no safety net. A wrong stop modified, an order silently removed — by the time anyone notices, the driver is already on the road.
Inconsistency
The same request gets handled differently depending on who picks it up. No standard process means different outcomes, different fields touched, different interpretations of the same instruction.
Invisibility
Nothing records what changed, who did it, or why. When something goes wrong there is no trail to follow — only guesswork and blame.
The problem worth solving
For this logistics client, delivery change requests came in all day — customers wanting to skip a week, add an extra box, update a delivery address, or reschedule a missed drop. Each request landed in someone's inbox, they'd log into the delivery software, make the change by hand, and move on.
Logistics kept their own records of how changes were performed within the system. But there was no real audit trail connecting the original request to what was actually modified — who made the change, when, and exactly what was touched. When a delivery went wrong, you could see the end result, but not the path that led there. Every investigation started from scratch.
The problem wasn't that the team was doing a bad job. The problem was that the process gave them no support. One slip in a busy week and a customer had a bad experience that nobody could fully explain or prevent from happening again.
| Ready? | Change Type | Pack Day | Delivery Day | Customer |
|---|---|---|---|---|
| ✓ | Remove Order | Thursday AM | Mon 26 May | Jane Doe |
| ✓ | Add Spare Box Delivery | Thursday PM | Tue 27 May | Jane Doe |
| ✓ | Update Delivery Day | Friday AM | Mon → Tue | Jane Doe |
The interesting constraint
The core requirement wasn't a specific tool — it was visibility. The intake needed to live somewhere the whole operation could see it, not buried inside a single department's workflow. Delivery changes don't just affect logistics: a skipped week or an address update has implications for customer service, billing, and other parts of the business.
Google Sheets turned out to be exactly the right fit. The team already worked in spreadsheets every day, and with the system built on Google's cloud infrastructure, connecting a live Sheet to the automation was the natural choice. No new tool to learn, no separate login, no siloed data — just a shared document that any part of the operation could open and check.
The intake, the result written back, the status visible to anyone with access — all of it lives in the same place the team was already working.
| Time | Change Type | Customer | Delivery Day | Outcome | Status |
|---|---|---|---|---|---|
| 07:01 | Remove Order | Jane Doe | Mon 26 May | Order removed from run | ✅ Done |
| 07:02 | Add Spare Box Delivery | Jane Doe | Tue 27 May | Added to Tuesday run | ✅ Done |
| 07:30 | Update Delivery Day | Jane Doe | Mon → Tue | Delivery day updated | ✅ Done |
| 07:55 | Add Redelivery | Jane Doe | Fri 22 May | Rescheduled for Friday | ✅ Done |
| 09:32 | Add Spare Box Delivery | Jane Doe | Mon 26 May | Already has an order | ⚠️ Review |
How a request actually gets handled
When a customer service rep submits a row, the system picks it up automatically — no emails, no phone calls, no manual handoff.
It reads the request, confirms everything required is there, and identifies the type of change: address update, skipped week, extra product, redelivery, and so on across fourteen distinct change types. Each has its own logic, and the system applies it the same way every single time — not depending on who happens to be available, or how busy the operations team is that morning.
If the change is valid and safe to apply, it goes through. The delivery software is updated, and the spreadsheet row updates to confirm it's done. If something isn't right — the delivery run has already started, it's a public holiday week, a required field is missing — the system flags it instead of guessing. The operations team gets a Slack message explaining exactly what needs their attention and why.
Every request, successful or not, gets permanently recorded: what was submitted, what the system did, and when. Managers can see a full picture of what's been processed at any point, without needing to ask anyone.
✅ Remove Order processed
- Route
- Monday Delivery Run ↗
- Customer
- Jane Doe
- Del. day
- Monday 26 May
- Removed
- 4 meals removed from run
Sheet row 8 · Mon 26 May · 07:01am
How an order reaches the route
For Add Order requests, the system doesn't push an address directly into the routing software. It works through a validated sequence — stopping at each step if anything is uncertain.
The pivotal step is geocoding. The full street address is sent to the routing software's geocoder. Only a high-confidence result lets the automation continue. Medium, low, or missing results go to manual review — the system does not place a stop on approximate coordinates.
Once the stop is created, the system writes both native routing fields and business-specific custom data: meals, order reference, marketplace extras, delivery instructions, and sequencing metadata — making the routing software the operational source of truth for the run.
Add Order — step by step
Validate delivery rules
Delivery day checked against pack-day rules for the postcode. Non-matching requests are flagged before the routing software is touched.
Geocode the address
Full street address sent for geocoding. High confidence required — medium, low, or missing results go to manual review, not the route.
Select best matching route
Routes filtered by delivery type and date. Spatial scoring compares the new stop's coordinates against existing stops to find the closest fit.
Segment-aware stop placement
Stop inserted between the most suitable neighbouring stops — not appended to the end. Preserves route flow in dense delivery areas.
Write business fields
Native route fields plus custom business data attached to the stop: meals, order reference, marketplace extras, and driver instructions.
Segment-aware stop placement
Once geocoded and matched to a route, the new stop isn't simply appended to the end of the run. The system evaluates adjacent route segments to find the most appropriate insertion point.
This matters in dense suburbs where two nearby addresses may sit on very different parts of a route. Inserting between the right pair of stops preserves flow and avoids backtracking — the difference between a driver who can work efficiently and one who has to double back.
The map shows a live delivery run. Watch the amber marker resolve into a numbered stop as the system identifies the optimal insertion point and updates the sequence.
Solution overview
Five layers. Every change follows the same path.
Google Sheet intake
Customer service submits via a structured spreadsheet. Dropdowns and enforced formats prevent free-form ambiguity before it reaches the system.
Validation
Required fields are checked before anything runs. Ambiguous or incomplete inputs are routed to manual review — the system does not proceed on a guess.
Route4Me execution
The correct handler fires based on change type. Strict field allowlists ensure only the intended update reaches the route.
Audit log
Every action writes a permanent record: input data, execution result, route IDs, sequence position, and timestamp.
Slack feedback
The team receives a human-readable summary of the outcome — success, needs review, or failed — in the same polling cycle.
Business impact
Built on evidence, not estimates.
Change types
0
operational change types standardised — every request handled consistently, regardless of who processes it
Validation
Built with automated testing and validation at every layer
Success paths, failure cases, and operational edge cases — all covered before anything reaches your operation
Audit trail
Every processed change has a full audit record
Input data, execution result, route IDs, sequence position, and timestamp — permanently logged
Safety
Unsafe changes blocked automatically, not guessed at
Ambiguous or risky inputs are held for manual review — the system never silently proceeds when intent is unclear
How it works
What happens, and how it's delivered.
Two flows, one system. The first shows what happens to every request — deterministic, no exceptions. The second shows how I build and hand it over to your team.
What happens to every request
01
Submit
Customer service fills a structured row in the Google Sheet. Dropdowns enforce valid inputs — no free-form ambiguity.
02
Validate
Required fields are checked immediately. Invalid or ambiguous submissions are flagged for manual review before anything runs.
03
Execute
The correct handler runs based on change type. Strict field allowlists mean only the intended update reaches Route4Me.
04
Notify
A Slack message summarises the outcome — success, needs review, or failed — with route name and key change details.
05
Audit
Every action writes a permanent record to the audit log: input data, result, route IDs, sequence, and timestamp.
How I deliver this
01
Discovery
Map your current workflow and pain points — what's manual, what's risky, what costs time.
02
Build
Purpose-built automation engine, configured to your operations — not a generic template.
03
Test
Simulated and real-world validation before go-live — so the system earns trust before it runs live.
04
Handover
Your team trained, documentation provided, system handed over — ready to run without me.
Built-in safeguards
Trust signals, not technical checkboxes.
These weren't bolted on after the fact. Operational automation has to be safe before it's fast — so these protections were designed in from the start.
Sticker-lock handling
Locked stops are detected before execution. The change is held for manual review rather than silently overwriting a protected record.
Public-holiday logic
Holiday dates are checked against the delivery calendar. Affected routes are handled correctly rather than treated as standard operating days.
Duplicate prevention
Re-submitted rows are identified and skipped. Running the same request twice produces one result, not two conflicting ones.
Route-start protection
Changes targeting a route that has already commenced are blocked automatically rather than applied mid-run.
Manual review states
Anything ambiguous or outside expected parameters receives NEEDS_REVIEW status and surfaces for a human decision. The system never silently proceeds when the intent is unclear.
Technologies used
Have a manual operations workflow like this?
Let's automate it safely — structured intake, deterministic logic, and full visibility from day one.