Week one: finding where time leaks
In the first week we don't write a line of code. We sit down with you and the people who do the daily work, and we map how the work actually flows. Not how it's supposed to flow per the manual — how it really flows on a Monday morning when twenty emails and three phone calls land at once.
We look for the places where time leaks: a figure someone retypes from one window into another, an email written nearly the same way every day, a report stitched together for half an hour every Friday out of three files. These spots are surprisingly visible once you start watching for them — they just go unnoticed in the rush of the day. The output of the week isn't a document for a drawer; it's a simple map: here, here and here is where the most time goes on things a human doesn't have to do.
What you do and what we do
The collaboration only works when it's clear who owns what. You are the experts on your company — you know why it's done this way, where the exceptions are, and what happens when something breaks. We are the experts on how to hand a given step to a machine without those exceptions getting lost.
In practice that means we need the time of two or three of your people, mostly at the start: to show us how the task is done and to answer questions like "what if the invoice has no reference number?" In return we carry all the technical work — design, development, connecting the systems, testing. Bad collaboration looks like a supplier vanishing for a month and coming back with something that doesn't fit. We show progress as we go and ask before we build the wrong thing.
Week two: picking one quick win
From the map of leaking time we pick one thing — not the biggest, but the one with the best ratio of benefit to effort. We look for a step that happens often, has clear rules, and eats too much time today. That's the "quick win."
We deliberately avoid reaching for the most ambitious problem. A large, tangled process with lots of exceptions is exactly what makes projects stall for months and never show a result. A small, clear task can be solved in a few weeks, measured, and used to build trust. Once the first thing works and you see the saved time with your own eyes, the next step is decided in a completely different way — from "this works, let's go on," not from "let's hope it pans out."
Weeks three and four: we build it and switch it on
In the third and fourth week we build the chosen win. Not to perfection — to the point where it reliably handles the ordinary cases and, for the unusual ones, would rather flag a human than quietly make a mistake. This is an important rule: an automation that can say "I don't understand this one, take a look" is far more valuable than one that confidently botches every exception.
We roll it out gradually. First it runs alongside your existing process, so you can see it does the same thing, only faster. Only once you trust it do we switch it over for real. This cautious start isn't a delay — it's the insurance that spares you an unpleasant surprise in the accounts or in front of a customer.
We measure and iterate — the end of the month isn't the end
At the end of the first month we look at the number we set at the start: how much time was actually saved, how many retypes disappeared, how quickly an answer now reaches the customer. Without this measurement, automation is just a feeling. With it, it's a decision backed by data.
And here the circle turns. The map from week one had more places where time leaks — we've solved one so far. The second month is decided calmly: take the next item from the map, or improve the first one. This is how chaos becomes a system — not in one big leap, but through a series of small, proven steps. Each one stands on the result of the last — which is exactly why you won't get lost or blow the budget on something that turned out not to fit.