BLOG MATRIX / OUR PROCESS
How an engagement
actually runs.
Stage by stage, in order: who has to be involved at each one, what commonly derails it, and what you keep when it ends.
Understand the business
The first conversation is about the business rather than the website: what you sell, who buys it, what an enquiry is worth once it arrives, and which of your services you actually want more of. That last question matters more than it sounds. Most sites end up optimised for whatever was easiest to describe, which is rarely the work with the best margin.
We also establish who can do things. Who can publish a page, who is allowed to approve a factual claim, who can deploy a change to the site. Engagements stall on that far more often than on strategy, and it is a much cheaper thing to discover in the first week than in the third month.
Review the starting point
Then the site and whatever data exists: a crawl, search data if there is any history, the templates that generate most of the pages, and the handful of pages already earning something. Depth follows scope. A forty-page service site is a day of reading. A catalogue with variants, filters and a decade of discontinued products is not.
Two findings turn up often enough to mention, and both change the plan rather than adding to it. The first is that search is not the problem: pages rank, people arrive, and nobody enquires, which is a conversion or an offer question and not one more SEO task. The second is that something is actively preventing discovery, in which case it jumps ahead of everything else and the rest of the roadmap waits, because it is technical work that has to land first.
Prioritise the work
Recommendations get ordered by what they would move, what they depend on, and what they cost to carry out. That third column is the one most roadmaps leave off and the one that decides whether anything happens at all. A recommendation requiring four days of developer time you do not have is not a priority, it is a wish with a rank against it.
So the roadmap separates what we can do, what only your team can do, and what needs somebody you may not have yet. If the honest version is shorter than you were expecting, that is the useful outcome rather than a disappointing one, and it is usually where an advisory scope is the right shape instead of a delivery one.
Agree ownership, then implement
Before work starts the proposal names who writes, who checks the facts, who deploys and who signs off. Leaving any of those unassigned is the single most reliable way to turn a three-month plan into a nine-month one, and it never announces itself: the work simply sits, and everyone assumes somebody else is holding it.
While the work runs we keep a register of what has shipped and what is blocked, with a name against each blocked item. Your developers keep control of their own releases. What we contribute is the specification, the affected examples and the check that confirms a change did what it was supposed to, so that finished means verified rather than sent.
Review, and say what did not work
Some of it will not work. A page built to rank does not; a term turns out to be harder than the research suggested; a competitor does something. Reviews are where that gets said plainly and the plan changes, rather than where it gets narrated around with a chart that happens to point upward.
The order matters: completed work first, then search visibility, then the business actions you care about. Reading it the other way round invites credit for movement nobody caused.
What you keep, and how you leave
Everything we produce is a document rather than a dashboard: the issue register, the briefs, the roadmap, the research. They are yours, and they remain readable after an engagement ends, which is not true of work that lives inside somebody else’s tool.
Access runs the same way. We ask for Search Console, analytics and CMS access through individual invitations rather than shared passwords, which means you can revoke any of it yourself, at any time, without asking us. An arrangement that is inconvenient to leave is not one you should be asked to enter, and the scope and commercial terms are set out before anything begins for the same reason.
QUESTIONS, ANSWERED
A few practical details.
How long does each stage take?
It depends on the size of the site and how quickly your side can review and publish. Approval queues stall more work than anything technical. We would rather scope around your real capacity than publish a timetable that slips.
Who does the implementation?
Whoever is agreed in the proposal, named before the work starts. Development, writing and publishing each need an owner. Most stalled engagements we have seen stalled because that was left vague.
What happens when something does not work?
We say so in the review and explain what we think happened. Work that did not move anything is information, and a process that only ever reports success is not reporting.
What do we keep if we stop working with you?
The work itself: the research, the documents, the content and the access, which was always yours. Nothing is held in an account you cannot reach. Ask any provider this before you start, not at the end.
A USEFUL NEXT STEP
Start with a useful conversation.
Share your current challenge and we’ll discuss an appropriate first step.