A reusable template for non-technical teams to document an AI or automation workflow before handing it off for technical discovery. Filling this out replaces open-ended discovery interviews with a clear operating picture, so builders can focus on integration and implementation rather than basic process comprehension.
Operators, legal, finance, people ops, and other non-technical teams who own a workflow and want to hand it to an engineering, automation, or AI team for scoping and build. The template is also useful for vendor onboarding and internal build requests.
Best fits:
- Legal operations: intake, routing, drafting, filing, records
- People Ops: onboarding, offboarding, benefits, personnel files
- Finance and grants: payments, budget review, invoices, approvals
- Compliance and diligence: KYC, vendor review, document-heavy processes
- Any cross-functional workflow where operators know the process better than the builders
- Start with the current manual process. Do not describe the ideal future state first. Builders need to understand what actually happens today.
- Name the source of truth. If multiple trackers or folders exist, say which one wins and when.
- List human approval gates. Mark which steps can be automated, which can be AI-drafted, and which must remain human decisions.
- Document exceptions. Edge cases are where builds typically fail. Include real examples.
- Remove or anonymize sensitive data before sharing broadly. The blank template is public; completed packets may not be.
- End with completion criteria. Define what must be in place before technical discovery begins.
| Status | Meaning |
|---|---|
| Draft | Still collecting process details |
| Ready for operator review | Complete enough for process owners to verify |
| Ready for technical discovery | Process owner has confirmed the packet |
| Submitted | Sent to technical partner or vendor |
| Needs clarification | Partner has follow-up questions |
The template is organized into seven parts:
Part 1 — Packet summary Project overview, business owner, operational DRI, technical partner, pain point, desired outcome, and explicit out-of-scope constraints. Includes a pre-discovery completion checklist.
Part 2 — Current-state workflow map Trigger and intake description, step-by-step manual process table (with automatable flag per step), decision points, and handoffs/approvals.
Part 3 — Source materials and systems Source-of-truth inventory, data quality assessment, document/data library index, template library, and access and permissions.
Part 4 — Automation design boundaries Explicit lists of what the system may and may not do, human review gates, and privacy/data-handling rules.
Part 5 — Edge cases and failure modes Edge case log with examples and current handling, plus failure mode table with safe fallbacks.
Part 6 — Build requirements and acceptance criteria Functional requirements, audit trail requirements, success metrics, and a prepared list of technical discovery questions.
Part 7 — Maintenance and change management Operational first responder, review cadence, people/transition plan, and a final readiness checklist.
Appendix — AI prompts for packet drafting Four ready-to-use prompts for using an AI assistant to extract a workflow map, identify source-of-truth conflicts, build an edge case log, and define a safe V1 scope.
Open the Google Doc template and work through the parts in order. Each section includes inline guidance and example language. Replace all [bracketed placeholders] with your workflow's specifics.
The packet is ready for technical discovery when:
- The current manual workflow is documented step by step
- Sources of truth are named and any conflicts are noted
- All human approval gates are identified
- Sensitive data boundaries are described
- At least three to five edge cases are logged with examples
- Success metrics are defined
- The process owner has reviewed and confirmed the packet
This template is released under Creative Commons Attribution 4.0 International (CC BY 4.0). You are free to use, adapt, and redistribute it for any purpose with attribution.
Found a gap, a missing section, or a better way to phrase something? Open an issue or submit a pull request. Improvements from teams who have filled this out for real workflows are especially welcome.