Skip to content
← Back to Insights

Introducing Automated Business Diagnostics

I built a small self-serve diagnostics tier for the cases where a full consulting engagement is too much, too early, or too expensive.

John Sambrook, TOC Jonah Certified ·
Automation Services Diagnostics Theory of Constraints

TL;DR

I built an automated diagnostics tier because not every problem needs a full consulting engagement on day one. Some problems need a quick, concrete read first. The self-serve tier handles the repeatable checks, scoring, and first-pass report. I handle the judgment, the tradeoffs, and the decisions that still need a person. Right now, the live offer is the JSON-LD Schema Audit. The other diagnostics are prototypes, not promises.

Last week I was looking at a website that had been getting steady traffic for months and almost no useful inquiries. The site looked fine. The copy was decent. The owner was not doing anything obviously wrong. But the site was speaking to search engines and AI systems in a way they could not really use. That is the kind of problem that can burn a lot of time if you jump straight to a big engagement before you know what is actually broken.

That is one reason I built a small automated diagnostics tier.

The other reason is simpler: some people need a useful answer before they are ready to buy a larger piece of help. They may need to know whether the issue is their markup, their messaging, their visibility, or something deeper in the business. A short diagnostic can separate the obvious from the non-obvious and keep both of us from wasting time.

What I Mean by “Automated”

I am not talking about replacing judgment with software.

I am talking about automating the parts that are repeatable and well-bounded:

  • collecting the input
  • checking known conditions
  • running a fixed analysis path
  • scoring or flagging the result
  • producing a report the buyer can use

That works well when the question is narrow enough to be answered from a known set of checks. It does not work when the real problem is still being defined, the stakeholders disagree about what “done” means, or the situation depends on local context that cannot be inferred from a crawl or a form submission.

That is why the automated tier sits below the human-led work instead of replacing it.

What Is Live Today

The live offer in this tier is the JSON-LD Schema Audit & Implementation Guide.

It is the clearest example of what I mean by a diagnostic product:

  • you give me a URL
  • the site is checked for structured data and related signals
  • the analysis produces a plain-English report
  • you get sample corrected markup and implementation guidance

That is enough to be useful on its own. It is also enough to tell you whether the larger problem is probably a visibility problem, a messaging problem, or a broader offer problem.

At $197, it is deliberately small. I wanted something that could answer, “Is this worth a larger conversation?” without forcing the buyer into one.

What I Am Building Toward

I have a couple of other diagnostics in prototype form. I am not selling them yet, and I do not want to pretend otherwise.

One is a GEO visibility audit, which looks at how well a business can be seen and cited by search and AI systems. Another is an offer clarity diagnostic, which looks at whether a business’s offer is easy to understand, easy to trust, and easy to buy.

Those are useful because they each answer a different question:

  • “Can machines understand what this business does?”
  • “Can a buyer understand why this offer is the right one?”
  • “Does the problem look like visibility, messaging, or something deeper?”

That matters because businesses often try to fix the wrong layer first. They spend on design when the offer is unclear. They rewrite copy when the issue is actually structural. They buy another tool when the constraint is in the process. A diagnostic should help stop that.

What Automation Can Do Well

When the input is clean enough, automation is very good at:

  1. Running the same check the same way every time.
  2. Comparing a site or a workflow against a known standard.
  3. Producing a report that is consistent from one run to the next.
  4. Catching obvious gaps before a person spends a lot of time on them.

That is valuable because it lowers the cost of getting a first answer.

If I can tell you in a short report that your site has no usable schema, or that your offer copy is too vague for a buyer to act on, then you do not need a two-hour call to discover the first layer of the problem. You can decide whether the next step is a fix, a conversation, or a deeper analysis.

What It Cannot Do

Automation stops being reliable when the problem is not purely technical.

It cannot:

  • decide which stakeholder definition of success matters most
  • resolve a real organizational conflict
  • infer hidden constraints from incomplete evidence
  • replace the judgment needed to choose between competing good options

That is not a flaw in the tool. It is the point where a tool hands work back to a person.

I think a lot of businesses get tripped up by this boundary. They either expect software to do strategy, or they assume every problem needs a human from the first minute. The useful middle ground is more practical: let the machine do the repeatable analysis, then bring me in when the work stops being mechanical.

How It Fits the Ladder

I think about the ladder like this:

  1. A self-serve diagnostic gives you the first read.
  2. A short conversation helps interpret what the first read actually means.
  3. A fixed-fee human engagement handles the cases where the diagnosis needs context, tradeoffs, or implementation support.

That ladder is better for buyers than a one-size-fits-all consulting offer. It gives people a lower-friction entry point without pretending the lower tier can solve everything.

It is also better for me. It keeps the work honest. If a quick diagnostic is enough, that is the right answer. If it is not enough, I would rather say that plainly than overstate what the machine can do.

Why I Care About This

I did not build the automated tier because I think consulting is obsolete. I built it because I think clear problems should be handled in the clearest possible way.

If the issue is narrow and the checks are known, automation can be the fastest and cheapest path to a useful answer.

If the issue is ambiguous, cross-functional, or tied up in real business conflict, then the answer is not a report. It is a conversation, an analysis, and probably some actual work.

That distinction matters. It keeps the first tier honest and the higher tiers useful.

If you want to try the live version, start with the JSON-LD Schema Audit.

If you are looking at a mess and trying to decide whether it is a visibility problem, an offer problem, or a deeper system problem, I would welcome the conversation. You can reach me at john@common-sense.com.