> ## Documentation Index
> Fetch the complete documentation index at: https://help.avoca.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Prepare for go-live

> Use a product-neutral readiness review to launch safely and establish clear operating ownership.

Avoca implementations commonly move from account and CRM setup through configuration, testing, launch, and post-launch monitoring. The exact sequence depends on the products and integrations your team uses.

Current self-serve teams use **Deploy → Launchpad** for assigned setup steps; teams on the legacy onboarding experience continue to use **Deploy → Setup**. Use **Deploy → Implementation** for readiness status. Treat these pages as guides: none replaces product-specific testing or launch coordination.

## Assign owners before configuring

Identify one owner for each area:

| Area                                                | Typical owner                      |
| --------------------------------------------------- | ---------------------------------- |
| Business hours, services, policies, and fees        | Operations leader                  |
| CRM credentials, catalog, and data sync             | CRM administrator                  |
| Booking windows, capacity, and holidays             | Dispatch or scheduling owner       |
| Transfers, on-call coverage, and emergency handling | Contact-center or operations owner |
| Messaging consent and brand registration            | Marketing or compliance owner      |
| Website widget or scheduler deployment              | Website owner                      |
| Reporting definitions and success targets           | Product or business owner          |

The same person can own several areas, but every launch decision should have a named approver.

## Complete the shared foundation

Before product-specific work:

1. Confirm the selected Avoca team, timezone, company name, contact details, and CRM.
2. Connect the CRM and complete the first catalog sync.
3. Review job types, business units, tags, service areas, and call reasons.
4. Complete the [Knowledge Base](/responder/knowledge-base).
5. Configure [Booking Windows](/responder/booking-windows), holidays, fees, and capacity as applicable.
6. Create Employee Contacts and confirm notification preferences.
7. Invite dashboard users with the minimum access they need.

<Tip>
  Correct the source system first. A prompt change cannot repair a missing CRM job type, an incorrect timezone, or an unavailable booking window.
</Tip>

## Review readiness by product

### Responder

* The agent has an approved name, intro, languages, and disclosure behavior.
* Services, service exclusions, FAQs, hours, and emergency guidance are accurate.
* Booking, cancellation, rescheduling, and fee behavior match the operating process.
* Transfer destinations have correct phone numbers, reasons, and schedules.
* Call classifications match the reporting questions the team will use.
* The production phone-routing plan and rollback owner are documented.

### Outbound

* Business compliance and brand onboarding are complete for the channels in use.
* The audience is previewed and exclusions are applied.
* The workflow is published, execution hours are approved, and every branch ends intentionally.
* The campaign uses the correct audience, workflow, phone number, and recurrence policy.
* Opt-out handling and monitoring ownership are confirmed.

### Speed-to-Lead

* Every source has a verified ingestion method and source attribution.
* Phone-number, service-area, CRM campaign, and tag mappings are complete.
* The intended campaign is active, or fallback behavior is explicitly approved.
* A controlled lead reaches Avoca, enters the workflow, and produces the expected Lead Journey.

### Simple Scheduler

* Appearance, service types, questions, ownership, compliance, and tags are configured.
* Each service produces the intended availability and CRM record.
* The generated widget key allows only approved domains.
* Website links, UTM mappings, and the production embed are tested.
* Notification and drop-off follow-up ownership are assigned.

### Coach

Use the dedicated [Coach overview](/coach/overview), [access](/coach/access), [rubrics](/coach/rubrics), and [call review](/coach/call-review) guides.

## Run a launch test matrix

Test at least:

* A new customer and an existing customer
* A supported request and an unsupported request
* A normal-hours and after-hours interaction
* A bookable and unavailable request
* A valid and invalid service area
* A completed transfer and a closed-destination fallback
* An emergency and non-emergency scenario
* A cancellation or rescheduling request when enabled
* The expected notification and CRM result

For website products, repeat the primary flow on desktop and mobile. For messaging products, test opt-out behavior with approved test contacts.

<Warning>
  A controlled test can create a real customer, job, appointment, message, or phone call in connected systems. Use approved test data and clean up records according to your operating process.
</Warning>

## Coordinate the cutover

Before production traffic moves:

1. Confirm the date, timezone, traffic-routing change, and launch owner.
2. Record the phone, campaign, source, widget, or integration being activated.
3. Confirm the expected rollback action and who can perform it.
4. Freeze unrelated configuration changes during the cutover window.
5. Route a controlled production interaction.
6. Verify the customer experience, dashboard record, CRM record, alerts, and reporting.
7. Mark the product Live in **Deploy → Implementation** only after the real launch is confirmed.

## Monitor the first week

Review the first production day closely, then establish a daily cadence for the first week:

* Volume and missing records
* Booking, transfer, response, and containment outcomes
* Source attribution and workflow entry
* CRM errors, sync delays, and unmapped catalog values
* Notification failures
* Repeat customer complaints or unexpected questions

When an issue appears, preserve the affected interaction ID and time, identify the owning configuration, fix the source, and retest the same scenario.

After stabilization, move to a weekly operating review with a named owner for each product and report.