# First SaaS customers: research and evaluation workbook

Use one copy for one audience hypothesis. Keep sensitive conversation notes in an appropriately restricted workspace. This workbook contains blank fields and a fictional example, not actual customer results.

## 1. State the uncertainty

- Owner:
- Review date:
- Starting audience:
- Problem hypothesis:
- Evidence already available:
- Most important unknown:
- Decision this work should inform:
- What would change our current view:

Choose the appropriate next step: research conversation, design partnership, product evaluation, or purchase discussion. Do not count these as interchangeable commitments.

## 2. Research candidates

Use one row per candidate. A public signal indicates possible relevance, not proven purchasing intent.

| Candidate reference | Observation and source date | Possible relevance | Unknown or disqualifier | Appropriate next step | Status |
|---|---|---|---|---|---|
| Fill in | Fill in | Fill in | Fill in | Fill in | Fill in |

Record only the information you need. Respect the setting's rules and a person's request to stop.

## 3. Prepare the invitation

- Relationship or legitimate context for the request:
- Specific observation, if verified:
- What we want to understand or evaluate:
- Concrete request and expected effort:
- Real resource or help we can offer:
- Terms if this is a product evaluation:

Do not disguise a sales request as research. Use a relevant, truthful invitation rather than a reusable claim about someone else's pain.

## 4. Record a conversation

- Role in the workflow:
- Last occurrence of the problem:
- Trigger and consequences:
- Steps taken and current alternative:
- Who participates and who approves changes:
- Attempts already made:
- Exact observations:
- Our interpretations, recorded separately:
- Evidence that contradicts our hypothesis:
- Agreed next step, owner, and date:

## 5. Agree on an evaluation

| Field | Agreement |
|---|---|
| Customer result | Fill in |
| Eligibility and compatibility | Fill in |
| Scope and exclusions | Fill in |
| Customer contribution | Fill in |
| Our contribution and manual support | Fill in |
| Access and data expectations | Fill in |
| Payment or evaluation terms | Fill in |
| Observation window | Fill in |
| Success evidence | Fill in |
| End decision and participants | Fill in |

## 6. Review the result

- Did the customer reach the agreed result? Evidence:
- What support did we provide, and how much effort did it take?
- Did the customer return when the need recurred?
- Is there a commercial commitment? State exactly what it is:
- Unresolved obstacle:
- Decision: buy, stop, or extend a specifically defined test:
- Next change to our audience, product, or offer:
- Owner and review condition:

## Fictional completed evaluation brief

An engineer with recurring API test failures agrees to evaluate a supported integration. The intended result is investigating one failure and choosing a next action. The customer provides a suitable test environment; the product team assists with connection setup. Evaluation terms and access are agreed before the test. Both parties will review the investigation outcome and support effort before deciding whether to continue. No evaluation outcome is assumed in this example.


---
Original resource by Jon Bishop. CC BY 4.0. Illustrative examples are not customer results.