Digital transformation: where do you start? a series of small deployments, not a three-year programme

01

What does „a digitally mature company” actually mean?

The phrase wore out because it promises a change of identity and usually describes swapping one tool for another. In a company of 15 to 150 people it translates into five conditions you can check, and none of them needs a three-year programme or an IT department.

The conditions are about where the data sits and who makes the call, not about how many licences you hold. A company with five systems and data scattered across mailboxes is less mature than a company with one CRM and two spreadsheets where everyone knows who fills in what.

• Customer data lives in one system, not in sales reps' inboxes and private spreadsheets
• Company documents sit in one repository, with one version in force and a visible date of change
• The process is written down well enough that a new person can run it without asking the colleague who is on holiday
• Operational decisions are made on a number read out of a system, not on the instinct of whoever has been here longest
• Every tool has an owner named in person, responsible for its configuration and for the team actually using it

02

Which maturity stage is your company on?

You recognise the stage by a symptom in daily work, not by a maturity questionnaire. Below are the five steps we see in workshops, and the first move that makes sense on each one.

Moving to the neighbouring row is cheaper than jumping two steps at once, and it usually fills a whole quarter. A company that wants to go straight from paper to decisions on data buys a warehouse and then fills it in by hand.

A company is rarely on one stage across the board: sales can be two steps ahead of the warehouse. Take the lowest stage in the area you pick for the first quarter, because that is the one setting the pace.

03

Where should the single source of truth sit?

A single source of truth means that for each type of data there is exactly one place where the value is binding, and every other copy is only a copy. It does not mean one system for the whole company, because at this size that system does not exist and nobody will buy it.

Four decisions are enough, and each one can be made in an hour. The hard part is not choosing the system. It is switching off the other places the data has been written to until now.

• Customer and contact history: the CRM (HubSpot, Pipedrive, Salesforce), not a sales rep's inbox
• Documents and procedures: one repository (Google Workspace, Microsoft 365, Notion), with one version in force
• Invoices and settlements: the accounting system, not a spreadsheet with its own numbering
• Numbers for decisions: one place they are read from (BigQuery, GA4, a sheet fed automatically), with a definition for every metric

04

Why do big transformation programmes fail in small companies?

A programme written for a corporation assumes a team that works on it full time. In a company of 40 people the same scope lands on somebody whose calendar is already full, so the project starts late and stops during the first busy week in sales.

The second problem is the horizon. A three-year schedule describes a company nobody has met yet. After a year the market shifts, the person running the project leaves, and what remains is a document nobody opens. Below are the five causes we see most often.

• Cost counted once, at the start: licences, migration and the team's time then run every month, while the budget was one-off
• No owner named in person: „the board is running it” means in practice that nobody is running it
• Change fatigue: three changes at once end with none of them becoming a habit
• A system deployed without changing the process: the tool records the old workarounds, the manual work stays, just in a nicer window
• A goal written as „digitisation”: there is no way to tick it off, so the programme has no end and loses its defenders after a few months

05

In what order should you do it? A two-quarter plan

A programme at this size fits into two quarters and onto one side of A4. Below is the order we use: quarter one sorts out the data and closes one deployment, quarter two adds two more and the measurement.

This is the plan for the programme, not for a single flow. How to break one deployment down into weeks is in our guide on AI in business: getting started.

1. 01

   Quarter 1, month 1: stage and scope

   You name the maturity stage separately for two areas, pick one, and name its owner in person. The month ends with a single page: what we are sorting out, who decides, and which number has to move.

2. 02

   Quarter 1, months 2 and 3: the clean-up and the first deployment

   You set the single source of truth for the chosen area and fix the date the other places of record get switched off. In parallel you take one deployment to production, the smallest one that still makes sense, so the team sees a result inside this quarter.

3. 03

   Quarter 2, months 4 and 5: two more deployments

   You take two processes from the same neighbourhood as the first, because the data is already in order and the work goes faster. Three parallel deployments is too many in a company this size. We take at most two at a time ourselves.

4. 04

   Quarter 2, month 6: measurement and the decision on the next quarter

   You read the numbers 30 and 90 days after each go-live, on the metrics written down in month one. A deployment with no improvement gets narrowed or switched off, instead of being given another quarter.

06

Who owns the tool, and what do you do about resistance?

A tool with no owner stops working in the third month, usually quietly. Somebody changes a field in the CRM, the integration stops hitting that field, nobody notices, because nobody is responsible for it. The owner is one person, named, with the task written into their job. Not a department.

Resistance rarely comes from a dislike of technology. It comes from change arriving as an announcement instead of a conversation, and from nobody saying out loud what happens to the time that gets freed up.

The third piece is when you run the training. People learn a tool at the moment they have to do their own work in it, so training run two weeks before go-live evaporates before the start. The conditions on the data, people and rules side are in our guide on how to prepare your company for AI.

• Tool owner: one person, named, with the configuration and the access rights written into their responsibilities
• The person who knows the process from the inside joins the project as the expert on exceptions, not as the subject of the analysis
• Say plainly which task disappears, instead of promising that „nothing will change”
• Training in the week of go-live, on the team's real cases, not on examples from a manual

07

How do you tell the transformation is happening, not just running?

By the numbers from specific deployments, not by a percentage of programme completion. „Transformation is 60 percent advanced” says nothing. „The weekly report writes itself, instead of taking 4 hours” says everything, and anyone can check it.

Measure every deployment on its own, with the same method as before the start, at 30 and at 90 days. The formula for the return and a worked example are in our guide on automation ROI.

We measure our own deployments the same way. Two AI agents have been in production in our founders' companies since March 2026. At the performance marketing agency, margin in May, June and July 2026 was 5.55 percentage points higher year on year, on revenue up 1.5 percent, and the number of people using the agent grew from 4 in March to 23 in August. That is a coincidence in time, not proof of cause: the client mix changed over the same window. The full figures with the measurement method and the caveats are in the sources below.

• Hours: how long the task takes after the deployment, counted with the same method as before it
• Volume: how many cases went through the new flow, and how many went back to the old one
• Clean-up: how many places of record you managed to switch off, because that is the real measure of transformation, not the number of licences bought
• Adoption: how many people used the tool in the last week; without that number a report shows a dead deployment and a live one the same way