Start from the business problem, never the technology
“We should do something with AI” is a pressure, not a strategy, and projects born from it select use cases by visibility instead of value. Reverse the direction: list where hours are lost, where clients wait, where information gets re-keyed, and only then ask which of these AI can absorb. The projects that survive their first year are boring on purpose: invoice routing, report generation, request sorting. The spectacular ones demo well and die quietly. Every engagement we run starts with the problem list, never with a tool.
Diagnose before you build
A diagnostic maps how work, documents and decisions actually flow, which is reliably different from how everyone assumes they flow. In one to three weeks of workshops and interviews it produces three things a strategy needs: the friction map, a quantified gain estimate per use case with assumptions written down, and a roadmap separating quick wins from deep projects. The deliverable stands on its own even if you build with someone else, which is the test of an honest one. This is lever one, and the format of our diagnostic.
Prioritising: measurable return within the quarter
Score every candidate on four axes: hours saved per month, error cost if the automation misfires, integration depth required, and whether a motivated owner exists. The first project must score well on all four, because it carries a burden beyond its own return: it sets what your team believes about AI. A first success makes the second project easy; a first failure poisons the well for years. This is why the flashiest use case, which usually fails the error-cost axis, should almost never go first.
Your data: good enough beats perfect
The two failure modes are symmetrical: launching an assistant on documentation nobody has looked at since 2019, and postponing everything until a mythical day when the data is clean. The working middle: pick the narrow scope of your pilot, clean only the documents that scope needs, and let the pilot itself reveal what is worth structuring next. Where know-how lives in people’s heads rather than files, capturing it is the project: structured interviews with your senior experts, turned into a queryable base. That is the knowledge-management lever, and for sensitive know-how it comes with the governance questions below.
Pilot on a narrow scope, then scale what worked
The pilot’s scope should feel almost disappointingly small: one process, one team, a few weeks. Narrow scope is what makes value verifiable, and verifiable value is what makes the next budget conversation easy. Define acceptance criteria before building, run old and new in parallel briefly, measure, then widen. We aim to take a proof of concept to working MVP in 13 days on average precisely because narrow scopes permit it. Scaling a verified pilot is routine; rescuing a big-bang rollout is not. Our case studies all follow this shape.
Adoption: the human half of the project
A perfect workflow nobody uses returns exactly zero, and adoption is decided early, not at the training session. Involve the people who run the process today in designing its replacement: they know the exceptions no workshop surfaces, and co-designers do not sabotage their own design. Give the tool one named owner. Frame honestly what changes in each job, because “nothing changes” is never true and everyone knows it. Then train on real cases, not demos. We treat training as a deliverable with acceptance criteria, not a handover meeting.
Governance: decide early, decide once
Four questions settle most of it, cheaply if asked early and expensively if asked after an incident. Which data may leave the company, to which providers, under which contractual terms? Who may use AI for what, written in one page of plain language rather than a policy nobody reads? Which decisions require a human signature no matter how good the automation gets? Where is it all hosted, knowing French and European options exist at SME prices when sovereignty matters? Write the answers down once; every subsequent project inherits them instead of relitigating them.
Measure from day one
The baseline is the strategy’s memory: without a before, every after is an anecdote. Measure the process before touching it, in hours per month and error rate. Ship every automation with its own counters: volume processed, time saved, failures. Keep it to one simple dashboard your leadership actually opens, not a reporting machine. Then review quarterly: what worked feeds the next scope, what underperforms gets fixed or killed. Sunsetting a mediocre automation is a sign the measurement works. Our pricing and ROI guide details the honest metric.