The request is not the problem
A business calls with a specific ask. Redirect these pages. Connect this system to that one. Automate this report. The ask is almost always sincere and almost always describes a symptom rather than the condition producing it. The person making the request reasons from inside the operation, and has lived with the underlying constraint long enough to stop seeing it.
Intent analysis is the diagnostic work that happens before anything gets built. The work decodes what the business actually needs and establishes what is structurally possible given the systems already in place. It sizes the problem honestly, then identifies where to start. Firms that skip this step deliver exactly what was requested, which is how a company ends up paying for a competent solution to the wrong problem.
What a symptom-level brief looks like
One engagement began with a narrow request. An online retailer wanted product pages redirected to a set of hub pages, because search was indexing the wrong ones. Straightforward on its face, and the kind of task that gets quoted in an hour. The work went through several rewrites, and every rewrite was forced by learning something further about how the catalog was actually built. The product records were shared parents carrying variations for each configuration, and the identifying codes lived on the variations rather than on the parents. An approach aimed at the variation level collapsed everything back onto the parent and over-redirected almost the entire catalog. Handling it at the parent level forced an arbitrary choice, since one parent legitimately belonged to several destinations.
The correct answer turned out not to be a redirect at all. Consolidating the ranking signal to the destination page while leaving the original reachable was the only approach that could send different configurations of the same address to different destinations. But the finding underneath the finding was the one that mattered: this business had no product pages capable of ranking or transacting, and the hub pages were the only surface available for either. That is not a redirect problem. That is a fact that determines the entire content and commerce strategy, and it had never been articulated.
Internal organization is not how customers search
One finding from that assessment generalizes to almost every business we work with. The existing pages were organized by style and finish, which is precisely how the company thinks about its inventory. It is a coherent taxonomy and it is the wrong one, because a customer with a job to do does not search for a finish name. They search for the job rather than the product line. The piece that fits the awkward space. The option that works with equipment they already own.
So the page architecture was rebuilt around configuration and problem rather than around internal classification, with each new page defined by a rule so the map can keep expanding. That translation, from the client’s internal organizing logic to the customer’s external organizing logic, is frequently the highest value output of the whole diagnostic. Companies almost never see it themselves, because the internal taxonomy is the water they swim in.
Size the problem before proposing a solution
A catalog of roughly four thousand configurations sounds unmanageable, and quoting it that way would have been easy and defensible. Examining the actual data showed those four thousand configurations resolved to only about three hundred and fifty distinct descriptions, since the same specification repeated across every finish of the same item. The work was a three hundred item job rather than a four thousand item job, which changes the timeline, the cost and the entire question of whether it is worth doing.
Right-sizing cuts in both directions and we report it either way. Sometimes the assessment finds the problem is far smaller than the business feared. Sometimes it finds a request that sounded like a week of work depends on data conditions that will take a month to correct first. Either finding is more valuable than a confident estimate made without looking.
Choosing the first project
The last output of the diagnostic is a sequence. The first project should be high frequency, well understood and low consequence, because it produces a visible result quickly and builds the confidence that makes the harder work possible. The diagnostic also identifies work that should not be done at all: processes that exist because of a system limitation nobody has revisited, requests that would automate a workflow better removed than accelerated, data conditions that have to be corrected first. Saying so costs us the larger engagement in the short term.
Where AI earns its place in diagnostic work
Diagnostic work used to be constrained by how much a person could read. Examining thousands of records to find they resolve to a few hundred distinct patterns. Comparing how an entire site is organized against how customers actually describe what they want. We use AI for that analysis, and it is a genuine change in what a diagnostic can cover, because the full data set can be examined rather than a sample of it. What comes back is a set of candidate findings with the evidence attached.
"A model can tell you that four thousand records collapse to three hundred and fifty patterns. It cannot tell you whether fixing that is the right thing to spend the next month on."
The judgment stays human. Which findings actually matter to this business, which apparent problem is in fact deliberate, and what the correct first project is are decisions made with the people who own the consequences.
What you end up with
A written account of what your systems and architecture actually permit, which is frequently the first time that has been documented. The translation between how you organize your business internally and how your customers describe what they want. An honestly sized version of the problem you called about. A sequence with a defensible first project. The findings are yours whether or not we do the implementation.
How the engagement runs
Diagnostic work happens through screen shared working sessions against your live systems and data. Where physical operations are part of the picture, onsite observation earns its cost and is covered in onsite engineering. The search and content execution that follows an intent map is covered under organic search marketing. The systems work it typically leads into is covered in CRM integration, ERP integration and workflow automation.