Our approach

Discovery first, then a plan, then working systems, then a number.

The order is fixed and it is the whole method. We will not recommend a build before we have watched the work, and we will not call an engagement finished before the number we agreed at the start has moved.

This page is the long version. If you want the short one, it is four steps: assess, prioritize, implement, measure.

Schedule a Strategy Call

Illustrative engagement board for a fictional business showing the four steps side by side: a workflow map from Assess, a ranked opportunity list from Prioritize, a system in testing under Implement, and the agreed metric tracked against its baseline under Measure and refine. — Illustrative screens on this page use a fictional business and fictional data.

What does discovery-first actually mean?

It means the recommendations are outputs of the discovery, not inputs to it. We arrive with a method and no conclusions. What gets automated, what gets built, who it is for, and what it is measured against are all decided after we have seen how your business runs, never before.

The alternative is what most of this industry does, and it is easy to spot once you know the shape. A firm arrives with a product it already sells, spends two weeks confirming you need it, and presents that as a finding. The tell is that the recommendation could have been written before the first meeting. Ours could not, and the written list of what we advise you not to automate is the proof, because a template does not produce that list.

Illustrative list of three ideas judged not worth automating, each with the reason written beside it.

There is a cost to working this way and it is worth being straight about it. Discovery-first is slower to a proposal than a firm that already knows what it wants to sell you, and it occasionally ends with us telling you there is nothing here worth building yet. Both of those are features. Neither is comfortable.

The method

What happens in each of the four steps?

Each step ends in a document or a system you own, so you can stop at any boundary and still be further ahead than when you started. Nothing is held back to force the next stage.

/ 01

Assess

In one line: We find out how the business actually runs.

What happens: We sit with the operations we agreed to scope and follow the work through them. That means reading the systems your team already uses, watching where information gets re-entered by hand, and interviewing the people doing the job alongside the people who own the process. We time the tasks that get repeated. We collect the artifacts: the proposal templates, the intake forms, the spreadsheets somebody maintains that nobody asked for.

Why it is done this way: Process documentation describes the intended workflow. Interviews with the person doing the job describe the actual one. The distance between those two is where most of the recoverable time is sitting, and it does not show up in either account on its own.

What you get: A workflow map of the scoped operations, and a plain-language write-up of where time and margin are leaking.

How long: Most of the two to four weeks.

Illustrative workflow map of a fictional client intake process, with the steps where information is retyped by hand highlighted.

/ 02

Prioritize

In one line: We rank every opportunity honestly, including the ones we would not take.

What happens: Each candidate opportunity is scored on three axes: the return it would produce, the effort to build it, and the risk it carries if it goes wrong. Return is modeled rather than asserted, using the volumes and durations collected in step one. Risk covers what happens when the system is wrong, not only whether it works, because a tool that drafts a client email and a tool that quotes a price fail very differently.

Why it is done this way: Ranking by return alone produces a roadmap that starts with the most expensive item and stalls. Sequencing from fastest payback funds the rest of the program out of its own results, which is the difference between a roadmap that survives a budget review and one that does not.

What you get: A phased roadmap with sequencing and owners, a modeled return on the top recommendations, and a written statement of what is not worth automating and why. A walkthrough session to hand it over.

How long: The back end of the assessment window.

Illustrative scoring table rating four AI use cases on the same scale for return, effort, and risk.

/ 03

Implement

In one line: We build the thing, inside the software you already use.

What happens: Production build, integrated with your existing systems, tested against a set of real cases pulled from your own records rather than demo data. Your team gets trained on it while it is being built, not after. Documentation is written for the person who will do the job, not for a developer who might inherit it.

Why it is done this way: A system tested only on clean examples fails on the first messy one, and the messy ones are the majority. Real cases surface that before launch, when it is a fix, rather than after, when it is a reason to stop using the tool.

What you get: A working system you own outright, documentation, handover, training, and a measurement approach wired to the metric agreed up front. No vendor lock-in.

How long: Typically 4 to 8 weeks per system. Multiple systems are sequenced rather than run in parallel, so nobody on your team is absorbing two changes at once.

Illustrative Implementation Sprint tracker in its testing stage, showing test results against real cases and the documentation, baseline, training, and handover checklist.

/ 04

Measure and refine

In one line: We report against the one number until it moves.

What happens: The KPI was agreed before any work started, so there is nothing to negotiate about at this point. We report against it monthly, with the baseline shown alongside, and we keep tuning the system while the number is short of target. Where a system is doing its job but the KPI is not moving, we say so and look at why, rather than quietly reporting activity instead.

Why it is done this way: One metric agreed in advance is the only version of this that cannot be gamed after the fact. A dashboard assembled at the end of an engagement will always find something that went up.

What you get: Monthly reporting against the agreed KPI, and continued refinement until it is met.

How long: Every engagement targets a first measurable result within 90 days.

Illustrative monthly partnership report tracking the agreed metric against its baseline, beside the build queue for the quarter.

What do we need from your side?

Less than you probably expect, and it is mostly access rather than effort.

One person who can make decisions

Not a committee. Someone who can approve scope, resolve a disagreement between two departments, and say no. Engagements that stall almost always stall here.

Time with the people doing the work

Usually an hour each, sometimes two. This is the single most valuable input you provide and it is the one most often offered up as a substitute in the form of a process document.

Read access to the systems in scope

The tools where the work already happens. We do not need administrative rights to assess, and we will tell you exactly what we are looking at before we look at it.

Real examples, including the bad ones

The awkward client file, the job that went wrong, the quote that had to be redone three times. Clean examples make a demo. Difficult ones make a system that survives contact with your actual work.

No technical staff

Deliberately on this list. You do not need a developer, an IT department, or anyone who knows what a model is. If a system we build needs an internal engineer to stay alive, we have built the wrong system.

How long does all of it take?

Two to four weeks to a roadmap, four to eight weeks per system after that, and a first measurable result inside 90 days. Those are the commitments, not averages.

What sits between those numbers is your decision time, and it is genuinely yours. The roadmap is a finished document that stands on its own, so there is no expiry on it and no pressure built into the sequence. Some clients move to a build the week after the walkthrough. Some take a quarter, or take the roadmap to their own team and build it there, which is a legitimate outcome the document is written to support.

Illustrative engagement timeline: assess and prioritize over two to four weeks, a gap for your own decision, one system implemented over four to eight weeks, then monthly measurement, with the first measurable result marked inside 90 days.

The one thing we will not compress is step one. An assessment run in a week is a survey, and a survey tells you what people believe about their own processes, which is the thing this method exists to get past.

How does this work for AI search visibility?

The same four steps, with a different instrument at each one. AI search visibility work has its own measurement system, so the method is more literal there rather than different.

Assess

The five-pillar AI Visibility Audit and the six-dimension Brand Gap analysis. A locked set of the questions your customers actually ask, run three times each across every surface, with the transcripts attached

Illustrative AI Visibility Score for a fictional business: a composite of 56 out of 100 beside a score for each of the five pillars.

Prioritize

Every failed check comes with the business consequence, the specific fix, and the engagement that delivers it. The fix list is ranked, not dumped

Implement

A remediation tier: Tier 1 Foundation, Tier 2 Growth, or Tier 3 Authority, scoped from your own findings rather than from a package

Illustrative remediation plan with fixes grouped into Tier 1 Foundation, Tier 2 Growth, and Tier 3 Authority.

Measure and refine

The Quarterly Recheck. Same rubric, same locked question set, rerun, with a delta report showing exactly what moved

Illustrative Quarterly Recheck delta report comparing a fictional business's pillar scores across two quarters on the same question set.

The recheck is the part worth pausing on, because it is the step most of this industry skips. Rerunning the identical question set is the only way to prove the work did anything. A recheck against different questions is not a measurement, it is a new opinion with a chart on it.

See how AI search visibility works

Honest boundaries

What does not happen

Four things this method rules out. Each one costs us work we could otherwise sell, which is the only reason any of them is worth stating.

We do not build from a spec we did not write

Levels three and four exist to carry out a plan we produced. We cannot stand behind a result we did not scope, and a build we did not diagnose is somebody else's guess with our name on it. If you already know exactly what you want built, that is a good position to be in. It is a build conversation rather than a strategy one, and we will route you to CAL Design, our development and production partner.

We do not run pilots or proofs of concept

A pilot is a way of postponing the decision about whether something is worth doing while spending money as though it were. Either an opportunity survives being scored on return, effort, and risk, or it does not belong on the roadmap.

We do not deliver a strategy deck and leave

The roadmap is a document you own and can hand to anyone, including your own team. If you want what it recommends built, we build it, and it stays our responsibility until it works.

We do not sell governance separately

Policy, guardrails, and safe-use standards come with the build. Governance is not a product anyone shops for, it is a reason to trust the products.

Get started

Where would this start for us?

That is the call. Thirty minutes, no pitch deck, no obligation. We ask how work moves through your business and where it gets stuck, and we tell you which step you should be starting at, including the case where the honest answer is not yet.

Schedule a Strategy Call See what an assessment covers

We reply within one business day.