RoutineSmithQuote request intake checklist for a small service team.
Turn incomplete emails and forms into a reviewable request—without letting automation make commercial promises.
Check whether this request is ready for human review.
Mark only whether each fact is present. Do not enter customer details here. This checklist does not approve scope, price, availability, terms or a reply, and it does not connect to your inbox.
Human controls
Working checklist only; human review is still required.
QUOTE REQUEST INTAKE — WORKING CHECKLIST Requester and reply path identified: Not checked Requested service or outcome captured in the requester’s words: Not checked Service location or remote-delivery condition known: Not checked Relevant scope facts and constraints present: Not checked Requested timing recorded as a request, not a promise: Not checked Relevant files, links or earlier reference associated with one case: Not checked One accountable owner and canonical request ID recorded externally: Not checked Possible duplicate: Not checked Conflicting or uncertain facts: Not checked Duplicate search completed: Not checked Human reviewer named: Not checked Working status: Checklist incomplete Boundary: This is not approval to quote or send.
Accountable owner: ____________________
Canonical request ID: ____________________
Require facts that make review possible—not a false promise of certainty.
Adapt the field names to the service, then write an observable acceptance rule for each one. Keep the requester’s words and source files attached to the canonical case.
| Area | Capture | Complete enough when |
|---|---|---|
| Contact | Name, reply address and preferred contact method | A person can reach the requester |
| Service | Requested service or outcome in the requester’s own words | The team can identify the service family |
| Location | Service address, area or remote-delivery requirement | Coverage and travel can be reviewed |
| Scope | Quantity, dimensions, assets, symptoms or other job-specific facts | Known facts are separated from assumptions |
| Timing | Requested date or decision deadline | It is recorded as a request, not a promise |
| Evidence | Relevant photos, files, links or earlier reference number | Attachments are accessible and associated with one case |
| Ownership | One accountable team member and one canonical request ID | No parallel quote is being prepared |
Give every active request one owner and one visible state.
The shared address is not the owner. A named person is accountable until a recorded handoff occurs. Keep lifecycle state separate from urgency or service category.
| State | Meaning | Next controlled action |
|---|---|---|
| NEW | Request received; ownership and completeness have not been checked | Assign one owner and search for an existing active request |
| MISSING INFO | One or more required facts are absent or ambiguous | Human approves a concise request for the missing facts |
| READY FOR REVIEW | Required facts are present and sources are linked | A qualified person reviews scope, price, availability and terms |
| WAITING | The team is waiting for the requester or an internal specialist | Keep the same owner and record the next review time |
| CLOSED · DUPLICATE | A person confirmed that this is the same request as an active case | Link it to the canonical ID; do not create another quote |
Let AI prepare evidence. Keep commercial decisions with people.
Extract explicitly stated facts, classify a service family, flag missing or conflicting fields, summarize compatible attachments that the team has authorized the system to access, and draft a missing-information checklist.
Scope, price, discount, availability, deadline, contractual terms, exceptions, duplicate confirmation and the final message sent to the requester.
Stop automated processing when intent is uncertain, evidence conflicts, a request may be urgent or sensitive, or an output would create a commitment. This human-review boundary applies the risk-management principle of documented roles described in the NIST AI Risk Management Framework.
Northstar Field Services receives an incomplete request.
A requester asks for a repair “next week” and attaches two photos, but provides no service address or equipment model.
The workflow creates QR-1042, records the known facts, flags two missing fields and assigns Maya as the single owner.
AI prepares a two-item clarification draft. Maya checks it and sends it from the canonical conversation.
The requester supplies the missing facts. Maya moves the case to READY FOR REVIEW; a qualified estimator—not AI—decides scope, price and availability.
Map the operating rule onto the software you already use.
- Google Groups: Google documents how to make a group a Collaborative Inbox and how members can use a group as a Collaborative Inbox.
- Microsoft 365: Microsoft explains how a team can open and use a shared mailbox; configure sent-item visibility deliberately so the team can verify replies.
- Help-desk or CRM: use one canonical request ID, one current owner and a visible audit trail. Product features do not replace the operating rule.
Check the current administrator documentation and test with synthetic requests before connecting a live mailbox.
Measure whether control improved without creating hidden work.
Record a representative baseline first. During the test, use synthetic or appropriately protected messages and keep a daily exception log.
- GO: observed control or quality improves versus baseline, reviewers can manage exceptions, and hidden work does not erase the gain.
- REVISE: the route is useful but specific fields, thresholds or responsibilities remain unclear.
- STOP: unsafe outputs, ownership gaps or review burden cannot be contained with the current design.
Seven days is an initial evidence window, not proof of ROI or a universal benchmark.
Avoid the shortcuts that make a queue look cleaner while risk moves elsewhere.
- Creating a new case for every channel without a duplicate check.
- Treating missing information as permission to infer facts.
- Using “assigned to team” instead of one accountable owner.
- Measuring faster acknowledgments while ignoring correction and escalation time.
- Allowing a generated draft to send prices, dates or terms without approval.
Practical questions before you connect automation.
What makes a quote request complete enough?
It is complete enough when the team can identify the requester, service, location, known scope, requested timing and relevant evidence, and when one owner can route it to a qualified reviewer. Complete enough does not mean approved or priced.
Can AI decide the price?
Not in this starter workflow. AI may extract stated facts, highlight missing information and prepare a checklist. A qualified person retains decisions about scope, price, discount, availability, deadline, terms and the final send.
Should every form submission create a new quote?
No. Search active requests first. If the sender, address, thread, reference or job facts suggest a match, route it to a duplicate check and let a person confirm before closing or merging anything.
What if a customer provides uncertain or conflicting details?
Preserve the original message, mark the conflicting fields and request clarification. Do not ask AI to resolve uncertainty by guessing.
How long should the pilot run?
Seven days can expose ownership gaps and exception patterns, but it does not prove ROI. Compare a representative baseline and pilot period, then continue, revise or stop based on observed quality, review effort and operational risk.
Add a supervised triage layer after the intake checklist.
The private planner drafts general routing outputs, human approval boundaries and stop conditions. Keep the quote-specific fields, ownership and duplicate controls from this checklist in your operating record; the planner does not transfer them or connect to your inbox.
Draft the general triage layer