A case study is not your only way to help a buyer assess what you offer. Before you have permissioned customer outcomes, you can explain the process, illustrate the intended workflow or demonstrate a functioning system. Any expected result should remain a hypothesis rather than being presented as evidence.
The important boundary is simple: a functioning-system test can show that the tested mechanics connect under the demonstrated conditions. It cannot prove that the system will increase a buyer’s revenue.
That boundary should shape what you publish. Choose the form of proof that answers the buyer’s immediate uncertainty, then state precisely what remains unknown.
Start with the question your proof needs to answer
A buyer may be wondering:
- Is this designed for a business like mine?
- What information or effort will I need to supply?
- What will actually change in the way work gets done?
- Can I see the system operating before I commit?
- Is there evidence of a measured outcome?
These are different questions. One testimonial, screenshot or process diagram cannot answer all of them.
Scale Manual’s reviewed proof material separates five useful subjects: the customer’s starting point, fit, required effort, process change and the result observed in a stated context. This changes the decision from “Do we have a case study?” to “Which uncertainty can we honestly reduce?”
Use this evidence ladder
| Evidence level | What you can show | What it can establish | What it cannot establish |
|---|---|---|---|
| 1. Clear explanation | Inputs, steps, responsibilities and boundaries | You can describe the proposed work coherently | That the process operates in practice |
| 2. Representative walkthrough | A hypothetical or model workflow traced from start to finish | The intended sequence is understandable and its assumptions can be examined | That a production system operates as shown |
| 3. Functioning-system test | A working implementation tested from start to finish | The tested mechanics connect under the demonstrated conditions | That the system will produce a commercial outcome |
| 4. Documented implementation | Records showing what was built or changed, with appropriate permission | The work was implemented in a stated context | That the change caused an outcome |
| 5. Measured outcome | Baseline, comparison, method, time window and relevant context | What changed under the recorded conditions | That every future buyer will get the same result |
Move only as high as your evidence allows. A precise walkthrough or functioning-system test is more useful than a vague claim made to resemble measured outcome evidence.
What a useful walkthrough or demonstration looks like
Imagine that you are presenting an enquiry-handling system for a service business. A representative walkthrough could trace this hypothetical path:
Enquiry submitted → notification created → named owner alerted → response recorded → booking status updated
A visible lead path can help identify a stopped handoff instead of leaving follow-up to memory or improvisation.
In a representative walkthrough, you could explain:
- where a sample enquiry would enter;
- where its details would be stored;
- who should receive the notification;
- how ownership would be assigned;
- what should happen when the person books;
- what should happen when they do not book; and
- where the final status should be checked.
That walkthrough illustrates the intended sequence and may reveal design gaps, such as three inboxes receiving an enquiry while nobody is assigned the next action. It does not establish that a production system operates correctly.
If you also have a functioning implementation, run a test enquiry through it and record what actually happens. That test can establish that the observed steps connected under the test conditions. It still does not establish that the workflow increases bookings, reduces response time or raises revenue. A process demonstration can support understanding of how a system operates without proving that it improves revenue.
Record evidence before turning it into a claim
Before publishing an outcome claim, create a short evidence record. Include:
- the source or customer;
- permission to use the material;
- the starting baseline and comparison;
- what was measured and how;
- the relevant time window;
- the context that could affect interpretation; and
- the exact public wording permitted.
These fields are part of Scale Manual’s reviewed claim-record approach. Use them to reduce the risk of turning a genuine observation into a broader promise during editing.
For example, “The notification reached the assigned inbox during our demonstration” is a narrow, observable statement. “This system stops leads being lost” is much broader. The second statement would need evidence covering real use, exceptions and a defined period—not just one successful test.
A quick decision aid before you publish
Use these four questions:
- What buyer uncertainty are we trying to reduce? Name one: fit, effort, intended mechanics, tested operation, implementation or outcome.
- What did we actually observe? Separate an explanation, a representative walkthrough, a functioning-system test and a measured result.
- What is the narrowest accurate claim? Remove implied guarantees and unsupported cause-and-effect.
- What would someone need to verify the claim? Keep the source, permission, method, period and context with the record.
If you can only illustrate the proposed sequence, call it a representative walkthrough. If you test a functioning system, describe the conditions and observed mechanics. If you have a sensible expectation but no observation, label it as a hypothesis. If you have measured results and permission, state the relevant conditions instead of presenting them as universal.
Narrow, well-documented proof can be more useful than a broad claim because the buyer can see what it establishes and what remains uncertain.
I have spent thousands of hours studying marketing; my aim is to turn that learning into practical steps you can use. If you want to build and operate your own lead system, or explore help building a system you control, a fit conversation is a sensible next step.
