A mobility firm: one screen in place of seventeen tabs
Two operators on the counter where one would have done. A public house that the night manager had stopped linking to because the figures on it were a day behind. We rebuilt the ledger and made the web
The reading
A regional mobility firm. Vehicles, scooters, a parts counter, a workshop booking book, and a public-facing site that the previous web shop had built in 2019 and which the night manager had privately given up on. The counter screen had seventeen tabs open at any one time. On a busy Saturday, two operators were needed to keep the counter moving — one to take the customer, one to keep the tabs in agreement with each other.
The partners had been quoted for a “bookings platform” and separately for a website refresh. The two quotations assumed the website and the ledger were different pieces of work, which was the first problem.
The seventeen tabs
- Inventory, in a spreadsheet.
- Day-sheet of bookings, in a Google doc.
- Workshop queue, on a whiteboard photographed on a phone.
- Public prices, on the website, out of date.
- Customer file, in the till.
- Hire agreement PDFs, in a shared drive.
- Fault log, in a WhatsApp group.
- Deposit ledger, in a separate spreadsheet.
- … and nine others, each defensible on its own.
The seventeen tabs were the symptom. The underlying fact was that no single record of the firm existed anywhere. Each tab was a partial view, maintained by someone who did not have time to reconcile it with the others.
What we built
One ledger. The vehicle is a record. The booking is a record. The hire agreement is a record. The customer is a record. The public website — and this is the point the partners had not previously considered — is the ledger’s first page, rendered for the public rather than for the counter.
The night manager now works alone. The seventeen tabs are one tab. The public prices are the ledger’s prices because they are the same object. A fault reported by a customer at 23:47 is on the proprietor’s phone before midnight.
Six weeks from enquiry to the first booking taken on the new ledger.
The numbers at ninety days
| What | Before | Ninety days in |
|---|---|---|
| Operators on the counter / Saturday | 2 | 1 |
| Tabs open on the counter screen | ~17 | 1 |
| Spreadsheets of record | 11 | 0 |
| Public prices vs. ledger prices | ~ 3 weeks out | real-time |
| Fault notice to proprietor | hours or days | < 2 minutes |
| Booking abandonments on the website | 1 in 2 | 1 in 11 |
What this is not
It is not a bookings platform bolted onto an unrelated website. The firm tried that in 2021 and the two systems did not know about each other. Bookings existed on the website that the counter could not see; walk-ins existed at the counter that the website continued to offer. The customer would arrive to collect a vehicle already hired to someone else.
A ledger that is split across two systems is two ledgers. There is no amount of synchronisation that recovers the fact that the firm, in that configuration, has two conflicting books.
The standard
A new night manager should be running the firm on their own by the end of the first weekend. That is the test. The ledger holds the business; the person on duty consults the ledger and acts on it. The seventeen tabs are not an obstacle a new hire has to learn to navigate; the seventeen tabs should not have existed in the first place.
When the ledger is one, the firm is one.