Problem, users and process
- The business problem and its observable consequences.
- Affected users and their role in validation.
- The current process, steps and tools already used.
- The expected result and anything explicitly outside scope.
How to write an AI project brief
A useful project brief gives providers enough context to propose a scope, ask the right questions and make their responses comparable.
Purpose
What the project brief is for
The document explains context, aligns stakeholders and helps providers respond to the same need. It can remain incomplete in the first version as long as assumptions and open questions are clearly marked.
Expected outcome
- Providers understand the problem before proposing a solution.
- Scopes and responsibilities become easier to compare.
- Unknowns are visible before pricing and contracting.
Minimum information
Information that makes a response actionable
Write “to be clarified” when information is missing. An explicit unknown is more useful than an invented level of precision.
Data, volume and tools
- Available data, format, quality and data owner.
- Current volumes, frequency and known variations.
- Existing software, APIs and test environments.
- Required integrations and those still to be confirmed.
Technology, security and control
- Technical constraints, identities and access rights.
- Security, confidentiality and retention rules.
- Hosting or data-location constraints.
- Steps that require human validation and an audit trail.
Governance, budget and continuity
- Success and acceptance criteria.
- Budget, timeline and internal responsibilities.
- Expected deliverables, documentation and training.
- Maintenance, support, reversibility and knowledge transfer.
Wording
Separate the need, feature and technical solution
Need
Reduce the time a support team spends sorting incoming requests.
Describes the problem, users and expected outcome.
Feature
Classify requests, suggest a priority and prepare a summary for human validation.
Describes useful behavior without fixing the whole architecture.
Technical option
A model connected to the shared inbox and case-management tool.
A possible implementation that the provider should validate against constraints.
Choices to delay
What not to impose too early
A mandatory constraint should have a business, legal, security or operating reason. Otherwise ask providers to compare options.
- A specific model before quality criteria are defined.
- A complete architecture before data and integrations are inventoried.
- Automation without human validation for a sensitive decision.
- A hosting choice before security requirements are stated.
- An unverified target volume or performance claim without test cases.
- Production deployment while the test scope is still open.
Copyable template
AI project brief template
Copy this template into your working document, remove fields that do not apply and mark information that still needs clarification.
Template ready to complete
AI PROJECT BRIEF 1. CONTEXT - Business activity and team involved: - Situation that triggered the project: - Stakeholders: 2. BUSINESS OBJECTIVE - Problem to reduce or decision to improve: - Expected outcome: - Explicitly out of scope: 3. CURRENT PROCESS - Current steps: - Tools used: - Observed friction points: - Current human validation: 4. USERS - User profiles: - Number of users or usage frequency: - Training or change-management needs: 5. DATA - Available sources: - Format, quality and data owner: - Personal, sensitive or confidential data: - Missing data or preparation required: 6. VOLUMES - Input or document volume: - Frequency and known variations: - Assumptions still to confirm: 7. INTEGRATIONS - Software and systems involved: - Available APIs or connectors: - Test environments: - Identities, roles and access rights: 8. CONSTRAINTS - Business constraints: - Technical constraints: - Internal-team availability: - Reversibility requirements: 9. SECURITY AND HOSTING - Confidentiality rules: - Hosting location or policy: - Data retention and deletion: - Logging and access control: 10. DELIVERABLES - Expected deliverables: - Documentation: - Training: - Knowledge transfer: 11. SUCCESS CRITERIA - Business indicators: - Quality criteria: - Acceptance conditions: - Stop or review thresholds: 12. BUDGET - Budget range or decision method: - Recurring costs to make explicit: - Internal time available: 13. TIMELINE - Desired milestones: - Availability constraints: - External dependencies: 14. MAINTENANCE - Owner after delivery: - Monitoring and incident handling: - Update cadence: - Support conditions: 15. POINTS TO CLARIFY - Open questions: - Hypotheses to test: - Decisions expected from the provider:
The button only copies the template locally to your clipboard. Template content is not sent to GA4.
Simplified example
Example for a services SMB
Fictional example: a team receives requests in a shared mailbox and wants to improve triage before assignment. Draft outputs remain subject to employee validation.
- Objective
- Reduce manual triage and make prioritization more consistent.
- Users
- Support team and an owner responsible for validating rules.
- Data
- Historical messages to inventory, existing categories and internal rules.
- Integrations
- Shared mailbox and case-management tool, subject to suitable technical access.
- Initial deliverable
- A limited-scope test with reviewed results and documented errors.
- Expected decision
- Determine whether quality, security and integration effort justify a next stage.
Useful discovery
Questions good providers should ask
- 1Which business problem are we trying to reduce, and how is it observed today?
- 2Which data is genuinely available for a representative test?
- 3Which users will participate in workshops, testing and validation?
- 4Which integrations are required from the first stage?
- 5Which actions must always remain subject to human validation?
- 6Which security, confidentiality and hosting constraints apply?
- 7Which deliverable will allow us to continue, change direction or stop?
- 8Who will operate and maintain the solution after delivery?
Needs revision
Signs that the brief is not ready
- The brief starts with a model or tool without explaining the business problem.
- Users and the internal project owner are not identified.
- Data is described as available without format, volume, quality or access rules.
- The scope mixes a test, final product, integration and maintenance without distinction.
- No acceptance or end-of-stage decision criteria are defined.
- The budget does not separate initial delivery, tools and recurring costs.
- Security, human validation or reversibility are not addressed.
Evaluation
How to compare responses
Ask providers to respond in a common format. Keep assumptions and reservations visible because they often explain differences in price and timeline.
Understanding
The provider restates the problem and identifies missing information.
Scope
Deliverables, exclusions, responsibilities and dependencies are explicit.
Method
Stages, tests, human validation and the end-of-stage decision are described.
Evidence
References or demonstrations are tied to a comparable context.
Total cost
Initial work, tools, operations and maintenance are separated.
Reversibility
Documentation, data, access and handover are planned.
The provider evidence checklist helps distinguish a demo, reference, deliverable and private evidence.
Next step
Choose which provider categories to approach
The same brief can be sent to different provider types. Keep the categories whose responsibilities match the scope you have described.
AI agencies
For designing and delivering a use case with a project team.
AI consultants
For auditing, prioritizing, scoping and supporting a decision.
AI integrators
For connecting, securing and operating a solution in the existing IT environment.
Already have a project brief?
Use it to describe your business need, data, systems, budget and constraints. The shortlist workflow can then compare providers against the same scope.