On Pace

What this is

On Pace is a working prototype of a delivery ledger for agencies that sell work on a regular cadence. It demonstrates how the system could be structured and used in practice. There are no real users, and the three clients shown in the prototype are fictional.

The design was informed by materials shared with me directly by a small production team. I have omitted their specific details, and none of their information appears in the prototype. The system therefore focuses on the broader operational pattern I was trying to understand. All sample data was written from scratch for this build.

See the prototype.

The problem

An agency that promises a client a set number of pieces each month has made a clear obligation. The work required to meet that commitment is often organised through individual task lists, with assignments distributed among team members.

A task records that something was completed. The monthly commitment itself sits outside that record, usually in an email, a contract or someone's memory, so answering “Are we behind on this client?” can require reconstructing the month's progress by hand.

The client has no direct view of that progress. If they want to know where their work stands, they have to ask, and someone has to check and respond. The same question comes up repeatedly, and the answer becomes outdated as soon as more work is completed or delayed.

There is another issue with the internal view. It contains information about every client, internal notes, assignments and delays across the team. That makes it unsuitable for sharing directly with an individual client.

Key decisions

Attribution is derived from the stage, not stored on the deliverable

Every deliverable records the stage it is currently in. Each stage also defines whether the agency or the client is responsible for the next step. That information lives in one place and is looked up when the page renders.

I considered storing the waiting-on value directly against each deliverable. That would make it possible to represent situations such as an editor being blocked while waiting for a missing client asset. I chose the stricter model because it keeps the data internally consistent: a deliverable in the editing stage cannot simultaneously be marked as waiting on the client. The trade-off is that the prototype cannot represent every kind of blocked work.

The same records produce two vocabularies

The internal view uses six working stages: briefed, awaiting materials, scripting, editing, internal review, and with client. The client window presents those same records through three simpler statuses: in production, waiting for your materials, and ready for your review.

A client doesn't need to know whether a piece is being scripted or edited, and some of the internal labels would sound unnecessarily pointed when shown to the person they describe. Both labels belong to the same stage record, so a stage cannot exist with one wording and not the other, and the mapping between them is visible in a single file rather than reconstructed by reading two views side by side.

Being behind is measured against the month elapsed, not the month ended

A client promised fourteen pieces who has approved four is on schedule on the third of the month and badly behind on the thirtieth. The same two numbers mean opposite things depending on the date. The prototype compares approved work with the proportion of the month that has passed, and reports a client as behind once the gap reaches a whole piece.

I use a whole-piece threshold because a shortfall of a third of a video does not tell me much about delivery progress. A rule that flags every fractional shortfall would produce constant warnings. The calculation also assumes that delivery is distributed reasonably evenly across the month. An agency that shoots everything in one week and publishes it over the following four weeks would need a different pacing model.

The same records, both ways

Table Nine has six deliverables this month. Two are approved, two are with the client for review, and two are waiting for materials the client has not sent. Those six records provide the data for both views below.

In the internal view, the six pieces appear as a pace figure, a waiting-on split, and a list of work that has been open for more than seven days. The table-setting piece has been with the client for sixteen days, and the ledger attributes it to the client, which is correct. Sixteen days also means nobody at the agency chased it. The ledger records where a piece is sitting. Whether someone should have moved it is a judgement it has no way to make.

The client window presents the same six records with a smaller set of information. It leaves out the day counts, the pace figure, and information about the other two clients on the ledger. Two pieces are marked ready for review, and each has an approve and a request-changes control.

Approving the table-setting piece changes its status in place and removes the controls, and the counts above it move from two approved to three. Nothing is saved, so reloading the page restores the original state.

What I would need to find out

The tutoring page taught me things by being live. This one has no users, so there is nothing to report. What follows is what I would ask an agency before building any of it properly.

Where does client-deliverable status live today? If the answer is a spreadsheet somebody maintains by hand, the problem is real. If the answer is that their workspace tool already does it, On Pace has nothing to add.

How does a client currently learn status and approve a piece of work? The approve control only earns its place if approval currently happens somewhere that loses it, such as a voice note or a reply in a group chat.

How many active clients are there, and what volume was promised to each? Three clients at ten pieces a month is a different tool from twelve clients at two. The pace calculation assumes a monthly promise exists as a number. If nobody can state it, the whole model rests on nothing.

What does the person accountable for delivery check first each morning? If the honest answer is their messages rather than any system, then an internal view that has to be visited will not be visited.

What was the last thing that slipped, and how was it discovered? This is the question I would weight most heavily. If slippage is always found by a client complaining, the ledger has an obvious job. If it is found by someone noticing in time, the job is smaller than I have assumed.

What this doesn't have

There is no database or account system. The prototype reads from a single file and builds to static pages, so the approve control only changes the state shown on screen. Reloading the page restores the original state.

Stage ageing is currently stored as a number of elapsed days. In a working version, each deliverable would have a stage-entry date and the elapsed time would be calculated from the current date. Keeping the number directly in the page source makes the figures easy to inspect and keeps the entire prototype consistent around one stated snapshot date.

There is currently no connection to a workspace tool. The intended setup keeps Notion, Asana, or another workspace as the system of record, with On Pace interpreting the information from there. For this prototype, that information comes from a file I wrote by hand. A working version would read the stages through the relevant tool's API. The exact shape of that integration remains the biggest unanswered question in the design.

Task management, time tracking, analytics, invoicing, chat, and notifications are outside the scope of this prototype. I considered each one and kept the focus on the central question: what was promised to a client, and where does that work currently stand? Adding any of them would pull the ledger towards being a second workspace tool, which is the one thing it is meant not to be.

The three sample clients were created around the three states I wanted to demonstrate: on pace, behind because of the agency, and behind because of the client. Data chosen to demonstrate a model will always flatter it.

See it

Open the On Pace prototype. It works on a phone, and the client window appears in the second half of the page.