Preparation, not self-deployment
What guided onboarding does
Guided onboarding creates a shared implementation brief. You provide accurate business decisions, approved information and operational context; ConvoRev uses that material to prepare, configure, test and refine the conversation system.
Business decisions
Define the audience, use case, next action, boundaries and people responsible for approval.
Approved knowledge
Identify the sources the AI Agent may use and separate confirmed information from open questions.
Operational connections
Describe the required channels, calendars, hours, handoffs and existing systems that should remain in place.
Private testing
Confirm the scenarios, reviewers and release conditions used before normal contacts see the experience.
Onboarding does not mean you must design and launch the system alone. Its purpose is to give ConvoRev the reliable input needed to do the implementation work with you.
Gather the right people and sources
Before you begin
You do not need every stakeholder in every session. Start with the people who can approve the first use case and explain how the existing customer workflow operates.
Business owner
A person who can confirm offers, policies, boundaries and the intended customer outcome.
Source material
Current website pages, documents, FAQs, policies and operational instructions.
Workflow owner
A person who understands how bookings, estimates, applications, purchases or handoffs are completed.
Access owner
An administrator who can authorize required channel or calendar connections through approved methods.
If pricing, policy, availability or qualification information is uncertain, mark it for verification instead of supplying an assumption.
Seven preparation stages
Complete the onboarding brief
Work from business context toward private testing. Each stage gives the next implementation decision a more reliable foundation.
Business context
Describe the business and audience
Give ConvoRev enough context to understand what the business offers, who starts the conversation and where the first opportunity comes from.- Industry, business model and locations or service area
- Products, services or programs included in the first release
- Primary audience and common reasons they start a conversation
- Website, campaign, referral source or other starting context
First outcome
Define the conversation's job
Choose one meaningful next action for the first deployment. This gives the AI Agent a clear destination without treating every conversation the same way.- The question, decision or problem the conversation should support
- The booking, estimate, application, purchase path or qualified handoff
- Information that should be collected before the next action
- Situations that should not continue through the normal path
Approved knowledge
Identify the sources the AI Agent may use
Provide current, approved material and separate confirmed facts from information that still needs verification.- Relevant website pages, documents, FAQs and policies
- Pricing rules, quote process, availability and important exceptions
- Eligibility, qualification or service-area requirements
- Claims the AI Agent may make and claims it must avoid
Channels and timing
Describe where and when conversations happen
Confirm the intended customer-facing entry point, operational hours and any booking or calendar requirements without changing the existing stack unnecessarily.- Supported channel or website entry point for the first release
- Business hours, response expectations and after-hours handling
- AI Agent active hours, quiet periods or timing restrictions
- Booking method, appointment types and calendar ownership
Voice and qualification
Set the conversation style and questions
Explain how the AI Agent should sound, what it needs to learn and how much information is appropriate before the next action.- Preferred tone, formality, terminology and response length
- Languages the approved experience should support
- Questions used to understand or qualify the request
- Words, claims, topics or decisions that require special handling
Handoffs and ownership
Define when a person takes over
Give every escalation a reason, destination and owner. A handoff is useful only when the receiving person knows what happened and what to do next.- Ambiguity, complaints, exceptions and high-risk requests to escalate
- Person, role, team inbox or business system receiving the handoff
- Contact and qualification context that should accompany it
- Response expectation and backup ownership
Testing and approval
Prepare a private verification path
Identify who will test, who can approve the first release and which scenarios must pass before normal contacts see the experience.- Private test contact, channel or approved test environment
- Normal, ambiguous, difficult and out-of-scope scenarios
- Sensitive requests and human-escalation tests
- Approver for knowledge, behavior, handoffs and release scope
Data safety
Handle access and sensitive information safely
General onboarding fields and ordinary notes are for business context—not secrets or unnecessary personal records.
- Approved public business information
- Current policies and operating instructions
- Role names and monitored team destinations
- Connection requirements without the secret values
- Passwords, secret keys or authentication codes
- Private customer records or full conversation exports
- Payment details or unnecessary identity documents
- Confidential notes unrelated to the first deployment
Use the approved secure connection or authorization method for each account, channel, calendar or system. Provide only the permissions required for the implementation.
Shared implementation
Who handles what
Clear ownership keeps onboarding from becoming an open-ended information request and ensures that implementation decisions can be approved.
Useful working answers
Save progress without turning uncertainty into fact
You do not need to solve every open question in one session. Record what is confirmed, identify the owner of each missing decision and return when the source is available.
Ready to use
The answer has an accountable source and may be included in the implementation brief.
Needs confirmation
The question is important, but pricing, policy, availability or another fact still requires an approved answer.
Outside first scope
The idea may be useful in a future phase but is not required for the first deployment.
- The question
- The responsible owner
- The approved source needed
- The date it will be reviewed
Before configuration is finalized
Onboarding approval checklist
Use this checklist to confirm that the implementation brief is ready for preparation and private testing.
The first audience, use case and intended next action are clear.
The approved knowledge sources are current and contradictions are resolved.
Voice, language, qualification questions and prohibited claims are documented.
Channels, hours, booking requirements and timing restrictions are confirmed.
Escalation triggers, handoff context and human ownership are approved.
Private test scenarios and the release approver are identified.
Unresolved critical facts, missing human ownership or unclear test conditions should pause preparation of the affected path until the decision is confirmed.
From brief to prepared release
What happens after onboarding
The completed brief becomes the working foundation for configuration, connection, testing and release approval.
Review
ConvoRev checks the brief for missing decisions, conflicting sources and implementation dependencies.
Prepare
The approved material is organized into AI Agent instructions, knowledge, boundaries and workflow requirements.
Connect
Required supported channels and next-action paths are prepared using the appropriate authorization method.
Test
The first conversation path is privately evaluated, corrected and presented for release approval.
The existing CRM, website, calendar, store or operational system remains in place whenever practical. ConvoRev prepares the conversation layer to work alongside it.
Continue the preparation path
