Before the examples
A vendor says: “The demo shows a success banner, so the lead is safely in the CRM.” Without reading the answers, write the evidence you would require before approving the work.
Copy your answer before proceeding. A useful requirement names a trigger, an observable destination state and a pass/fail rule. Later, try the new booking scenario without consulting the answers.
Synthetic case · persistence
A green response, an empty CRM
Fictional proposal excerpt
Every accepted web enquiry will be saved in the CRM. The demonstration returns success and displays the lead name.
Synthetic run P-01. The CRM snapshot is a complete query of the test workspace for source enquiry E-101, taken after the worker queue is empty. It is not a screenshot of a filtered sales dashboard.
| Row | Time | Source | Object | Observation |
|---|---|---|---|---|
| P1 | 09:00:00 | webhook | E-101 | HTTP 200; accepted=true |
| P2 | 09:00:01 | worker | E-101 | CRM write rejected: required owner missing |
| P3 | 09:00:02 | queue | E-101 | empty; no scheduled retry |
| P4 | 09:05:00 | CRM query | E-101 | matching persisted records=0 |
Download matching CSV evidence
Reviewer worksheet
Your entries stay only in this page. Nothing is submitted or saved automatically. Copy them elsewhere before closing or reloading.
Compare with the explained answer
What the evidence shows
Acceptance of the request was mistaken for durable completion. The complete destination query shows no persisted lead after the queue drained.
A revised observable acceptance condition
For test enquiry E-101, submit once with a valid owner. Within 60 seconds, a fresh CRM query by source enquiry ID must return exactly one persisted record with the expected name and owner. Repeat the query after worker restart. With owner missing, report a failed write, never a completed CRM save, and retain a visible recovery item.
Do not overclaim
This shows one failed save, not that every request fails. A successful HTTP response alone cannot prove storage. A timestamp without a destination record is insufficient.
Synthetic case · transfer
Try a new handoff: the booking calendar
Fictional proposal excerpt
Every confirmed appointment appears once in the shared calendar, including when the calendar service is briefly unavailable.
Unseen transfer exercise. Synthetic run T-01 uses booking B-404. The calendar snapshot is a complete query for that booking after the queue drained. Write your answer before opening the separate answer key.
| Row | Time | Source | Object | Observation |
|---|---|---|---|---|
| T1 | 12:00:00 | booking UI | B-404 | confirmed |
| T2 | 12:00:01 | calendar API | B-404 | 503 unavailable; no event created |
| T3 | 12:00:02 | queue | B-404 | empty; retry job absent |
| T4 | 12:05:00 | calendar query | B-404 | matching events=0 |
Download matching CSV evidence
Reviewer worksheet
Your entries stay only in this page. Nothing is submitted or saved automatically. Copy them elsewhere before closing or reloading.
Share an exercise response
Free sample: one worked CRM case, one booking-calendar transfer exercise, two matching CSV files and a separate answer key. Use the baseline and transfer answers to check whether you can write a more observable approval condition; improvement has not been measured with real users.
Proposed full guide: $9 USD, enquiry only. It includes three worked cases, matching CSV evidence, worksheets and a plain-text answer key. Orders and payment are closed pending seller, payment and delivery verification.
Optional feedback: send your baseline answer, transfer answer, whether the worked case helped, and whether you want the proposed $9 pack. Do not send real proposals, customer data or credentials.
Selectable address: moxie@staticterminal.com
Subject: Automation proposal exercise
Include: baseline; transfer; usefulness; $9 pack interest (yes/no); optional minutes spent.
No form submission or automatic data collection. Email feedback is optional; any email you choose to send reaches our business mailbox for manual review. Omit identifying business details.