Write a time-tracker requirements brief
Specify acceptance criteria before a sales demonstration.
Write requirements as observable outcomes, including a sample input and the file or screen that would prove success. Separate mandatory outcomes from preferences before comparing products.
Name the recipient and the decision
“The operations coordinator checks weekly project totals” is more useful than “we need reporting.” Specify who receives the record, how often, which people and projects it covers, and what happens when a record is unresolved. Identify the system receiving an export and whether it expects entries, daily totals or one total per person. Do not assume a CSV extension establishes compatibility.
Turn wishes into acceptance statements
Use a compact requirements table. Assign an owner who can accept the result and a test case with a known expected output. Mark missing evidence as unresolved rather than giving the feature half-credit.
Scroll horizontally to compare every column.
| Requirement | Evidence to request | Decision |
|---|---|---|
| Preserve contributor identity | Export two people with the same display name but different IDs | Mandatory if names are not unique |
| Explain a correction | Show original and revised value, actor and reason or a linked change record | Mandatory if recipient needs traceability |
| Use agreed units | Export 90 minutes and confirm recipient reads 1.5 hours | Mandatory |
| Attractive dashboard | Observe readability on the reviewer’s device | Preference unless a specific access need makes it mandatory |
Keep documented and demonstrated evidence separate
Product documentation can establish available formats or roles. It does not establish the behavior of your configured integration. Save the document URL and observation date alongside a separate pilot result. A sales claim without a reproducible example remains unresolved. Do not request demonstrations containing another customer’s identifiable records; a small fictional fixture is enough to test field semantics.
Make a go/no-go rule before the demo
A candidate passes only when every mandatory outcome is demonstrated and the cost is within the agreed ceiling. Preferences can break a tie between candidates that already pass. A low price or a strong dashboard cannot cancel a missing required field. Record an explicit no-purchase option: continue the current workflow, repair it, or delay the change until the missing requirement is resolved.
Continue this work-record check
Use the linked guide for the next decision in this workflow. Keep your original records separate from experiments and record any unresolved requirement before changing a live process.
Sources and boundaries
Primary documentation supports the dated product facts. Proposed checks and fictional examples are our editorial method, not observed product results.
- DeskTime — export · checked September 23, 2026
- Time Doctor — export · checked September 23, 2026