A stage that means a feeling cannot be counted. One screen every Monday: twelve counts with totals, the conversion between each pair, and the stage that leaked.
A number in a notebook on Monday. The pipeline is read as a feeling: busy, quiet, promising. Nobody can say which stage lost the week. At a twenty-five-person software company the founder knows the total and none of the parts.
By hand today
“a single ‘expected next 7 days’ number written down every Monday + a Friday review of what actually happened vs prediction”
ouuki, on Indie Hackers, read 7 September 2026
That is the best version of doing it by hand. One number predicted, one number checked. What it cannot tell you is where the gap came from. The Friday number was low. Was it fewer emails found, fewer replies, or fewer calls taken?
Most companies do not have the notebook. They have a CRM whose stages have become descriptions of mood. “Qualified” means someone felt good about it. “In conversation” means a reply once arrived. A stage that means a feeling cannot be counted, and what cannot be counted cannot be seen leaking.
What it costs you each week
$96,000, the top of the salary band in one advert for a revenue operations hire whose named deliverable is the dashboard. Below that, the dashboard is a spreadsheet the founder updates when things feel wrong.
Source: a job advert for a Revenue Operations role, Intellibright, on Workable, read 7 September 2026
Larger companies hire the number. Reading a pipeline honestly, week after week, is a job that produces a screen the rest of the company reads. Smaller companies get a spreadsheet that is trusted less each month.
Count one thing in your own week: how many of your stages you can put a number on right now, with the total beside it, from one page. For most founders the honest answer is the first stage and the last, and nothing between.
The build
Codex: one screen, every Monday. Twelve counts, each with its total. The conversion between every neighbouring pair. And the one stage that leaked most this week. Nothing on it is typed. All of it is derived from the events the other chapters wrote.
The screen has three parts and no fourth. The counts: what sits in each of the twelve stages now, what entered last week, what left this week. The conversions: for each neighbouring pair, this week’s exits divided by last week’s entries. And the leak: the one stage whose conversion fell most against the week before.
The rule under all of it is that a count is never shown without its total. ArkOne learned this on its own console, where an accounts page once showed 500 companies of 3,405 with no total, and a company that existed read as one that did not.
Open Codex in the folder that holds your CRM access and the logs from the earlier chapters, the last of them the call brief. Type:
Read the CRM. For each of the twelve stages, count what is in it now, what
entered it last week and what left it this week. Show every count with its
total. For each pair of neighbouring stages, divide this week's exits by
last week's entries and call it the conversion. Compare each conversion
with the week before. Name the one stage whose conversion fell most; that
is the leak. Mark any stage with too few rows for an honest rate. List
leads that have sat in a stage with no next step. Write all of it to one
screen, weekly.md, and never a second page. Run every Monday morning.
What comes back is one page. Twelve rows, each with now, entered and left. A column of conversions between the rows. One line at the bottom naming the stage that leaked most, with this week’s rate beside last week’s. Then two short lists: stages too thin to rate, and leads sitting in a stage with no next step.
The page is saved as weekly.md, and each week’s copy is kept in weekly/ under its date. Nothing on the page is typed. If a number looks wrong, the fix is upstream, in the chapter that should have logged the event.
The open-source dashboards found count what sits in each stage today; none can name a leak. The pattern is ArkOne’s own. src/lib/pagination.js lines 4 to 7 state the rule: a read either hands back a page and says how many there are in total, or a bounded set and says so; lines 21 to 22 say why, a total beside the rows is what makes a truncation visible. docs/crm-module.md line 18 has crm_pipeline counting companies per stage, and line 370 has station tabs whose counts are derived on read. The reader builds their own version. There is no demo to download.
What it feeds
Next week: the list, from the top. The leak names the chapter to reopen. The fix goes into that stage and the engine runs again from stage one. Proof: the one stage whose rate fell, with every count beside its total.
This is the last chapter, and what it feeds is the first. If the leak is at stage five, emails found, next week begins by reopening chapter five. If it is at stage eight, the sorter gets a new label. The list for next week is written by the leak, not by instinct.
Three things prove this stage worked. Per-stage conversion this week against last, on one page. The one stage whose rate fell, named. And every count shown with its total.
What stays with a person
The Monday number, and the change. The tool shows the leak. A person writes down the number they expect, and decides what to change.
The habit quoted at the top survives the build. Someone still writes the expected number on Monday, by hand, because predicting is what makes the Friday reading mean anything. The tool can only count.
Deciding what to change is the other half. The screen says stage nine leaked; it does not say whether the gap between follow-ups is too long or the last message too soft. A person reads the objections file and decides. One change a week, written down, so that next Monday can say whether it worked.
The tools you already pay for
Nothing new to buy.
CRM: the stages and the events; every count is derived from it on read.
A text file: weekly.md, one page, kept by date.
A calendar: one Monday slot to read it and write the number down.
The objections file: from chapter eight, opened when the leak is a message.
No dashboard product and no revenue operations hire.
One screen, twelve counts, one leak. Then the list for next week writes itself.
Ask: Which of your twelve stages leaked most last week, and how do you know?
This is chapter twelve of twelve, after handing a warm reply to a call; the engine then runs again from writing down the market. The book, Building a real outbound engine with Claude Code and Codex, end to end, runs the whole engine in order, from writing down the market to reading the weekly number, one chapter per stage. A free starter edition for firms under fifty people is coming through the 100k programme.