THE QUESTION

The Question Behind the Fix

In the fortnight since “DSO: The Quiet Killer” published, a pattern showed up in the replies that didn’t show up in the plan. Several readers ran the 90-day sequence more or less as written — automated chasing switched on, a benchmark band checked, a lever picked. The number moved. Then, a few weeks later, it moved back.

That’s not a story about a bad plan. The 90-day sequence in that piece is sound, and for the businesses that report the fix held, it’s holding for a specific reason we’ll get to. But the drift-back pattern raises a sharper question than “did the plan work”, which is the question this piece actually investigates: why does a FinTech capability that demonstrably works in month one fail to hold by month four?

The easy misreading is that this is a discipline problem — the founder got busy, the follow-up lapsed, attention moved to the next fire. There’s a grain of truth in that, but it’s the wrong diagnosis, because it implies the fix is a matter of willpower, and willpower isn’t a durable operating strategy for anyone running a business with more inputs than hours. The real answer is structural, and it’s this: a capability and an operating rhythm are two different things, and almost everything written about FinTech tools — including, honestly, most of what runs on this site — is written to build the first one, not the second.

A capability is a single deployable skill. It’s the ability to calculate DSO correctly. It’s a tracker that flags aged receivables. It’s knowing which of three levers — automated follow-up, embedded payments, selective invoice finance — fits which cause of drift. Capability answers the question “can I do this”. It’s necessary. It is not, on its own, sufficient, and the reason is structural rather than personal: a capability that isn’t wired into a rhythm has to be remembered into existence every single time it’s needed — and remembering things is exactly the kind of task that a business run by a founder with limited attention will eventually fail to do, not because the founder is undisciplined, but because attention is a scarce resource and the capability was never given a claim on it beyond the week it was built.

An operating rhythm is different. It’s the reason a capability keeps running after the founder’s attention has moved on to something else. It doesn’t ask “can you do this” — it asks “does this happen reliably, on a fixed cadence, without you having to remember to do it”. A DSO tracker that only gets checked when cash feels tight is a capability. A DSO tracker that gets checked every Monday at 9am as a fixed line item, whether or not anything feels tight that week, is part of an operating rhythm. Same tool. Same tracker. Completely different survival rate.

This piece maps the gap between those two states — why it opens up even for operators who did the capability-building work properly, what closes it, and what it costs to leave it open. It uses three of the FinTech capabilities most SMB operators already have some version of — cash forecasting, receivables discipline, and Open Banking-fed visibility — as the worked terrain, because the dependency chain between them is a clean illustration of a pattern that holds well beyond cash operations. And it returns, at the end, to the business from the DSO piece, three months on, to show what changed the second time the fix went in.

The question this piece answers, stated plainly: what has to be true, structurally, for a FinTech capability to become permanent rather than seasonal? The short answer is that it has to stop being a thing the founder does and start being a thing the business runs. The rest of this piece is about how that happens.

THE LANDSCAPE

Where the Rhythm Breaks

Most SMB operators past their first eighteen months of trading are not capability-poor. That’s worth stating plainly because most FinTech marketing — again, including plenty published on this site — implies the opposite: that the gap holding a business back is a missing tool. It rarely is. By year three or four, a typical operator has accumulated a reasonable capability inventory without anyone calling it that: a forecasting spreadsheet or template, some version of a chasing process for overdue invoices, a bank feed or Open Banking connection into the accounting platform, maybe a lending relationship opened at some point for a specific need. None of these are nothing. Individually, each one represents real capability-building work.

What’s missing isn’t the capabilities. It’s the connections between them, and the connections fail in three specific, recognisable places.

A useful way to see this before getting into why it happens is to sort a typical capability inventory into three buckets. One-off and manual: a cash forecast rebuilt from scratch each month in a spreadsheet nobody else in the business can open. Automated but isolated: an Open Banking feed that updates a dashboard nobody has a fixed time to look at, so it sits there being accurate and unused. And connected: a receivables view that automatically surfaces into the same weekly slot as the forecast, with a rule already agreed for what happens next. Most SMB finance functions have capabilities scattered across all three buckets at once — a forecast in the first, a bank feed in the second, and, often, nothing yet in the third. The businesses that get real value from FinTech tooling are rarely the ones with the most tools. They’re the ones with the fewest capabilities left sitting in the first two buckets.

The first is sequencing. Capabilities have dependencies, and the dependencies aren’t optional or a matter of preference — they’re mechanical. A weekly cash forecast rhythm is close to impossible to run meaningfully without a live data feed, because a forecast built on month-old accounting exports is always describing a business that no longer exists. Real-time visibility, in turn, is close to impossible without an Open Banking or bank-feed connection doing the pulling automatically, because manually reconciling a bank statement every week is a task most operators correctly deprioritise the first time a real fire needs attention. And a receivables discipline — the DSO piece’s territory — is close to impossible to run with any precision without the cash forecast already running, because DSO only becomes an actionable decision once you can see what a released pound of working capital would actually be used for. Skip a step, and the capability built on top of it sits there working technically but pulling nothing, because there’s no rhythm reaching down to activate it.

This is the actual reason “just get an Open Banking feed” and “just automate your chasing” so often produce a burst of initial improvement and then nothing. The tool arrived in the right order for what it does on paper, but not in the order the operator’s actual rhythm needed it, so it became one more capability sitting next to the others rather than one more capability the rhythm could reach.

The second break point is what this catalogue’s own production architecture calls the connective material — and the name is useful outside a curriculum context too. When Vogue Boost built the Founder GM Path, the actual content split turned out to be roughly seventy per cent individual capability material and thirty per cent connective material: the intro that frames how capabilities relate to the role, the transitions between one capability and the next, the exercises that force a capability to be applied rather than just understood. That thirty per cent isn’t padding. It’s the material that makes the other seventy per cent compound instead of sitting in parallel, and it’s structurally the same as what’s missing operationally in most SMB finance functions.

Operationally, connective material looks like three specific things, and all three are cheap to build and almost always skipped: a fixed weekly review slot (not “whenever there’s time” — an actual slot, a fixed day and time that survives a busy week); explicit handoffs (a rule that says the output of one capability becomes the input to the next — the forecast’s aged-receivables view feeds directly into the DSO lever decision, rather than the two living in separate spreadsheets that happen to both exist); and escalation rules (a pre-agreed threshold that triggers action automatically — “if DSO drifts more than five days past the sector benchmark band, the automated follow-up cadence tightens” — rather than waiting for the founder to notice on a day they happen to be looking).

None of these three things require a new FinTech tool. That’s precisely why they’re skipped: building them doesn’t feel like doing something, in the way that switching on a new automated chasing tool feels like doing something. But they’re the difference between a set of capabilities and a rhythm, and skipping them is the single most common reason a DSO fix — or a cash forecast, or any other capability — improves for six weeks and then quietly reverts.

The third break point is diagnostic. It’s rare for an SMB operator to have ever been asked the right question about their financial operations, because the question that gets asked — by accountants, by advisors, by most FinTech content — is a capability question: can you calculate DSO, can you run a forecast, do you know what Open Banking does. Those are useful questions and this catalogue asks plenty of them. But a capability diagnostic can only ever produce a capability answer, and a business can score well on every capability question on the list while still not having a functioning operating rhythm, because “can you do X” and “does X happen reliably without you remembering to do it” are different questions with different answers.

A role diagnostic asks the second kind of question, and it’s a short list: does this happen on a fixed cadence, or only when something prompts it. Is there an explicit handoff into and out of it, or does it exist in isolation. Is there an escalation rule that would catch drift automatically, or does drift only get caught by someone noticing. And — the question that surfaces the sequencing problem — is this capability blocked by one that doesn’t exist yet, meaning it’s technically “in place” but structurally unable to run.

Run that diagnostic against a typical SMB’s financial capability inventory and the pattern is usually the same: capabilities score reasonably well individually, cadence and handoffs score badly, and at least one capability turns out to be blocked by a dependency nobody had named. That gap — reasonable capability, absent rhythm — is where the fix that worked in month one quietly stops working by month four, and it’s the gap the rest of this piece is about closing.

THE MECHANISM

The Architecture of a Rhythm That Holds

Closing the gap mapped above isn’t about acquiring a new capability — the businesses in the pattern above mostly already have the capabilities that matter. It’s about building three specific layers on top of what’s already there: a dependency-ordered sequence, the connective material that links each layer to the next, and a diagnostic that tells you honestly whether the rhythm, not just the capability, is actually running. Each layer is worth taking in turn, because each one has a distinct failure mode and a distinct fix.

Layer one: sequencing by dependency

The starting move is mapping the actual dependency chain for the capabilities in question, rather than the order they happened to get built in — which is usually the order a salesperson called, an accountant recommended, or a specific fire forced. For cash operations specifically, the chain most SMB operators are working with runs roughly like this: an Open Banking or bank-feed connection (tools like TrueLayer or Yapily sit behind many accounting-platform integrations here, though increasingly this is built directly into Xero or QuickBooks) creates live visibility into the actual cash position. That live visibility is what makes a rolling cash forecast meaningful rather than a monthly guess — a 13-week rolling structure, re-baselined weekly, only works if the inputs are current. A working forecast is what makes a receivables discipline actionable, because DSO only becomes a decision — which lever, how urgently — once you can see what the released capital would fund. And visibility plus a working forecast plus a receivables discipline together are what put a business in a position to negotiate supplier terms or a lending facility from a position of leverage, rather than urgency, because the operator walking into that conversation can show a lender or a supplier exactly what the cash position looks like twelve weeks out instead of asking them to take it on trust.

Miss a link and the capabilities above it don’t fail loudly — they just sit unused. This is the single most common reason a DSO fix undershoots what the diagnostic promised: the automated chasing switches on and the benchmark gets checked, but there’s no live forecast underneath it to make the resulting decision — which lever, how much urgency — anything other than a guess. The tool works. The rhythm has nothing to plug it into.

The practical move here isn’t “build everything in the right order from scratch” — most operators are past that point, with capabilities already built out of sequence. It’s diagnostic: map what you actually have against the chain, find the first missing or non-functioning link, and treat that link as the priority over anything built downstream of it. A DSO lever chosen without a working forecast underneath it is a guess dressed as a decision, however good the lever inventory is.

Layer two: the connective material

Once the sequence is right, or at least understood, the second layer is building the thirty per cent that makes the capabilities compound rather than coexist. Three components, each cheap and each usually skipped.

The weekly review slot has to be fixed, not contingent. “I’ll check the forecast when things feel uncertain” is not a rhythm — it’s a capability that only activates under stress, which means it activates too late and inconsistently. A fixed slot — the same day, the same rough time, calendared like a client meeting — is what survives a busy week, because a meeting with yourself is the first thing that gets skipped unless it’s treated with the same protection as a meeting with someone else. Fifteen to thirty minutes is enough for most SMB operators at this stage; the point isn’t duration, it’s reliability.

The explicit handoff is the mechanical link between one capability’s output and the next one’s input. In cash-and-receivables terms: the forecast’s aged-receivables view should feed directly into the DSO lever-decision dashboard, ideally as a shared sheet or a simple automated flag, rather than the two existing as separate documents that happen to both technically exist. Without the handoff, the operator has to remember to manually carry information from one tool to the next, and — per the argument in Section 1 — remembering things under attention pressure is exactly the failure mode this whole piece is about avoiding. The handoff removes the memory requirement.

The escalation rule is the piece most operators skip entirely, and it’s the one that matters most for the fix holding without ongoing founder attention. It’s a pre-agreed threshold, set while thinking clearly, that triggers a specific action automatically rather than waiting for a bad number to be noticed. “If DSO for the mid-size client segment drifts more than five days past this sector’s benchmark band, tighten the automated follow-up cadence and flag for a manual call” is an escalation rule. It converts a rhythm from something that depends on the founder noticing drift into something that catches drift on its own — which is precisely the property that was missing when the DSO fix in the opening section reverted after six weeks: nobody had set a threshold, so nobody, and nothing, caught the drift until it had already cost weeks.

Layer three: the role diagnostic, run honestly

The third layer is a genuine self-assessment against the four questions introduced in Section 2 — cadence, handoff, escalation, and dependency-blocking — applied without the instinct to answer generously. Most operators, asked “do you review your cash position regularly”, will say yes, because they do check it, sometimes. The honest version of the question is narrower: is there a fixed slot this happens in, every week, regardless of how the week is going. Run that version and the answer changes for a meaningful share of otherwise well-run businesses.

The value of running this diagnostic isn’t the score. It’s that it converts a vague sense of “we should be better at this” into three specific, buildable gaps — a missing cadence, a missing handoff, a missing escalation rule — each of which takes a fraction of the effort that building a new capability from scratch would take, because the capabilities are usually already there. The work is connective, not acquisitive, and that’s good news for anyone who has already spent the last eighteen months acquiring the underlying tools: the remaining work is cheaper than the work already done, if it’s approached as rhythm-building rather than as one more tool search.

THE PLAN

A 30-60-90 Sequence for Building the Rhythm

Given three layers rather than one lever, the implementation sequence below is deliberately ordered by dependency — the same principle argued for in Layer One, applied to the plan itself, on the view that a plan for building rhythm should model the thing it’s trying to build.

Days 1–30: audit and one fixed slot

The first thirty days involve no new tools. The task is an honest capability inventory against the dependency chain from Layer One — what exists, in what order, and where the chain is actually broken versus just imperfect. Alongside the audit, pick one capability already in place — not the newest or most exciting one, the one closest to the base of the dependency chain, which for most cash-operations businesses will be the forecast or the underlying data feed — and give it a single fixed weekly slot. Nothing else changes in the first thirty days. The point is proving, with the lowest-stakes possible test, that a fixed slot survives a normal busy week before building anything more elaborate on top of it.

Days 31–60: one explicit handoff

With the base slot holding, the next thirty days build exactly one connective handoff — the single highest-value link identified in the audit, which for a business with a working forecast and an underused receivables process will usually be the forecast-to-DSO handoff described in Layer Two. This does not require new software in most cases; a shared view, a flagged column, or a five-minute manual carry-over at the fixed weekly slot is often sufficient at this stage. The discipline is specificity: one handoff, clearly defined, rather than a general intention to “connect things better”.

Days 61–90: the escalation rule and the role diagnostic

The final thirty days do two things. First, write one escalation rule against the capability now running on a rhythm with a handoff feeding it — a specific, numeric threshold that triggers a specific, named action, agreed while thinking clearly rather than in the moment drift is discovered. Second, run the role diagnostic from Layer Three honestly against the full capability inventory, not just the piece just built, and name the next blocking dependency — the one capability further up the chain that, once addressed, would unblock the most further progress. That named gap becomes the input to the next ninety-day cycle, which is the point: this is not a one-off fix, it’s the first lap of a rhythm that keeps identifying its own next bottleneck.

Three things are deliberately absent from this sequence. There’s no step that says “buy a new tool”, because for most operators reading this, the capability layer is already ahead of the rhythm layer, and adding another tool before the rhythm exists to run it is the exact pattern that produced the drift-back problem in the first place. There’s no step that compresses the ninety days, because the fixed-slot discipline in days 1–30 needs to survive at least a few genuinely busy weeks before it can be trusted, and that takes real time, not enthusiasm. And there’s no step that depends on the founder remembering anything past day 90 without a rule doing the remembering — which is, again, the entire argument.

THE WORKED EXAMPLE

The Second Fix: Clarity Marketing Agency, Three Months On

Clarity Marketing Agency, the £1.2m-turnover business at the centre of the DSO piece, is a useful place to close, because it shows both failure modes in the same business, six months apart.

The first fix worked, by the measure it was built to hit: DSO moved from fifty-two days to forty-one over ninety days, releasing roughly thirty-six thousand pounds of working capital that had been sitting in the gap between invoicing and payment. The lever chosen — a mix of automated follow-up and a tightened embedded-payments option for the agency’s larger accounts — was the right one for the cause of drift, which was concentrated in a handful of slow-paying mid-size clients rather than spread evenly. Read against Layer One of this piece, the sequencing was fine: a forecast was already running, so the released capital had somewhere specific to go, and the lever decision wasn’t a guess.

What wasn’t built was the rhythm around it. The DSO check happened when the founder thought to run it, not on a fixed slot. There was no explicit handoff between the forecast and the receivables dashboard — they were reviewed together the week the fix went in, and separately, unevenly, after that. And there was no escalation rule: nothing was watching for drift past a threshold, so when a new client onboarding push pulled attention away for six weeks over the summer, nobody — and nothing — caught the mid-size segment drifting back up by nine days until a routine month-end review noticed the cash position was tighter than the forecast said it should be.

That’s the pattern from Section 1, in the one business this whole piece has followed. The capability had worked. The rhythm hadn’t been built, so the capability had nothing holding it in place once attention moved on.

The second fix, going in now, follows the sequence in Section 4 rather than re-running the original ninety-day lever plan from scratch — because the lever choice was never the problem. The fixed weekly slot goes onto the calendar for Monday morning, ahead of the receivables check rather than instead of it, because the dependency runs forecast-to-receivables and not the other way round. The handoff is built as a flagged column in the existing tracker: any account ageing past the sector benchmark band is surfaced automatically into the forecast review rather than requiring a separate check. And the escalation rule is specific — drift of more than five days in the mid-size segment average triggers an automatic tightening of the follow-up cadence, with no requirement that anyone notice first.

Nothing about the underlying tools changed. The lever inventory — automated follow-up, embedded payments, selective invoice finance — is exactly what it was in July. What changed is that the capability now sits inside a rhythm that runs whether or not it’s a quiet month, which is the actual test any FinTech fix eventually faces, because every business eventually has a quiet month, or a loud one, that pulls attention somewhere else.

That’s the distinction this piece has been arguing for the length of a proper investigation rather than a diagnostic checklist: a capability answers “can this business do this”. A rhythm answers “does this keep happening, including in the month nobody’s watching”. Most of what gets built and sold under the FinTech label — plenty of it in this catalogue — is built to answer the first question well, because the first question is the one that’s visible in a demo. The second question is the one that decides whether the fix from month one is still standing in month four, and it’s answered by cadence, handoffs, and escalation rules rather than by any tool on its own.

The 2028 baseline this catalogue keeps returning to isn’t really a capability threshold, even though most of the run-up to it will look like one — more SMBs able to calculate DSO correctly, read an Open Banking feed, run a rolling forecast. Underneath that, the actual shift is a rhythm threshold: financial operations that run on a cadence rather than on a founder’s memory becoming the baseline expectation, not the exception. For any operator wanting the fuller, role-level version of the framework in this piece — sequencing, connective material, and the role diagnostic applied across an entire operating role rather than one capability at a time — that’s the specific gap the Founder GM Path, in production now, is built to close.

Read also

DSO: The Quiet Killer — the companion piece this episode extends. Founder GM Path — the role-level programme this framework feeds into, in production now.