August 13, 2026 · 7 min read
AI Avatar Project Brief Template for Sales Teams
An AI avatar project brief should define who the avatar serves, whose likeness and voice it may use, what it is allowed to say, which approved sources it knows, what action completes a successful conversation, and when a person takes over. The template below gives sales, marketing, legal, and implementation teams one shared set of decisions before production begins.
Copy the headings into your working document and replace the bracketed prompts with approved facts. A useful brief is specific enough to test. It should describe real audiences, real source material, and real handoff paths rather than asking the build team to make assumptions.
Project approval path
A sales avatar needs four approvals before production
Ready to build
Consent recorded, sources owned, actions mapped, handoff tested
Keep in review
Missing consent, unsupported claim, stale source, or unclear system destination
Build the brief with every owner in the room
Two printable pages with decisions, checklist items, and acceptance tests.
Created by Sales Avatar, a HummingAgent product.
See how these decisions become observable launch checks in the website AI sales avatar process.
1. Business goal and audience
Primary goal: [qualify inbound visitors, explain a product, guide a demo, answer buyer questions, or another defined outcome]. Primary audience: [role, company type, buying stage, geography, and language]. Successful conversation: [the observable action or answered need that marks completion].
List what the avatar should not optimize for. If it should educate but never negotiate, say so. If it supports existing customers but does not handle billing disputes, put that boundary in the brief before scripts and integrations are built.
2. Likeness, voice, consent, and disclosure
Approved person or visual identity: [name or brand character]. Approved voice: [source and permitted use]. Consent owner and record location: [owner]. Permitted channels and duration: [website, event, campaign, regions, and term]. Revocation process: [who removes assets and where].
Disclosure: the experience must clearly identify itself as AI. Document prohibited impersonation, deceptive editing, and any context where the likeness or voice cannot appear. Consent is an operating requirement, not a one-time production checkbox.
3. Knowledge and response boundaries
Approved sources: [product documentation, current pricing, policies, case studies, FAQs, and objection guidance]. Source owner: [person responsible for accuracy]. Refresh trigger: [what change requires an update]. Prohibited claims: [unsupported outcomes, legal promises, unapproved comparisons, or confidential information].
Define what the avatar says when the source does not answer a question. The safe response should acknowledge the limit, capture the question, and offer the approved human path instead of inventing an answer.
4. Conversation, CRM, and handoff flow
Entry point: [page, campaign, or event]. Required qualification fields: [fields]. CRM record and owner: [object, fields, assignment rule]. Calendar action: [meeting type and eligibility]. Human handoff triggers: [pricing exception, security review, complex technical question, complaint, or explicit request].
Describe the end state for every branch: meeting booked, lead routed, question logged, content delivered, or human connected. A transcript without a destination is not a finished sales workflow.
5. Acceptance tests and ongoing ownership
Test the common buyer path, an unsupported claim request, outdated source content, a CRM failure, a calendar conflict, a request for a person, a consent question, and an adversarial prompt. Confirm both the visible response and the system record created afterward.
Name the owners for content, consent, integrations, analytics, incident response, and final launch approval. Review conversations after launch and change the system from observed failure patterns, not guesses about what users might ask.