ZOPSYS

Fictional ZOPSYS Case Study · Sample Systems Review

Summit Pest Solutions

Summit Pest Solutions is a fictional business. This Systems Review demonstrates how ZOPSYS investigates the operating conditions behind Assessment signals.

Systems review objective

Primary owner objective

“Reduce Ryan’s day-to-day involvement while maintaining controlled growth and improving profitability.”

Review question

“What operating conditions currently require Ryan’s attention, and how should Summit’s roles, workflows, decisions, systems, and management visibility change so the business can operate reliably with less owner intervention?”

Assessment signals that triggered deeper investigation

  • Visibility & Resilience

    85.0 — Severe Constraint

  • Leadership & Key-Person Dependency

    75.0 — High Constraint

  • Revenue Flow & Capacity

    90.0 — Severe Constraint

These scores identified where to investigate. The Systems Review investigates why.

Executive summary

What the review found

“Summit’s growth has outpaced its operating structure. Ryan remains the exception-management layer because authority, visibility, workflow, and system handoffs are still too dependent on people.”

  1. 01Authority
  2. 02Visibility
  3. 03Revenue flow
  4. 04System orchestration

Current-state organization

Who reports to whom

Owner

Ryan Mercer

Owner / General Manager

  • · Major pricing exceptions
  • · Key customer escalations
  • · Hiring decisions
  • · Technician exceptions
  • · Sales oversight
  • · Vendor issues
  • · Management reporting
  • · Operational troubleshooting

Manager

Lisa

Office Manager

  • · Inbound calls
  • · Customer service team
  • · Scheduling oversight
  • · Billing coordination
  • · Technician/customer conflicts

Observed · Substantial responsibility, but decision authority is incomplete. Many exceptions still escalate to Ryan.

Team

2 CSRs / Dispatchers

Office team

  • · Phones
  • · Web inquiries
  • · Scheduling
  • · Estimate follow-up
  • · Customer changes

Observed · Follow-up and escalation practices vary by employee.

Manager

Mark

Service Manager

  • · Seven field technicians
  • · Technical quality
  • · Callbacks
  • · Field questions
  • · Inventory coordination

Observed · Critical technical knowledge is concentrated in Mark. Technicians regularly escalate exceptions to Mark or Ryan.

Team

7 Field Technicians

Field team

  • · Recurring service
  • · Inspections
  • · Treatment
  • · Field documentation
  • · Customer communication

Observed · Decision authority for discounts, additional work, callbacks and unusual conditions is inconsistent.

Owner · escalation pointManager · partial authorityTeam

The org chart shows who reports to whom. The orchestration map shows how work actually gets done.

Current-state orchestration map

How work and exceptions actually move

Customer / Lead
Office / CSR
Scheduling / Service
Lisa / Mark
Can they decide?
Continue
Ryan
Decision
Work continues
Routine work proceedsManager decision pathEscalation / approval by Ryan
“Ryan is not doing every task. He is functioning as the business’s exception-management layer.”

Review findings

Owner dependency and visibility

SR-F01Owner dependency

Owner is the exception-management system.

Routine work can usually proceed without Ryan. Exceptions often cannot.

01 · Observed in review

Fictional evidence · Exceptions that route to Ryan

  • Nonstandard pricing
  • Customer-save situations
  • Technician overtime

02 · What it indicates

“Decision authority and escalation thresholds are incomplete.”

03 · Assessment connection

Leadership & Key-Person Dependency75People, Roles & Accountability65

  1. Assessment signal

    Leadership & Key-Person Dependency 75 · People, Roles & Accountability 65

  2. Review evidence

    Pricing, customer, technician and schedule exceptions route to Ryan

  3. Root cause

    Decision authority and escalation thresholds are incomplete
SR-F02Visibility

Management visibility requires manual inspection.

There is no single exception-oriented management view.

01 · Observed in review

Fictional evidence · What Ryan checks

  • Field-service software
  • CRM information
  • Text messages

02 · What it indicates

Ryan monitors routine activity because the business does not reliably surface only what requires his attention.

03 · Assessment connection

Visibility & Resilience85
  • Field service
  • CRM
  • Phone
  • Accounting
Ryan
Assembles manually
  • Text / email
  • Office
  • Technicians
Visibility is assembled manually instead of delivered through an operating view.

Revenue flow & capacity

How a lead becomes service today

Intake · lead sources

  • Phone
  • Website
  • Google Business Profile
  • Referral
  • Repeat customer
  • Commercial inquiry

Entry varies by source — dashed paths skip or reorder steps.

  1. Office receives inquiry
  2. CSR determines next step
  3. Estimate / Ryan involvement
  4. Manual follow-up
  5. Scheduling
  6. Service
HandlingOwner escalationConversion workflowDelivery

No single enforced lead-response standard.

SR-F03Revenue flow

Lead response varies by channel.

01 · Observed in review

Fictional evidence · Observed

  • Phone inquiries may receive immediate handling
  • Website inquiries may wait
  • Commercial opportunities are sometimes routed directly to Ryan

02 · What it indicates

03 · Assessment connection

Revenue Flow & Capacity90
SR-F04Revenue flow

Estimate follow-up is not consistently event-driven.

Some estimates receive calls, texts and emails. Others rely on employees remembering to follow up.

01 · Observed in review

Fictional evidence · Follow-up today

  • Phone calls
  • Texts
  • Emails

02 · What it indicates

“There is no consistently enforced follow-up workflow triggered by the status of the opportunity.”

03 · Assessment connection

Revenue Flow & Capacity90Processes & Knowledge70
SR-F05Capacity

Sales demand and operating capacity are not connected.

Marketing and sales activity are not consistently tied to:

01 · Observed in review

Fictional evidence · Not connected to

  • Technician availability
  • Geographic route density
  • Service type

02 · What it indicates

03 · Assessment connection

Revenue Flow & Capacity90

Today

  1. More leads
  2. More bookings
  3. More scheduling pressure
  4. More office coordination
  5. More exceptions
  6. More owner involvement

Target concept

  1. Growth
  2. Capacity visibility
  3. Controlled routing
  4. Defined exceptions
  5. Management by exception

“More sales should not automatically create proportionally more coordination and owner involvement.”

Knowledge & systems

Where operating knowledge and information live

SR-F06Knowledge

Critical operating knowledge remains informal.

01 · Observed in review

Fictional evidence · Handled from memory

  • Customer-save decisions
  • Reschedule priorities
  • Route exceptions

02 · What it indicates

03 · Assessment connection

Processes & Knowledge70

Today

  1. Experienced person
  2. Knows what to do
  1. Newer person
  2. Asks experienced person
  3. Possible escalation

Target principle

  1. Defined situation
  2. Operating rule
  3. Authorized role
  4. Escalation only when threshold is exceeded
SR-F07Systems

Summit has software, but the systems do not yet operate as one coordinated business system.

01 · Observed in review

Fictional evidence · Operating environment

  • Website
  • CRM
  • Phone

02 · What it indicates

The Review does not conclude that Summit lacks software. It identifies that information, decisions and workflow are not consistently orchestrated across the existing operating environment.

03 · Assessment connection

Systems & Integration65
  • Website
  • CRM
  • Phone
  • Field service
  • Accounting
  • Email / text
  • People
Manual handoff · Information is re-keyed, relayed by message, or carried by a person between tools.

“Don’t automate disconnected work. First create a system worth automating.”

“Requirements first. Products second.”

Root causes

Five connected root causes

  1. 01AuthorityIncomplete decision authorityRecurring decisions still escalate because thresholds and authority are not sufficiently explicit.SR-F01
  2. 02ExceptionsPeople-based exception handlingExceptions are managed through experienced individuals rather than consistent operating rules.SR-F01 · SR-F06
  3. 03VisibilityManual management visibilityLeadership must assemble operating information instead of receiving exception-oriented visibility.SR-F02
  4. 04WorkflowInconsistent revenue flowLead response, follow-up and opportunity movement vary across channels and people.SR-F03 · SR-F04 · SR-F05
  5. 05OrchestrationSystems are not yet orchestratedExisting tools support activities, but the end-to-end operating flow still depends heavily on human handoffs.SR-F07

Each cause compounds the next: unclear authority creates exceptions, exceptions demand visibility, and missing visibility keeps workflow and systems dependent on people.

Assessment → review traceability

From signal to root cause

Assessment scores pointed to where to look. The fictional review evidence below — not the scores alone — establishes the likely root causes.

  1. SR-F02

    1. Assessment

      Visibility & Resilience — 85

    2. Review evidence

      Ryan checks multiple systems and people

    3. Root cause

      No unified exception-oriented management view

  2. SR-F01

    1. Assessment

      Leadership & Key-Person Dependency — 75

    2. Review evidence

      Pricing, service, scheduling and customer exceptions escalate

    3. Root cause

      Decision authority and escalation thresholds are incomplete

  3. SR-F03 · F04 · F05

    1. Assessment

      Revenue Flow & Capacity — 90

    2. Review evidence

      Lead response and follow-up vary; capacity is disconnected from demand

    3. Root cause

      Revenue flow is not consistently orchestrated

  4. SR-F06

    1. Assessment

      Processes & Knowledge — 70

    2. Review evidence

      Experienced employees handle recurring exceptions from memory

    3. Root cause

      Operating knowledge remains informal

  5. SR-F07

    1. Assessment

      Systems & Integration — 65

    2. Review evidence

      Information moves manually across multiple tools

    3. Root cause

      Systems support activities but not end-to-end orchestration

Systems review conclusion

Summit does not appear to have a fundamental people or demand problem. It has reached a level of complexity where informal coordination no longer scales efficiently.

Ryan remains embedded in the operating system because decision authority, exception handling, management visibility, and cross-system workflows have not evolved at the same pace as the business.

The opportunity is not simply to remove Ryan from work. It is to redesign how the work moves so fewer situations require him in the first place.

What needs to change

Four target-state themes

  1. 01

    Clarify authority

    Move recurring decisions from people-dependent escalation into defined roles, thresholds and operating rules.

  2. 02

    Create visibility

    Replace routine owner checking with exception-based management visibility.

  3. 03

    Standardize revenue flow

    Create one defined journey from inquiry through follow-up, booking, service and reporting.

  4. 04

    Orchestrate systems

    Connect the necessary people, processes, systems and automation around defined operating outcomes.

These themes bridge the Review and the Blueprint. Specific products are not selected at this stage.

Current → target operating direction

Current

Target

  • Owner-centeredRole-centered
  • Manual visibilityException visibility
  • Informal decisionsDefined authority
  • Variable lead flowStandardized revenue flow
  • Manual handoffsOrchestrated handoffs
  • Software islandsIntegrated operating system

Case study continues

The Review identifies the causes. The Blueprint defines what changes next.

The ZOPSYS Improvement Blueprint converts Summit’s Assessment signals and Systems Review findings into a prioritized target operating model and implementation roadmap.

See Summit’s Improvement Blueprint Back to Assessment Results