The Host and Operations Consoles: There Is No Such Thing as "the Back Office"

The first eight chapters were the skeleton of a transaction: comments in, stock held, money collected, goods out the door. This one switches viewpoint — what the people standing in the live-stream room actually see. Before talking about “the back office”, here’s the conclusion: this system has no such thing as a back office. It has a set of role interfaces, and what each person opens does only the thing they’re doing right now.

A live stream is a performance

Start with who does what. The host is in front of the camera calling keys, quoting prices, chasing the supplier for more stock — they have no time to operate any platform. Every platform action goes to the live assistant: product information, opening and closing bidding, adding stock. But the host can’t perform blind: how many units sold, who’s ordering, how many people are watching — they need that live, or they can’t hold the stream’s rhythm — something sells out and they add more on the spot; the room goes cold and they switch product fast.

In theatre terms: the actor reads the teleprompter, the stage manager works the machinery. That division decides directly how the interfaces are cut:

The host dashboard: data is a sense of rhythm

The host’s screen has no button worth pressing — it’s the sole customer of that WebSocket from the opening move: comments pushed live, how many units sold, who ordered, the viewer count pulled from the Facebook API. All of it looking only.

Two details worth pausing on:

• The comment stream carries blocklist tags. At the system level, a blocklisted person’s comments aren’t processed by the batch at all; at the interface level, the host can see that this person is blocklisted — which gives live human judgment (skip this one out loud, don’t hold stock) real-time intelligence. Risk control isn’t only a filter, it’s an intelligence card handed to the decision-maker, and that thread (along with how the batch checks the blocklist quickly) gets picked up in the risk chapter.
• The data is a mash-up of our own facts and the platform’s. Units sold and who ordered come from our ledger, the viewer count from the Facebook API — the host doesn’t care about the source, they care whether the room is hot and whether goods are moving. A dashboard is organised by the user’s question, not by where the data comes from — the same thing I later wrote in the Grafana series as “one panel answers one question”, except back then I had none of the vocabulary.

Assistant and operations: two rhythms of a console

The assistant’s dashboard is the live console, with buttons that follow the stream’s minute-by-minute rhythm: product information (supporting both entry in advance and opening on the fly — a host who gets goods on set wants to sell them, and the system doesn’t bet on “there’ll be time to fill it in first”), open bidding, close bidding, re-open (the re-call‘s UI shell), add stock — the person retrying against that hot row in the stock chapter is the assistant.

Operations’ pages are a separate set, on a per-round rhythm: closing a round (the big clean), shipping fee settings, goods-in records, allocation. Both are “operating”, but live operation and round management were split into two interfaces — because the rhythm of the operations differs: one is counted in seconds and races the live moment, the other in days and manages a round opening and closing. Mix them into one screen and the fast one gets blocked by the slow one.

admin: a lab for uncertain requirements

The engineers’ own interface is Django admin, and only engineers use it — the first reason is plain: touching the DB directly is too dangerous, and admin is a layer of safe console you can’t fat-finger, convenient for managing Celery task schedules on the side.

The second reason deserves its own section: admin is a lab for uncertain requirements. A request arrives, building it properly takes time, and nobody is sure it’s a real requirement — the two most expensive mistakes being “spend two weeks on a beautiful interface nobody uses” and “refuse outright and miss a real one”. The third path we took: stitch a not-very-usable rough draft out of admin features and keep the requirement alive:

A real requirement gets complained about as “this is so hard to use” — the complaint is the graduation application, and it’s worth promoting to a purpose-built interface; a fake one dies quietly inside admin at almost no cost. Looking back, the other half of “a dozen features shipped a day” is right here: not every feature was built well, but every feature cost exactly what it was worth.

What a rebuild would add

Almost everything here survives a rebuild — the role split, the maturity spectrum, separating looking from doing are all right. Two additions:

1. Audit logs for every back-office operation. Goods-in and allocation already had records, but opening and closing bidding, adding stock and changing shipping fees should all leave a trace too (who, when, what changed) — it’s the evidence chain for the reconciliation chapter and the foundation for the permissions chapter.
2. Restocking through the adjustments ledger. The adjustments ledger from the stock chapter — whose beneficiary is exactly that assistant standing in the live room hitting a button that fails and having to hit it again.

Reflections

Your internal users are your heaviest power users

An external customer uses your system for three minutes a day; an assistant or an operator uses it for eight hours. A customer who hits friction leaves; when an assistant hits friction, the host’s rhythm breaks on camera. Every second of latency and every mis-click in an internal tool is amplified into real money in the live room. This team treated internal tools as products from day one (the identity chapter covered where that came from), and what I’ve come to believe since is: the quality of your internal tools decides not “whether staff are happy” but how fast your whole operation can react — it’s the conduction speed of the organisation’s nervous system.

A rough draft is strategy, not shame

What the admin lab taught me: building a product is fundamentally about managing uncertainty, and an interface is one of the most expensive ways to place a bet. Making every requirement beautiful means betting heavily on every unproven hypothesis; the lab lets the size of the bet follow the evidence — and a rough draft’s awkwardness isn’t a quality problem, it’s a graduation bar left there deliberately: only a real requirement is worth tolerating awkwardness to keep using. An engineer’s pride often can’t stand shipping a rough draft — but roughness that fits the moment is more professional than polish that doesn’t.

Designing for looking and designing for doing are two different crafts

The host’s screen has not one button and the assistant’s is all buttons — that’s not a coincidence, it’s the task deciding the interface: an interface for looking wants to be understood at a glance (information density, immediacy, no interruptions), and an interface for doing wants to prevent mistakes (explicit actions, predictable results, guardrails). Most unusable back offices are sick with exactly this: the two mashed together, so people who came to look navigate a wall of buttons and people who came to act hunt for the entrance inside a chart. The test for splitting an interface was never “are these features related?”, it’s “what is this person’s task right now?” — one screen, one task, one rhythm.