System run · public-signal diagnostic · disclosed limits

The right first AI project was not a new AI project.

Substrate analyzed a Calgary home-services operator across intake, estimating, scheduling, delivery, invoicing, reputation, and retention. Its primary conclusion was to configure owned capabilities before commissioning custom software.

Real system artifactModel call budget recordedFacts and estimates separatedNot a client engagement
WHAT RAN

One company through the complete diagnostic path.

The system received a structured company brief, verified public facts, software context, customer signals, and explicit uncertainty rules. The call passed through Substrate's model router and budget gate, wrote a persistent research artifact, and advanced the opportunity state from detected to researched.

Recorded model-call cost for this diagnostic: USD $0.0793. This is the model call recorded by the pipeline, not the price of a client engagement.

Ranked findings

Where the system would investigate first.

The ranking joined a visible operating signal to a specific capability and number. It did not treat every stage as a reason to add AI.

01 / INTAKE

Test unanswered-call capture and speed-to-lead using capabilities available in the existing field-service stack.

CONFIGURE
02 / CONSULTATION

Address the public rescheduling signal with reminders and pre-visit qualification before adding a custom agent.

CONFIGURE
03 / RETENTION

Segment the existing customer base by completed work and time since service for controlled reactivation.

CONFIGURE + TEST
04 / QUALITY

Structure completion evidence and callback reasons so rework can be measured before it is predicted.

PROCESS FIRST
05 / CASH

Connect job completion to invoice creation and route disputed or overdue cases to a person.

CONFIGURE

The non-obvious finding

An AI quote cannot fix an undefined price model.

The company publicly described a broad hourly service. A reliable instant quote needs a defined catalogue of common jobs, variables, exclusions, and pricing rules. The diagnostic identified this operating design task as the prerequisite.

WITHOUT THE PREREQUISITE

The bot guesses.

  • Scope varies with every description
  • No stable item exists to price
  • Exceptions are discovered after commitment
  • Automation creates quoting risk
WITH THE PREREQUISITE

The system has something to reason over.

  • Common services become defined items
  • Inputs, exclusions, and ranges are explicit
  • Uncertain work is routed to an estimator
  • Online booking can begin with safe categories

Generated deliverable

More than a recommendation paragraph.

The run produced the same structured outputs now used by the reusable Business Diagnostic input contract.

15operating stages considered from lead generation to subcontractors
8automation stages mapped with triggers and human roles
90days sequenced from owned configuration to measurement
5owner questions that could materially change the recommendation

What this proves

The diagnostic engine runs. The business result still has to be earned.

The artifact proves that the system can accept company evidence, reason across an operating cycle, classify interventions, preserve uncertainty, and produce a structured roadmap. It does not prove that the subject company adopted the recommendations or achieved the estimated effects.

Observed

The pipeline ran, recorded its model cost, generated the required sections, persisted the report, and changed the opportunity state.

Estimated

Potential capture, no-show, reactivation, margin, and cash-flow effects require the company's own baseline data.

Next proof

An owner-approved internal diagnostic followed by one measured pilot against written acceptance criteria.

Run it on a different business

Replace public hypotheses with your operating facts.

Start with the company, systems, repeated workflows, current failures, constraints, and the numbers management already watches.

Request a diagnostic