Clarity before technology.
Start with the business problem and its cause, not with a tool or proposed solution.
These are seven entry points into one decision journey — not seven service packages. Start wherever you already are.
Pick the situation closest to yours, then open the question that fits. Each station on the map takes you straight to it.
“We want to use AI. Where should we start?”
“This process is a headache. How should we automate it?”
“We built an AI agent. Can we rely on it?”
If something important is missing, we move backward before moving forward.
Choose a question to see what it takes to answer it.
Before talking about tools, we look at how the work actually gets done: where time is consumed, decisions repeat, work gets stuck, mistakes happen, or people spend their day moving information between systems.
Then we separate the problems technology could credibly help with from the ones it probably cannot.
whether there is a real opportunity — and where it is.
An opportunity only matters if it changes something useful.
We connect the areas we find to outcomes that matter in the operation: more capacity, faster turnaround, better service, fewer errors, greater reliability, or more time for people to focus on work that actually needs them.
Where possible, we also define how that improvement could be measured.
where technology could genuinely improve the business and what “better” would actually mean.
Value is the operating outcome.
The biggest idea is not always the best first move.
We compare the expected value with the evidence behind it, urgency, readiness, complexity, dependencies and what happens if the solution fails.
Sometimes a smaller opportunity is the better starting point because it can work now and makes the next move easier.
what to do first, what to prepare next, and what to park for now.
Start where it matters most.
The part that looks slow is not always the part causing the problem.
We reconstruct how the work really happens: the handoffs, waiting, decisions, exceptions, rework and bottlenecks — and look at what changes upstream and downstream if one part gets faster.
Where possible, we establish the current baseline so there is something real to improve against.
whether this is actually the part worth changing, or whether the real problem sits somewhere else.
Once the problem is clear, we work out what the task actually requires.
Maybe a step should disappear. Maybe two systems need to talk to each other. Maybe a rule is enough. Maybe conventional automation works. Maybe AI should assist a person, or take on a tightly bounded part of the work.
If a vendor or tool is already on the table, we test it against the same requirements rather than accepting the demo as the starting point.
what should change, what technology fits, and what does not need technology at all.
A capable tool is not enough if the business cannot give it what the work depends on.
We identify the information, context, rules, systems, permissions and exceptions involved.
We define what technology may decide or do, what happens when something falls outside the normal case, and where a person still needs to review, approve or take over.
That often reveals the real preparation work: rules sitting in someone’s head, inconsistent data, missing access, unclear ownership or decisions nobody has formally defined.
what needs to be prepared before implementation and exactly where technology’s responsibility should stop.
We go back to the task itself and compare what a good result actually requires with how the solution has been built.
We look at whether the technology fits the task, what information and context it receives, how the prompting or instructions are structured, where it can fail, whether simpler logic would be more reliable, and where guardrails or human validation are missing.
Then we define the cases it needs to survive: normal cases, edge cases, missing or contradictory information, unusual situations and failures.
We turn those into concrete test scenarios and acceptance criteria.
what to test, what needs stronger prompting, controls or human checks, and whether the right answer is to keep it, strengthen it, simplify it or replace it.
We start with the question you actually need answered and go only as deep as that decision requires — understanding the work, establishing the evidence, finding what drives the result, checking what the technology depends on, and defining what should happen next.
The seven questions are the spine. The methodology is the navigation system. Every problem is a new quest.
Each principle comes from a point on the journey. Its color shows where it applies.
Start with the business problem and its cause, not with a tool or proposed solution.
Automation is useful only if it improves the operating outcome, not simply one activity inside the process.
Use the simplest technology that can solve the problem reliably. More intelligence does not automatically mean more value.
Define what technology may know, decide and do, where its authority ends, and when responsibility returns to a person.
Better AI still needs the right information, context, rules and boundaries to act reliably.
Real operations include exceptions, failures and consequences. The solution has to work there, not only in the happy path.
Start with the question that matters to your business.
Discuss your situation ↗