# Starting brief: customer enquiry to approved quote Status: illustrative sample, not a client specification or validated recommendation. Version: 0.1 ยท 13 September 2026 ## Purpose and boundary Help a small service business prepare consistent quotes without repeatedly copying information between email, documents and spreadsheets. Start: an operator receives a customer request. End: the approved quote is delivered and the shared record contains the version, approver and delivery result. This first version covers one service catalogue, one currency and one operator role. Confirm these assumptions before implementation. Contract acceptance, payments, scheduling, procurement and accounting are outside this slice. ## First version Build a manual path before adding AI: 1. Paste an anonymised request or enter it through an intake form. 2. Create a shared request record, preserving the original text. 3. Enter structured needs and select catalogue items manually. 4. Check required fields and calculate the quote from a versioned catalogue. 5. Review and approve a specific quote revision. 6. Generate a PDF and stage an email. In development, route delivery to a test inbox. 7. Record delivery success or failure, then expose a safe retry action. Once that path works, add AI-assisted extraction into the same editable fields. It should reduce entry work without becoming a prerequisite for creating a quote. ## Entry points and interfaces - Intake: a small form with source text, customer contact and optional reference. Manual email paste avoids mailbox integration in the first version. - Work queue: reference, status, owner, last change and missing information. - Request detail: original source beside editable extracted facts, catalogue selections and quote preview. - Review: price breakdown, scope, exclusions, outstanding questions and the exact revision being approved. - Delivery: approved PDF preview, recipient confirmation and explicit send action. - Administration: catalogue version, item price and availability. Who can change these is an open question. ## Process responsibilities AI extracts candidate facts from variable text. Its output includes source excerpts for each supported claim and an explicit unknown for missing facts. Extraction failure leaves manual entry available. It does not set prices, make commercial promises or send messages. Code validates required fields, calculates from the approved catalogue, tracks revisions, invalidates approval after a change and enforces the delivery state. It records events so a person can understand what happened. A person resolves ambiguity, chooses the offering, checks scope and approves the customer promise. Clarification messages are reviewed before sending. AI used during development is separate from AI used in the running product. A coding assistant may help build validation and pricing; those steps execute as ordinary code. ## Minimal shared record - Request: ID, original source, contact, owner, state, timestamps. - Draft facts: field values, source references, unresolved questions, manual edits. - Quote revision: selected catalogue version, lines, quantities, currency, totals, scope, exclusions. - Approval: quote revision, approving person, timestamp. - Delivery: revision, recipient, PDF reference, idempotency key, attempt state, provider reference if available. - Events: actor, action, time, previous/new state and relevant revision. Store business facts with the request. Keep development decisions in project documentation. Avoid copying customer content into general assistant memory. ## Delivery and exceptions The UI sends an explicit command for the approved revision. The server verifies approval, records a delivery attempt and sends the matching PDF through an email adapter. If details are missing, the request enters `awaiting_clarification`. It returns to validation after the answer has been incorporated. If the quote changes, it returns to `draft` and needs a new approval. A duplicate send command does not create a second customer email. An uncertain provider response remains `delivery_unknown` until reconciled; blind retry is not the default. Failed AI extraction is a recoverable draft warning. Delivery failure remains visible to the owner and does not mark the request completed. ## Acceptance checks 1. A request can move from intake to a delivered quote without any AI call. 2. Unsupported extracted facts remain unknown and can be corrected manually. 3. Missing required details prevent approval and point to the fields to resolve. 4. A catalogue change does not silently alter an existing quote revision. 5. Editing an approved quote invalidates that approval. 6. Sending an unapproved or stale revision is rejected on the server. 7. Repeating the same delivery command cannot send a duplicate quote. 8. A failed delivery remains visible and can be retried or reconciled without losing the approval history. 9. Another authorised operator can see the source, current state, decisions and next action. ## Questions to settle with the owner - Which fields are required for a defensible quote? - Who maintains the price catalogue and who may approve exceptions? - Is more than one currency, tax treatment or language needed? - What data can be sent to an external AI provider, and under which retention settings? - Which existing system is the source of customer and product information? - Who receives failed delivery alerts and handles clarification? - Is one user role sufficient for the first version? These are unknowns, not assumptions to hide in implementation. Tax amounts and wording need an approved source; this sample does not define them. ## Foundational development prompt Read `process.bpmn`, this brief and `handoff.md`. Treat them as an illustrative starting specification that needs the owner's confirmation. First identify the unknowns that block a first build. Separate questions that affect the core data model from details that can be configured later. Inspect the existing repository and follow its architecture and design conventions. Implement the manual intake-to-approval path first using synthetic data. Show the source text, structured fields and quote revision together. Keep pricing deterministic and make approval specific to a revision. Add a test delivery adapter so the first demonstration sends no real customer messages. Validate the acceptance checks for the implemented slice. Report what works, what remains unimplemented and which assumptions you made. Then propose the smallest addition for AI extraction, preserving manual entry and the human approval boundary. Before handing work over, update the continuation record using `handoff.md`. Link to files and checks that support the claims. Do not claim the sample process has been validated with a customer.