Why we start every engagement with a five-day sprint

Most operations leaders we talk to have already bought automation once. A CRM rollout, an ERP project, an "all-in-one" suite that promised everything would connect. Some of it worked. A lot of it became another tool the team works around.

So when a new vendor arrives with a proposal, the buyer isn't neutral. They're carrying the memory of the last one. And the traditional way of selling this work makes that worse, not better.

The proposal problem

A typical engagement opens with weeks of discovery, a long document, a big number, and a timeline measured in quarters. The buyer has to commit before they've seen anything work. Every risk sits on their side of the table.

That model made sense when building software was slow and expensive. It makes much less sense now, when a single well-scoped workflow can be automated in days. The honest thing to do is let the work prove itself before asking for the big commitment.

A burned buyer doesn't need a better proposal. They need something working, on their own data, this week.

What the five days actually contain

The sprint is deliberately small. One workflow, chosen together on a 30-minute call, where the cost of doing it by hand is obvious. Quote replies, order intake from emails and PDFs, status updates, invoice matching. Then:

• Day 1: we map how the workflow really runs today and record a baseline: how long it takes, how often, how many errors.
• Days 2 to 4: we build the automation on the tools you already use, with a person approving anything that touches money or customers.
• Day 5: it runs on your real data. You get a handover document and a short note on what it's worth, measured against the day 1 baseline.

The scope and cost are agreed before we start, and the sprint is credited in full to whatever you decide to do next. If it isn't working on day 5, we keep going at no extra cost until it is.

Why this is better for us, too

It isn't charity. A sprint is the fastest way for us to learn how your business actually works: the real objects, the real exceptions, the workarounds nobody wrote down. That knowledge is what makes a larger build accurate instead of optimistic.

It also filters. Some companies discover after five days that their real problem isn't automation at all. It's a process that needs fixing first, or data that doesn't exist yet. Finding that out in five days is a good outcome, and we'll tell you plainly if that's where you are.

What happens after

Most clients go one of three ways. Some take the working automation and run with it. Some move to a two-week Leak Diagnostic to price every leak in the business and plan the order to fix them. And some go straight to a build, because the sprint already answered the question they cared about: can these people actually ship?

All three are fine. The point of the sprint is that the decision is made on evidence, not on a proposal.

How to pick your first workflow

Look for work that is frequent, repetitive and currently done by retyping something from one place into another. If a senior person does it because nobody else knows how, it's an even better candidate: you'll get their time back as well as the hours.