This is a sample document using fictional business data.
Inquiry pilot: scope and acceptance
Prepared for an example service business. Version 1. The written scope defines dates, account access and commercial terms before work starts.
1. Purpose and boundaries
Capture an incoming service request once, check the required information, create a record and prepare an editable first reply for a named person to review.
The pilot covers one intake source, one agreed destination and one human review step. It does not send a reply without approval.
2. Input map and required fields
- Source and trigger
- One website inquiry form. A valid submission starts the workflow.
- Required input
- A unique request ID, contact name, valid email, requested task and tools involved. The agreed source supplies the request ID.
- Optional input
- Company and expected request volume. Other fields require an agreed reason and retention rule.
- Destination
- One inquiry tracker with an agreed field map and access owner.
- Output
- One traceable record with input reference, required details, owner, status, timestamps, missing information and a reply draft.
Fictional acceptance input: request INQ-EXAMPLE-001; contact Example Contact; email contact@example.invalid; task “Route website inquiries to a reviewer”; tools “Website form and inquiry tracker”.
Credentials, confidential records and sensitive personal information are not part of the test input.
3. Owners and approval points
- The client names an intake owner, a reviewer and a backup reviewer.
- I implement the agreed workflow and provide the acceptance record and handover notes.
- The reviewer checks the record and edits the reply before approval. An edit requires another review.
- Sending, account changes and financial actions need separately agreed permissions. This starting scope does not include unattended sending.
4. Deliverables
- An input map showing required fields, field ownership and review points.
- One intake-to-record workflow with validation, duplicate handling and a visible failure state.
- An editable reply draft with an explicit human approval step.
- Results for the acceptance checks below, including failures and recovery.
- Source or workflow access, operating notes and a handover walkthrough.
5. Exclusions and dependencies
Bulk outreach, extra intake channels or integrations, historic data migration, OCR, ongoing monitoring, tool subscriptions and performance guarantees are outside this starting scope.
The client supplies authorized access, representative redacted inputs, an accountable reviewer and the required provider plans. Provider API access and quotas are checked before work is committed.
6. Acceptance tests
- Complete request
- Submit INQ-EXAMPLE-001 with every required field. Exactly one record contains the agreed mapped values. A reply draft is available for review. No reply is sent automatically.
- Incomplete request
- Remove the email or requested task. The missing field is visible to the operator. The workflow does not silently treat the request as complete or send a reply.
- Duplicate request
- Deliver the same request ID twice. The destination has one record and the second delivery is identifiable. A safe replay does not produce a second reply draft for sending.
- Failed request
- Simulate destination unavailability. The operator can identify the failed request and stage without exposing credentials. After recovery, an approved retry completes once without a duplicate.
- Approval reset
- Approve a draft, then edit it. The revised content requires review again.
The client reviewer checks the evidence against these agreed cases. New requirements are recorded as changes rather than added silently to acceptance.
7. Milestones
- Confirm the input map, access, reviewers and acceptance examples.
- Review the implemented workflow and failure paths.
- Run the agreed acceptance checks and record corrections.
- Accept the agreed scope and complete the handover.
8. Fees, costs and payment
Final fees depend on the agreed scope. Agree the fee, currency and payment terms in writing before work starts.
Hosting, model usage, databases, automation subscriptions, email and other provider costs are listed separately.
9. Changes and handover
Record a requested change, its reason and its effect on scope, acceptance checks, dates and price. I agree those effects in writing before implementing work outside the approved scope.
At handover, the client owns the business accounts and API keys. Record source or workflow access, the operating notes, acceptance results and the removal of project permissions.