Compare the operating models
In this fictional example, Repair intake repeatedly needs device, site and reported problem. A new project brief may need discussion, drawings and unusual constraints. One exhaustive form would burden the project; unstructured repair email repeatedly omits essential context.
| Business requirement | Short structured intake | Flexible email/brief |
|---|---|---|
| Repeat repair | Device/site/problem plus notes | Staff must extract missing fields |
| Negotiated project | Only stable essential questions | Narrative and attachments |
| Human review | Structured is not verified | Narrative is not automatically unusable |
Work through the chosen model
Repair form stores a known device/site link where available, reported issue and contact, with optional narrative. Project intake retains original brief/attachments and agreed extracted facts. Preserve the source request; a filled field or AI extraction is not itself acceptance of scope.
- Select repeat task or exploratory brief
- Collect just the required context
- Review and create matching work record
Forms reduce repeated omissions but can force poor answers if overdesigned. Email supports nuance but needs extraction/review.
A repair creates a case with device/site/issue. A project creates a brief retaining drawings and unresolved questions, not a fabricated complete specification.
When the other model fits
Repair requires unusual evidence that the form cannot capture. Reject the request?
Show the worked answer
No. Allow notes/attachments or a staff-assisted route, then review the actual request.