Bring Five Test Cases to Your Dispatch Software Demo
By STEADYWRK Team
A useful dispatch demonstration starts with a request that your team would recognize and an outcome you can inspect. Before the call, write down what should happen when information is missing, someone changes a booking, or two people act on the same request. A smooth prepared example cannot answer those questions by itself.
The five cases below are synthetic exercises, not STEADYWRK customer records or a promise that any particular product supports the behavior. Use them to ask what the product does today, what needs configuration and what remains a manual step. Download the CSV worksheet, open a copy, and replace the fictional site names with neutral labels for your own workflow.
Define the boundary before the call
Choose one workflow: for example, receiving a maintenance request and handing it to the person who can schedule a visit. Keep quoting, approval, assignment and completion as separate events. A request arriving does not mean a visit is booked; a quote being prepared does not mean a customer accepted it.
Write a short starting record:
| Field | Synthetic example |
|---|---|
| Request ID | DEMO-101 |
| Site | Site A |
| Reported problem | A light is not working in the meeting room |
| Requested window | Morning; exact date still missing |
| Approval | Not yet requested |
| Assignment | Unassigned |
The missing date is intentional. Ask the demonstrator to preserve that uncertainty. If a default date appears, establish whether it is a suggestion, a stored value or a confirmed booking. Record the answer using the product's actual labels.
Case 1: required information is missing
Try to continue without the visit date or a usable site reference. Look for a clear explanation of what is missing and a way to save or recover the unfinished request. Then supply the missing information and try again.
Your evidence should show both attempts. A blocked first attempt may be correct behavior. A successful second attempt should retain the details you already entered. Ask who is responsible for obtaining the missing information if the request arrives outside working hours; a software field does not establish that responsibility.
Case 2: the same request arrives twice
Present DEMO-101 again as though a caller repeated the message. Ask how a person would identify and resolve the possible duplicate. Do not assume a system should silently discard it: the second message could contain a correction or describe another problem at the same site.
Inspect which record remains active, where the second message is kept and whether an assignment or notification was created twice. If duplicate detection is unavailable, record the manual procedure rather than marking the case as passed because the screen looked tidy.
Case 3: the requester cancels before assignment
Cancel a request that has not been assigned. Check the visible state, the reason and the next person's view. Then ask what would happen if the cancellation arrived after a technician had accepted the work.
Keep those two cases separate. A status label changing to “cancelled” does not prove that an already sent message was recalled, a calendar entry was removed or a charge was reversed. Only mark the effects actually shown. Ask the owner of any external system to confirm its part in a later controlled test.
Case 4: two people edit the same request
If the demo supports separate sessions, open one request in each. Change the visit window in the first session, then attempt an edit from the older second view. Observe whether the second user sees the new value, receives a conflict warning or overwrites it.
Explain the rule your team needs before judging the result. Some edits can coexist; competing changes to the same appointment time need an explicit resolution. If separate sessions are unavailable, mark this case not tested and ask for a follow-up demonstration.
Case 5: a colleague takes over
Hand the request to someone who did not see the original conversation. Ask them to state the site, reported problem, next action, owner and unresolved question using only the record. Compare their answer with the starting information.
This exposes gaps that a feature list misses. A long activity log may still leave the next action unclear. Conversely, a short summary may be adequate if it preserves the source details and points to the person responsible for the next decision.
Finish with a decision record
For each case, record the observed result, evidence reference and one of shown, failed, not tested or follow-up needed. Keep a separate column for whether the result meets your requirement. A behavior can be demonstrated accurately and still be unsuitable for your workflow.
Use the worksheet to decide which questions deserve a deeper trial. It is not a production acceptance test, a migration plan or a safety procedure. For STEADYWRK, start with the published Dispatch Engine scope, compare the current offers, and bring the unresolved cases to a demo. You can share the worksheet without including customer names, addresses or live work orders.