The Gap Analysis, in detail

What a gap analysis is

A gap analysis is an evaluation method that compares an organisation's current operational state against the state it is trying to reach. It is not a single-channel audit and it is not a proposal. It is the step that happens before a proposal exists, and its output is a description of the distance between two points rather than a recommendation to buy something.

The method breaks a business into three parts. The current state is what is actually happening today: real performance numbers, the software that is genuinely in use, where traffic comes from, what converts, and how the team moves work through a week. The future state is the measurable target — more qualified enquiries, a lower cost to acquire a customer, a workflow that no longer needs to be re-typed by hand. The gap is the specific set of missing capabilities, broken code, manual processes and blind spots sitting between the two.

Most businesses can describe the second part without help. They know they want double the leads or a back office that runs itself. What they usually cannot name is the exact place where money and effort are leaking out of the operation they already have. That unnamed point of friction is where projects fail, and naming it is the entire job of the diagnostic.

Why it comes before a quote

The common failure mode in this industry is prescribing before diagnosing. A prospect asks for a website and receives a website quote. A prospect asks for search work and receives a monthly content retainer. The shape of the answer is decided by the shape of the question, not by what is actually broken.

That approach treats symptoms. A business convinced it has a traffic problem can spend heavily on advertising while its real constraint is a form that silently fails or a database query slow enough to lose the visitor before the page finishes. More traffic aimed at a broken pipeline does not fix the pipeline; it just spends the budget faster.

Running the diagnostic first also changes what a scope document can honestly contain. No team can price a complex web application, a custom database or an agentic AI system accurately without looking at the existing infrastructure first. Skipping that step is how an underquoted project turns into a sequence of change orders once the deposit has cleared.

The four areas we inspect

Because Schkovl runs both a growth practice and a software practice, the diagnostic looks under the hood of the marketing engine and the technology stack in the same pass. Four areas are evaluated on every engagement.

• →Visibility and acquisition — how potential customers find the business today across traditional search engines, AI answer engines and paid channels.
• →Conversion and pipeline — what actually happens after a prospect lands on the site or inside the application.
• →Technology and data infrastructure — whether the software, APIs and database architecture can carry more load without breaking.
• →Operational workflows — where the team is spending manual hours on work a script or a bounded agent should be handling.

The evidence we collect

The diagnostic is evidence-gathering, not opinion-gathering. We read the analytics that already exist, audit the codebase that is already deployed, and walk the customer journey as a customer would experience it. Where a system can be measured directly, we measure it directly rather than trusting a summary dashboard.

The published NorthGuard Window Film engagement is the clearest example of what that means in practice. The July 2026 audit hashed the raw HTML returned for every route on the site. All nineteen URLs produced an identical hash, which established — as a fact, not an impression — that the site was serving one client-rendered shell to crawlers regardless of which page had been requested. That finding came from fetching the pages and comparing the bytes, and anyone else fetching the same URLs could have reproduced it. A Schkovl co-founder holds a partner stake in NorthGuard Window Film, so this is not an arms-length client relationship; the full disclosure is on the case-studies page.

We look at the workarounds too. The spreadsheet someone maintains on the side, the step a person repeats by hand every morning, the listing nobody has updated in a year: those are part of the current state whether or not they appear in any system diagram.

An illustrative example (not a client engagement)

The walkthrough below is written for this page as an illustration of how the method moves from symptom to root cause. It is not a client, not a case study, and not a measured result. Schkovl's real, dated engagements — with the numbers and their limitations — are published on the case studies page.

Imagine a service business that says its problem is traffic. It is spending on ads every month and the sales team reports that the phone is quiet. The instinctive prescription is more traffic: more budget, more keywords, more pages.

Walking the four areas changes the question. Visibility and acquisition shows the ads are in fact delivering visitors. Conversion and pipeline shows those visitors reaching a quote form that fails for anyone who fills it in on a phone. Technology and data infrastructure shows a query slow enough that a slice of visitors leaves before the page is usable. Operational workflows shows that the enquiries that do arrive sit in a shared inbox until someone notices them.

In that illustration, nothing about the traffic layer was broken, so nothing spent on the traffic layer would have moved the outcome. The prioritised list starts with the form, then the query, then the inbox routing — and the advertising spend is left alone until the pipeline it feeds actually works. That is the only reason the diagnostic runs first.

How findings get prioritised

A list of everything wrong with a business is not useful on its own. The diagnostic ends with an ordered execution plan: what to fix first, what to build next, and what to ignore entirely.

Ordering is driven by what is blocking everything downstream. A structural defect that caps what the rest of the system can achieve is worth fixing before anything that depends on it. Existing tools stay in place if they work — the blueprint maps only the system that closes the gap, rather than a stack chosen first and retrofitted to the problem afterwards.

That ordering sometimes produces a recommendation to buy nothing from us. Some gaps are operational rather than technical, and there is no software fix for a process problem. Schkovl has declined work on that basis.

What you receive, and what you own

The deliverable is a diagnostic breakdown of the current operational bottlenecks, the growth opportunities being missed, and the technical debt already accrued — followed by a prioritised execution plan with specific action items across both marketing and software.

That roadmap is yours. You can execute it with Schkovl, hand it to an internal team, or take it to another agency. The findings are presented on a kickoff call, and a plan to execute the recommended fixes is outlined from there.

What the method does not do

A gap analysis is a diagnostic, not a guarantee. It tells you where the distance is between today and the target; it does not promise a ranking, a traffic number or a revenue figure, and we do not present it as though it does.

It is also bounded in time and depth. A comprehensive gap analysis typically runs one to two weeks depending on the complexity of the business and the stack, and it produces an actionable report rather than an open-ended consulting relationship.

Finally, it is not the contract. Scope, deliverables and pricing for any engagement are set out in a separate written agreement or proposal between Schkovl and the client. The diagnostic informs that document; it does not replace it.

A technical audit score measures crawlability and indexability. It is not a search ranking, a traffic figure or a revenue result, and Schkovl does not publish it as one.

Where to go next

Last reviewed

The facts on this page were last checked against published Schkovl sources on 2026-09-20.

Everything here is drawn from material already published on this site. If something looks wrong, our editorial standards and corrections policy explains how to have it corrected.