Internal platformOrder operations
Control Tower: one place to find, fix and prevent stuck orders.
Orders sometimes get stuck between payment and delivery, and the order system does not say why. Control Tower is the internal platform I built to find them, explain them, and fix them safely.
- Role
- Owner, built end to end
- Live since
- May 2026
- Covers
- 21 tools in 5 groups
- Used by
- Web, store and platform teams
What it is, in one minute
An order is a relay: each team hands it to the next. Control Tower watches every handover and steps in when one is missed.
Think of air traffic control. It does not fly the planes. It sees all of them at once, spots the one in trouble, and talks it down safely. Control Tower does that for orders.
The life of an order
Where it can get stuckPlaced
Paid online or in a store
Where it can get stuck: Never leaves the first step
Checked
Payment and address confirmed
Where it can get stuck: Payment or address on hold
Released
Sent to a warehouse or store
Where it can get stuck: Sent to the wrong place
Prepared
Picked, packed or tailored
Where it can get stuck: Short, or never picked
Shipped
Handed to the carrier
Where it can get stuck: Shipped, never recorded
Closed
Delivered, collected or returned
Where it can get stuck: Delivered, never closed
What Control Tower does about it
- 01
Find
Sorts every stuck order into a named cause.
- 02
Explain
Says what went wrong, in the words of whoever is asking.
- 03
Fix
Repairs the order behind four checks, and keeps the evidence.
- 04
Automate
Runs routine repairs on a schedule, inside strict rules.
- 05
Prove
Scores each diagnosis against the tickets that were resolved.
What it replaced
Before, an order that looked wrong meant a manual investigation: someone who knew the system, five screens, and a conclusion nobody else could check. The backlog was one number with no names in it, the fix was whatever the last person had done, and the screen used to repair an order could just as easily break it.
The question
What it took
Why is this order stuck?
Five screens, and knowing which order to open them in
Which other orders are stuck the same way?
Nobody could ask that at all
Was the fix applied, and did it work?
Open the same screens again and look
How often is our diagnosis right?
No way to know
The system held every answer. Getting to one took a person, an afternoon, and a repair screen with the wrong button one click away.
More than a stuck order list
It started as one board of stuck orders. It is now 21 tools in five groups, each one a question the operations team used to answer by hand.
Find
What is stuck, and where
5 tools
Pattern board
Every stuck order sorted into a named cause, with the ones no pattern explains yet counted live.
Eight daily reports
Stuck on open, awaiting payment, address holds, totals that do not add up, refunds, refund gift cards, store shipments ageing, failed order events.
Health score
Every monitor ranked into one stability gauge, so the worst problem is the first thing on screen.
Order lookup
One order, read live, with its history, its tickets and the diagnosis in one view.
Unit inventory
One item followed by its tag or product code, with every movement on a timeline.
Explain
Why it happened
4 tools
Plain words, per role
The same order explained six ways: operations get the action, technical staff the detail, business the outcome.
Setup checks
The order system's configuration compared with the agreed version, so drift shows before it breaks an order.
Atlas
A map of 69 components and over 2,300 settings that shows what a change would touch.
API reference
A curated guide to the order system's API, which doubles as the list of what the AI may read.
Fix
Fix it, with a record
4 tools
Guided fix
A 30 step repair per order: a rehearsal first, the order number typed to go live, the evidence kept.
Batch fixes
Many orders in one run. An interrupted run resumes by itself, and a very large order moves to a runner built for it.
One click tickets
The right template and the right team from the order page, kept in step as the order moves.
Ticket board and escalations
Tickets from the tool and from people in one board, with the store to support handover inside it.
Automate
Repairs that run themselves
4 tools
Scheduled playbooks
Four routine repairs that run each morning: find the order, confirm it live, fix it, read it back.
Failed event sweep
Three times a day it finds the messages the system parked and resends the ones proven safe.
Warehouse cross check
Finds shipments the warehouse confirmed that never reached the order system.
Daily digest and ticket linking
A morning summary of what the team did, and tickets matched to their orders every fifteen minutes.
Prove
Trust, measured
4 tools
Accuracy scoreboard
Each pattern checked against resolved tickets. Under 85 percent right, it does not go live.
Six roles, checked on the server
What each person may see and do is decided on the server, never by hiding a button.
Activity log
Every action recorded with who and when, exportable as a report per person.
A read only door for AI
The signed in, approved reads that Omniscope's AI tools use, so an AI can investigate without holding a password.
How a fix gets made
Fixing is the one thing the tool does that changes an order. Four checks sit between a person and a live change, and a run cannot skip any of them.
One fix, start to finish
Rehearsal, nothing sent
- Read the order
- Close the store delivery
- Match the payment
- Ship the open lines
- Close the order
RehearsalEvery step previewed, nothing sent
A fix that fails a check stops there, visibly. A fix that passes all four leaves a ticket anyone can read afterwards.
When it runs by itself
Routine repairs now run on a schedule. Automatic does not mean unchecked: a job changes an order only when four things are true at once, and every run is recorded.
One scheduled job
- 01
Detect
A fixed query finds the orders that match the playbook.
- 02
Confirm
Each order is read live, in case it has moved since.
- 03
Fix
The repair runs, one order at a time, within a cap per run.
- 04
Read back
The order is read again, and the result goes on the record.
All four must be true before anything is written
Set live by an administrator
Who types the job's name to confirm it.
The master switch is on
One switch in Settings stops every live repair.
No known blocker
A job with an open risk stays a rehearsal.
The right machine
Only the scheduled runner may write. Anywhere else, the same job rehearses.
Otherwise it rehearses
Small by design: capped per run, never twice for the same order, stopping for the day if something repeats, and off by default until a person has watched it work.
My role
Control Tower is mine end to end: the product, the patterns, the fix, the automation and the app, built as the analyst who used to do these investigations by hand.
- 01Turned recurring stuck order investigations into named patterns, each with a written procedure and a ticket template.
- 02Wrote the 30 step fix and hardened it over more than fifteen versions, then turned the most common repairs into scheduled playbooks.
- 03Designed the scoring, so a pattern goes live on measured results rather than on a hunch.
- 04Mapped the six kinds of user and brought each group on board, from store operations to business.
- 05Built the safety net that lets it change fast: 69 automated test suites on every change, and the real app driven in a browser before a screen ships.
- 06Now handing the tool to the web operations team and moving it, one piece at a time, onto the company's own cloud.
Given it again, I would build the scoring before the second pattern. Running a new pattern quietly alongside until it proves itself is what made them trustworthy, and it arrived after the first one had already gone live.
What changed
3,500
Stuck orders sorted into named causes
The backlog was one number with no names in it. It is now a set of named causes, each with a written procedure, a ticket and a score, and the most common repairs no longer wait for a person.
- Before
- After
- A manual investigation per order
- A named cause with a written procedure
- A repair screen that could also break things
- Rehearsal, typed confirmation, evidence
- The same repair, by hand, every morning
- A scheduled playbook inside four rules
- Whoever knew the system
- Six kinds of user, the same data
- No idea how often we were right
- Accuracy measured per pattern
8
Daily reports, each with a cause per row
85%
How often a pattern must be right before it goes live
4
Routine repairs that now run on a schedule
Built with
- TypeScript
- Next.js
- BigQuery
- Supabase
- Postman & Newman
- Jira
- Google & Atlassian OAuth
- Vercel
- GitHub Actions
Why I built it
Behind every stuck order is a customer waiting for a delivery, and a colleague answering why it has not arrived.
I wanted the team to find those orders the same day, fix them without risk, and trust the answer. And because the tool sits on company and customer data, privacy had to be part of the design from the first line, not added at the end.
Private by design
Customer data stays inside
Payment card details are masked on the server, and there is no way to reveal them.
Access is decided on the server
Every page and action is checked against the person's role. Hiding a button is not security.
Every change leaves a record
Who did what, when, and the evidence before and after.
AI can read, never write
The AI door is read only by construction and never holds a password.
Company sign-in, company cloud
People sign in with their work account, and the platform is moving onto the company's own cloud.