Throughline is the decision system inside a complex, multi-segment operator: several retail and service lines running alongside a recurring-revenue membership base, each with its own economics, systems and people. Nobody there lacked data. The point of sale held years of transaction history, the CRM held every inquiry, and the books closed monthly. Each system was right about a different thing, and nothing said which one to believe for which question. With Claude as the build partner, those systems became one decision environment: a warehouse underneath, a page for every recurring decision, and a rule that software proposes and a person commits. The hard part was never the data. It was deciding what each person needed to decide, and what the software was never allowed to decide for them.
Company figures are deliberately absent from this page. The method is the point, and it does not need them.
The question arrived as whether to spend more on advertising, and the data answered a different one. A small test showed inquiries were cheap at current volume. What limited results was the capacity to follow up on them. More inquiries without that capacity would buy roughly the same number of sales and a crowd of people who asked and heard nothing, in a small market where you get to do that to a household once. The budget is gated on follow-up capacity, then ramped and read after two weeks.
Counts that move nightly belong on a page that refreshes itself. Documents hold method, definitions and decisions. Every page states when its data was pulled and from which system, so a reader can tell a snapshot from a live count without asking.
Open deals rarely carried a dated next step. One script could have filled every one of them and turned the metric green without changing a single conversation. The pipeline page proposes an exact dated step for each deal, and a person copies it in. The same rule governs the books: nothing is written to the ledger by software, and the bookkeeper posts every entry.
A cost field in the point-of-sale export turned out to hold the line total rather than the unit cost, so every multi-unit line counted quantity twice. The evidence held on nearly every multi-unit line tested, and the fix is one line of code. It stays held until the people who run the system confirm how the field is filled. A correct fix applied on inference teaches people that the numbers change without them.
Why this sits on a finance executive's site. Start from the decision, not the data. Gate spend on the capacity to use it. Keep the analyst who proposes separate from the person who commits, whether the analyst is a person or a model. Those are the rules I have used to build forecasting, close and portfolio reporting at scale. A small business shows them at a size where every decision is visible at once. The long version is at the bottom of this page.
Every recurring decision in the business gets one page that answers it, refreshed as often as the decision is made, with its source and date on the page. The work started from the decisions people make and worked back to the data each one needed. No single system answers any of them on its own terms.
| Decision | Point of sale | CRM | Ads | Books | Payroll | Answered on |
|---|---|---|---|---|---|---|
| Who needs a call today | New Member Pipeline | |||||
| What an inquiry costs, and which ads to fund | Inquiry Engine | |||||
| Why deals are lost | Inquiry To Member | |||||
| What the member base is worth, and whether it renews | Member Book | |||||
| How busy today will be, and how much discount room there is | Shop Day Card | |||||
| What to buy for next year, and when to commit | Shop Intelligence | |||||
| What cash looks like thirteen weeks out | 13-Week Cash Flow | |||||
| What to do next, in what order, and why | Earn The Right To Spend |
Each decision draws on one to three systems. The page in the right-hand column does the joining, so the person making the decision does not have to.
Four layers, one direction of trust. Each source feeds a single warehouse at its own cadence. The warehouse builds pages that each answer one question. People act on those pages, and anything that commits the business passes through a person.
Each source box says how it connects. Software reads everything to the left of the dashed line and writes only to the warehouse and the pages. Every write to a system of record passes through a person.
Follow-up call · Thu Oct 1Disposition call · Fri Oct 2Sample data. The page proposes the step and the words; a person copies the step into the CRM, and the page never writes it there. The second row shows the rule for older deals: a decision, not an assumption.
The full case study. Open any section.
Two systems both measured membership, and they measured different things. The closed membership revenue in the CRM's entire history was a fraction of what the point of sale books from the membership base in a single year. Neither is wrong: the CRM holds new inquiries and the point of sale holds the installed base. Anyone reading the pipeline as the state of the membership base would have been off by an order of magnitude.
The records measured assignment, not effort. The CRM owner field records who a deal was assigned to, not who worked or closed it. Grading anyone on it would grade them on the wrong thing, so the system does not.
The loss data could not explain the losses. Loss reasons were rarely recorded, so price, product, timing and neglect were indistinguishable. The answer was instrumentation: a required reason on every close from here on.
One activity record in five was filed to a person instead of a deal. A sweep of every record showed re-filing them would change the last-contact date on a handful of deals. The rate was identical for every person and every activity type, a habit rather than a discipline problem. The cleanup was skipped; the order of the team's morning changed instead.
One place had three names. Normalizing to a fixed list showed most deals had never recorded a location at all. That is a data-entry job, and it now has an owner.
Each system recorded cash at a different moment. The point of sale sees cash when it is taken and the books when it is reconciled. The thirteen-week forecast reads inflows where cash is recorded first, and says so on its face.
Three calendars ran at once. A fiscal year that does not follow the calendar, Monday-to-Sunday management weeks, and a calendar tax year. The company's own week map had construction errors in future years. One calendar table now serves every model.
Numbers moved while they were being reviewed. The lost-deal count changed in the hours between a page being built and being reviewed. Re-pulling everything before every meeting is a treadmill. Stamping every page with its pull time is the fix.
Some sources are still manual. The point of sale exports by hand. Until a daily export runs, the shop pages are stamped snapshots and are labelled that way.
In a founder-led business, sales run through the founder's relationships, so any finding about the pipeline can be read as a finding about the person who built it. The argument was sequenced the way a long-tenured operator needs to hear it: what is sound before what is broken.
Gates written as service levels. Three capacity tests gate the ad budget: the full sales team closes a membership start to finish; 95% of new inquiries contacted within 48 hours, two weeks running; 95% of open deals carrying a dated next step, two weeks running. A gate written as perfection gets abandoned the first week somebody is away. Instrumentation gates nothing and started immediately.
| Area | Owner |
|---|---|
| Campaign execution | Marketing, to a written campaign standard, five numbers weekly |
| Pipeline response | Owner: response time, and a dated next step on every deal |
| Assigned deals | Sales team, from the daily queue |
| Shop | Shop manager: discount ceilings, targets, inventory |
| Member records | Membership staff: contract and renewal state |
| The instrument | Me: what gets measured, definitions, warehouse, pages |
Adoption follows sequence, not instruction. The team had been asked for months to log from the deal record and to create a deal before calling anyone. Both failed because people worked from the phone, the inbox and the contact list. The fix was a third instruction: start the morning on the pipeline page. It is a deal queue with a dated instruction on every row, so the first two habits come with it.
A new page has to answer a question no other page answers. If a page is slightly wrong, it is fixed, not replaced. When two sources disagree, precedence runs from the live CRM or ad API, to the page built from it, to the operating canon, to any other document, to memory. Anything lower that disagrees is stale and gets corrected, not argued with.
| Page | The question it answers | Refresh |
|---|---|---|
| Start Here | What is all this, and where do I go? | When a page changes |
| Earn The Right To Spend | What do we do, in what order, and why? | When a gate moves |
| New Member Pipeline | Who needs a call today, and what do I say? | Nightly, automatic |
| Inquiry Engine | What does an inquiry cost, by ad and audience? | Weekly |
| Inquiry To Member | Where do inquiries go, and why do we lose them? | When losses move |
| Member Book | What is the installed base worth, and is it renewing? | Monthly |
| Shop Intelligence | How is each retail and service line doing against plan, price and volume? | Per export |
| Shop Day Card | How busy is today, and how much discount room is there? | Daily, once export runs |
| 13-Week Cash Flow | What does cash look like thirteen weeks out? | Weekly |
| The Board | What is built, what is next, and what does each person owe? | Each working session |
Facts, procedures and dashboards live in different kinds of documents. When facts were written into procedures, the facts moved and the procedures kept the old numbers.
On one evening the pipeline figures changed materially within seven hours. The pages were corrected that night and two documents were not, so for a day the project held retired numbers. The structure below exists because of that day.
One document that routes every question: settled facts not to be relitigated, open questions each with a named owner and a closing condition, the precedence rule, the page index and the cadence.
Every claim logged and typed as observation, assumption, risk, opportunity, decision or data quality, with source, confidence, dollar impact, owner and a required next-review date. Entries are superseded, never deleted.
Before the month's actuals are pulled, a prediction is written down; after, it is scored confirmed or refuted. A note cannot be wrong. A prediction can, and that is what turns a review into a test.
The point of sale's codes, crosswalks, caveats and merge procedure in plain language, so the knowledge does not depend on me.
Every missing input with the placeholder used meanwhile, who owes it, and what changes when it lands. Pages built on placeholders show the code on the page.
Everything built and to build, scored on effort, value and severity, with the inputs each person owes. Updated at the end of every session that ships or files something.
The nightly refresh, the Monday funnel review, the cash refresh and the pre-flight alignment audit are written as instructions Claude runs the same way every time. A procedure that lives in someone's head is done differently each time.
| Layer | Component | How it connects |
|---|---|---|
| Point of sale | Retail point-of-sale system | Manual export Loaded on receipt and diffed against the warehouse. Pages built on it carry the export date. |
| CRM | HubSpot | Live Read nightly through a connector. The page never writes back. |
| Ad account | Meta Marketing API | Live Read-only system user, pulled from my own machine. The token never leaves it. |
| Books | QuickBooks | Live Read-only connector. Nothing is written to the books; the bookkeeper posts every entry. |
| Payroll | Paychex | Browser pull Read through my own signed-in session, no stored credentials. Feeds pay dates into the cash forecast. |
| Warehouse | DuckDB | Single-file warehouse and the arbiter for anything historical. |
| Published data | Supabase | In build The hosted layer that lets daily pages run without one laptop in the loop. |
| Knowledge | Notion | Company context, the knowledge ledger, the review loop and the data dictionary. |
| Signals | Gmail, Granola | Email logged to the deal record, plus meeting notes. |
| Intelligence | Claude | Builds the pages, drafts, classifies and audits. The arithmetic behind every number is ordinary SQL anyone can rerun. |
The first build produced too many pages: six working pages about one funnel, a control room built to settle one day's disagreements, a setup guide and a separate ad review. Each was correct when built. Together they let the same number appear in three places and drift.
Asking why there were six made the real finding plain. Each page answered for a slice of the funnel someone owned, and the end-to-end number had no single owner. Four pages were retired at once, kept but not refreshed or shared. A cover page now routes readers, the question test governs every new page, and the ownership question sits at the top of the open list. It needs a name. It does not need a hire.
If a decision in your company is being made badly, tell me which one and what it costs. msandfordboone@gmail.com