Evidence status for this model
The evidence status is explicit:
- Observed: the filings and guidance make named categories and practices visible.
- Representative and untested: the five-layer model, ledger, example, and stop rule are editorial tools.
- Unknown: exception frequency, human effort, buyer outcomes, margin, and defensibility for any real service.
Five layers to separate
| Layer | Question before automation | Keep a human in the loop when |
|---|---|---|
| Judgment | Which input changes the decision? | Inputs are ambiguous or policy is disputed |
| Transformation | Can the same rule produce a checkable result? | There is no invariant or negative case |
| Accountability | Who accepts the consequence? | No owner can approve, reject, or reverse it |
| Exception handling | What happens outside the normal path? | Exceptions are frequent or materially different |
| Trust and demand | Why would another buyer rely on this? | The value depends on context the system cannot observe |
The model is deliberately stricter than “a human currently performs this step.” It is a worksheet for gathering evidence, not a source-backed universal productization rule. Human performance can be evidence, but it is not proof that the step is safe to remove.
What the filings show—and what they do not
ServiceNow's 2025 Form 10-K reports subscription revenue separately from professional services and other revenue. It describes customer support, professional services, adoption, implementation, architecture, and optimization work around its platform. GitLab's fiscal-2026 filing likewise describes hosting, customer support, professional services, and customer-success work alongside subscription revenue.
Those descriptions support a narrow observation: a commercial software operation can contain more work than producing an initial feature. They do not show that the work is a moat, that it is profitable, or that AI changed its cost. A revenue category is not a value map.
NIST's Secure Software Development Framework provides a vocabulary for secure development practices, and Google SRE's toil guidance makes recurring manual operational work visible. Neither document supplies a small company's staffing plan or a productization threshold.
Use a per-step evidence ledger
Copy one row for every candidate service step. Do not use one row to summarize an entire service.
| Candidate step | Layer | Observed input or rule | Negative or exception case | Evidence state | Failure and recovery owner | Buyer outcome | Human-effort pattern | Decision |
|---|---|---|---|---|---|---|---|---|
| Replace with one step | Judgment, transformation, accountability, exception, or trust | What was actually observed | What breaks the normal path | observed, representative, or unknown | Named person and recovery action | What the buyer can observe | discovery, linear burden, reusable asset, or unknown | human, assisted, or software |
If a material field is blank, this worksheet should leave the step human or assisted while the team gathers evidence. That is a boundary for using this model, not proof that every service must follow the same threshold.
The human-effort field keeps an investor from confusing expensive work with strategically valuable work. Declining effort, linear per-customer effort, a reusable asset, and an observable buyer outcome imply different questions. None is a moat or economics conclusion without operating and buyer evidence.
Counterexample: automate a reversible transformation
Consider a synthetic appointment-intake service. A customer enters a requested date and location in free text. Software can normalize the date format, preserve the original request, flag impossible dates, and place the result in a review queue. A service operator still decides availability, resolves ambiguity, and owns the customer promise.
This case challenges an all-or-nothing reading of the ledger: a bounded, reversible transformation can become software-assisted before demand or service economics are known. If the original request cannot be retained, the normalization changes the customer promise, or exceptions bypass review, the example no longer supports that boundary.
A productization stop rule
For this worksheet, do not mark a consequential step software until a
reviewer can answer yes to all of these questions:
- The normal input and output are bounded.
- Negative and exceptional paths are named.
- A person owns the consequential decision.
- Evidence is retained at the point of completion.
- Recovery is possible or the irreversibility is explicit.
- A buyer outcome—not merely a faster implementation—is observable.
Use the cheaper implementation and accountable operation analysis to separate cost categories from value claims. Compare the boundary with cheap code and vertical SaaS moats and the feature-to-product threshold.
This model remains a hypothesis until first-hand service and buyer evidence replaces its representative rows. It does not by itself establish market size, margin, value migration, or defensibility.