Start with the work
Describe a real item moving through the current workflow. Name the starting signal, person or organization served and outcome that would make the item complete. Use an example from normal work and one from an exception.
Build the working checklist
- Write one primary job and the current bottleneck.
- List the fields required, where they come from and who maintains them.
- Name the owner, handoff, exception and stop condition.
- Separate required capabilities from attractive extras.
Check it against a real task
Use the same sample with every candidate. Ask the provider to demonstrate the exception as well as the normal path. A checklist of feature names cannot establish how the work will behave.
What to take away
Finish with a measurable pilot and an exit plan. If the current system can meet the requirement, record that finding before introducing a purchase.
A one-page brief you can actually compare
Scroll horizontally to read all columns.
| Field | What to write | Example for a social enquiry |
|---|---|---|
| Job | One task with a clear end state | Deliver the requested sizing guide or hand over a fit question |
| Starting item | The event and its context | A relevant social comment or message |
| Required record | Only the fields the owner needs | Source, request, response sent, owner and next action |
| Must work | An observable acceptance condition | An uncertain fit question reaches a named operator with context |
| Must stop | A failure or boundary that blocks expansion | A stop request still receives a later automated step |
| Constraints | Channel, region, access, budget and implementation limits | Account eligibility and transfer method still need checking |
Turn a vague requirement into a test
“Improve customer engagement” is too broad to compare software. A useful replacement is: “Given a request for our sizing guide, deliver that guide once, retain the source and route an uncertain fit question to the operator.” The test uses a normal request, a duplicate and an exception. It can be tried with saved answers in the existing inbox before any purchase.
Decide what is optional
Separate the outcome from the mechanism. A handoff can initially use a reviewed manual record; it does not automatically need an API. An attractive dashboard is optional unless it resolves a measured operating problem. Take the same brief to each vendor so a polished demonstration cannot silently change the task being evaluated.
Working files
Blank templates for your own planning. These contain no customer records and are not submitted to Sales Fit Lab.
A fillable task, fields, acceptance test, constraints and decision record.