GTM and AI project scoping checklist
A useful project brief describes a business task, the systems involved and how you will know the work is complete. Before choosing tools or approving a budget, agree the boundaries below with the people who will use and operate the system. Use the prompts as a working document for a first scoping conversation.
Name the task and the bottleneck
Describe one complete unit of work. For acquisition, that could be researching an account and recording a reviewed outreach draft. For operations, it could be preparing a response from approved documents. Avoid starting with a tool list or a broad goal such as automate sales. Write down what triggers the work, who handles it today and where it waits.
- Task: what arrives, what happens and what must exist at the end?
- Baseline: how long does a typical task take, and how much review or rework does it need?
- Constraint: is the delay caused by data, decisions, access or capacity?
Draw the boundary of the first release
Choose a scope that can be tested from beginning to end. An acquisition pilot might cover one audience and one CRM destination. An internal assistant might prepare drafts for one team, while sending remains a human action. Identify exclusions explicitly. A system that drafts a proposal does not automatically have authority to approve pricing or commit to delivery dates.
- Included: which users, records, languages and integrations are covered?
- Excluded: which actions, channels and exceptional cases stay manual?
- Approvals: who may review, approve, pause and change the workflow?
Map data and access before promising automation
List the source of truth for each record and identify the person who can grant access. Check whether the necessary fields and interfaces actually exist. Decide how conflicting values will be resolved and how old a record may be before it needs verification. Use a limited, authorized sample during discovery instead of exporting an entire customer database into a planning document.
- Sources: system, record identifier, required fields, owner and update frequency.
- Permissions: what can the workflow read, create or change for each user?
- Retention: what must be stored, for what purpose and for how long?
Turn success into an acceptance test
Choose checks that an operator can run and explain. For example, a retried CRM task should update the intended record without creating a duplicate. A document assistant should identify the source used and send an incomplete request to review. These are illustrative checks, not performance claims. Agree the expected behavior on representative cases before selecting the final implementation.
- Normal case: expected output and the system where completion is recorded.
- Exceptions: missing data, contradictory sources, denied access, repeated requests and unavailable tools.
- Operating limits: acceptable task duration, review effort and cost per completed task.
Agree the handover and the next decision
A release is not complete when only its builder can operate it. Assign someone to monitor failures and approve changes. Agree what documentation, access and training the team will receive. Review the pilot against its acceptance criteria before expanding the scope. If the result is not useful, identify whether the problem is the implementation, the data or the original task selection.
- Ownership: repositories, infrastructure, vendor accounts and ongoing responsibilities.
- Recovery: how to stop the workflow, investigate a failure and resume manual work.
- Decision: proceed, adjust the scope or stop, with a named decision maker and review date.