Sprint 2 · Days 31–60 — One Pilot, Not a Platform

Once phase one produces a named workflow, an owner, and a number to hit, the temptation shifts immediately. Buy-in exists now, so the instinct is to move fast and roll the tool out across several teams at once. That’s the second most reliable way an SMB wastes a quarter. A platform-wide rollout in month two has no evidence behind it yet — it’s enthusiasm standing in for data. Phase two stays deliberately narrow: one workflow, one pilot, run properly.

The workflow chosen in phase one should already be the boring one — a recurring, friction-heavy task rather than a headline use case. Resist any pressure to swap it for something more visible once there’s budget attached to it. A pilot that succeeds quietly against a real cost centre is worth more at this stage than one that looks good in a company update but doesn’t touch anything load-bearing.

The owner named in phase one needs two things they rarely get automatically: protected time, and a short feedback loop. A monthly check-in is too slow for a thirty-day pilot — weekly is closer to right. The point of these check-ins isn’t status reporting. It’s catching early friction before the owner quietly stops using the tool and nobody notices until the pilot is already dead.

Somewhere around week six, most pilots show some version of resistance, and it rarely looks like open pushback. It looks like the tool getting used a little less each week, or getting used only for the parts of the task nobody minded doing manually anyway. That’s not sabotage. It’s usually a signal that the tool doesn’t yet fit how the work actually gets done, or that the person doing it doesn’t trust the output yet. Treating that as a discipline problem is the wrong read. Treating it as data about where the workflow needs adjusting is the useful one.

“Efficiency gains” doesn’t survive a budget conversation. Hours do. By day 60 the pilot should produce a concrete number — hours saved or reallocated on the specific task named in phase one, ideally measured against a baseline captured before the pilot started. If that baseline wasn’t captured, capture it now, retroactively and roughly if that’s all that’s possible. A number a CFO can push back on is still more useful than no number at all.

For the fuller four-step version of this calculation — conservative, expected, and optimistic scenarios, ROI, and payback — see Measure Value, Risk, Costs & KPIs.

If the open-source-versus-vendor question got raised in phase one, this is where it starts to matter in practice rather than in theory. A pilot built quickly on a proprietary stack because it was the fastest way to get moving can become expensive to leave once it’s working — the data, the integrations, and the habits are all tied to it by now. Worth checking, before phase three scales anything, what it would actually cost in money and effort to move this pilot off its current stack. An uncomfortable answer is worth having now, before phase three multiplies the exposure.

By day 60, four things should be true:

• The pilot has run on one workflow, with one owner, for the full thirty days.
• Usage data exists — not just a general sense that it’s going well.
• A real hours-saved or hours-reallocated figure exists, even approximate.
• The friction points are written down, not just remembered.

With that in hand, phase three is a decision, not a guess.