Complete Zendesk Implementation Checklist

Governance and requirements

1. Document the supported channels and explicitly disable or omit every out-of-scope channel: Talk, SMS, social messaging, Web Widget, live chat, and community.
2. Map every Issue Category and website/app path to classification, priority, SLA, handoff, and resolution.
3. Approve a production-change process for Zendesk configuration: request, impact, peer review, test evidence, approval, change window, rollback, and post-change validation. [PT-07]
4. Create the agent feedback process for go-live.
   • Collect bad routing, missing macros, confusing fields, wrong AI/Copilot suggestions, translation issues, and broken handoffs.
   • Review feedback on a set cadence and decide which fixes ship.
5. Freeze the smallest reliable ticket model before building. [PT-01]

Security, privacy, and compliance

1. Require two-factor authentication for all team members. [ZD-09]
2. Limit admins to the minimum necessary people.
3. Use a distinct OAuth client for every integration; never use a shared API token for this implementation.
   • New accounts created on or after July 28, 2026 cannot create or use Support API tokens, and all remaining API tokens stop working April 30, 2027. [ZD-10]
   • Use short-lived tokens, refresh/renewal handling, the narrowest resource scopes, secret rotation, and immediate revocation capability.

Brand, identity, and localization

1. Create or confirm the single production brand; set its name, logo, favicon, colors, default language, support addresses, and help-center association.
2. Approve the customer-visible human support team name.
3. Approve the Messaging AI agent name, avatar, and automated-agent disclosure.
4. Approve the Email AI agent name, sender presentation, and automated-agent disclosure.
5. Approve sender identity for human replies, AI-agent replies, and form confirmations.
6. Approve tone, terminology, capitalization, prohibited phrases, and signature style.
7. Approve legal footer, privacy notice language, and accessibility language.
8. Set English as the default Support/interface language.
9. Prepare dynamic content and email copy for English first; add Spanish and French only where the support workflow is ready for those app-interface languages.
10. Prepare mobile support-entry strings for the documented app interface languages: English, Spanish, and French. Keep English as the fallback.
11. Verify time zone, date/time formats, agent locale, business-hours time zone, and daylight-saving behavior.

Multilingual support for a monolingual human team

Coverage model

1. Create one language map from the documented app languages. [ZD-71]
   • Start with English default, Spanish, and French.
   • Track stream language separately as user/request metadata.
   • Track channel, use case, AI-agent support, conversation translation, help center, app UI, and fallback path.
2. Write the support promise for each app language: English full support, Spanish/French translated support where ready, or English fallback.
   • Do not treat stream-language selections as a same-language human support promise.
3. Set English as the account default language. [ZD-70]
   • Activate only the additional languages needed for the app/support workflow.
   • Do not assume activation translates email notifications, rules, macros, knowledge, or app-owned strings.
4. Add a preferred-language selector to the company-owned website form.
   • Pass the normalized locale through the backend.
   • Store the submitted value.
   • Set requester language through the approved rule/API mapping.
   • Treat browser/device locale and AI detection as hints when they conflict with an explicit choice.
5. Enable intelligent-triage language detection for the intended channels. [ZD-52]
   • Measure accuracy by language and channel before using it in rules or reports.
   • Create an Unknown/Needs review fallback.
6. Use Requester language conditions/actions to reconcile trusted form selections, requester profiles, and detected language; document precedence and prevent rules from repeatedly flipping the user’s language. [ZD-77]
7. Enable native conversation translation in Admin Center → Objects and rules → Tickets → Settings → Comment options for agents.
   • Enable Translate with AWS translate for Messaging and outgoing async comments.
   • Enable Additionally, translate async channels with AWS Nova Micro for both incoming and outgoing Email/API comments.
   • Decide whether to show the AI-translation disclosure on async replies; the disclosure setting does not apply to Messaging.
   [ZD-69]
8. Train agents on conversation translation controls. [ZD-81]
   • Accept or correct the detected language.
   • Turn translation on or off per conversation.
   • Inspect Show original and Show translation.
   • Escalate when meaning is ambiguous.
   • Do not copy customer data into consumer translation tools.
9. Create a case-sensitive do-not-translate glossary for brand/product names, URLs, commands, policy terms, agency names, legal citations, abbreviations, and identifiers. [ZD-72]
10. Use dynamic content for translated email, trigger, automation, macro, status, and system-message text. [ZD-73]
    • Create a variant for every enabled language.
    • Test the default-language fallback.
11. Enable help-center languages separately from Support languages and set the translated help-center name. [ZD-74]
    • Verify URL locale, profile/browser preference behavior, locale switcher, and default fallback.
12. Translate the help-center hierarchy in order: category, section, then article. [ZD-75]
    • Include theme snippets, navigation, metadata, and search terms.
    • Do not publish orphan translations whose parent pages are missing.
13. Use AI article translation only as a draft. [ZD-76]
    • Apply the glossary.
    • Retain the source/version relationship.
    • Review high-impact content through the approved process.
    • Add any required AI-translation notice.
    • Remember AI article translation does not support content blocks.
14. Track whether translated articles and dynamic-content variants are current; unpublish stale translations when the meaning materially changes. [PT-08]
15. Activate only languages supported for the current AI-agent use cases, generative replies, and agentic AI. [ZD-78]
    • Test mixed-language messages, language switching, unsupported-language fallback, and script/dialect issues where relevant.
16. Verify the Messaging and Email AI agents answer in the customer’s language from the intended source article/procedure, then preserve that language through human escalation.
    • Re-test supported languages after knowledge, instructions, procedures, model behavior, or system replies change.
17. Localize and test app-owned iOS and Android support-entry strings, SDK overrides, notification copy, accessibility labels, error states, dates/numbers, truncation, and pluralization. [ZD-79] [ZD-80]
    • Remember SDK UI localization does not translate AI, agent, or integration-authored conversation content.
18. Run language UAT for every launched locale using the best available review path.
    • If nobody can validate a language, launch it as limited support or keep it out of scope.
    • Test ordinary support, slang/typos, mixed language, ambiguous dates/numbers, form attachments, AI resolution, human takeover, translated reply, and high-risk escalation.
19. Report by requester/detected language: volume, AI resolution, escalation, translation use, first reply, resolution, reopen, CSAT, complaint rate, and fallback rate.
    • Pause a locale when quality or the review path is not good enough.

People, groups, roles, and skills

1. Use the confirmed WeeVu group model.
   • Legal.
   • Tier 1.
   • Tier 2.
   • Managers.
   • WeeVu Team as the holding group for everyone.
2. Set each agent’s ticket access to the narrowest appropriate scope and assign only required product/channel access.
3. Add light agents for counsel, security, leadership, or subject-matter experts who need visibility/private collaboration but should not own or solve tickets. [ZD-15]
4. Use skills only for real handling expertise inside the confirmed groups, such as iOS, Android, DMCA, law enforcement, privacy, security, or partnerships. [ZD-16]
5. Create test users for anonymous contact intake, authenticated app users, user switching, duplicate-email cases, unsupported languages, suspended users, and each legal intake category.
6. Define onboarding, role-change, leave, and offboarding procedures, including reassignment of open tickets and revocation of app/AI/OAuth access.

Ticket model and Agent Workspace

1. Retain one internal default ticket form only; do not publish Zendesk end-user ticket forms.
2. Use the existing Issue Category dropdown field 46045543672219 as the source of truth, not free-form tags.
   • Account / Login.
   • DMCA.
   • Equipment.
   • Legal / Compliance.
   • Other.
   • Payments.
   • Payouts.
   • Press / Partnerships.
   • Refund request.
   • Requests.
   • Safety / Abuse.
   • Streams.
   • Technical / App Bug.
3. Create only fields used for routing, handling, compliance, or reporting.
   • Source application/platform (website, iOS, Android, email).
   • Product/app version, OS version, locale, and authenticated external user ID.
   • Organization/agency, jurisdiction/country, reference/case number, and authority type where appropriate.
   • AI outcome, escalation reason, contact-form correlation ID, and integration status.
   • Legal-hold flag and sensitivity classification if approved.
4. Set field permissions deliberately: agent-only, customer-viewable, customer-editable, required at creation, and required before solving.
5. Use tags as deterministic automation markers only—such as source_contact_form, no_ai_reply, agent_copilot_enabled, and integration_error—and document every tag owner and purpose.
6. Use standard status categories consistently; add a small number of custom statuses only if agents need meaningful distinction.
   • New: not yet accepted.
   • Open: actively owned.
   • Pending: waiting on requester.
   • On-hold: waiting on internal or third party.
   • Solved: response/work complete.
   • Possible custom statuses: Awaiting legal review; Awaiting agency verification; Awaiting partner decision.
7. Review every trigger, automation, view, SLA, macro, and report before activating custom statuses. [ZD-17]
8. Design a compact custom ticket layout: identity/context first, category and routing second, required handling fields third, low-frequency technical fields collapsed.
9. Define priority deterministically and document who may override it.
   • Urgent: verified immediate safety/security/legal deadline only.
   • High: time-sensitive legal or material service impact.
   • Normal: standard support and partnership work.
   • Low: informational or non-actionable requests.
10. Define requester, CC, follower, collaborator, side-conversation, merge, and child-ticket rules—especially for sensitive tickets.

Website contact form integration

1. Use the existing custom contact form as built; do not add new fields to this launch scope.
2. Keep the form payload limited to submitted email address, broad selected category, description, and allowed attachments.
3. Validate and normalize only the submitted email address, broad category, description, and attachment metadata.
4. Add layered abuse controls: managed CAPTCHA, honeypot, per-IP and per-email rate limits, WAF rules, payload limits, disposable-email policy, attachment allowlist, and alerting. [ZD-19]
5. Scan attachments before upload; validate extension, MIME type, magic bytes, size, file count, filename, and archive contents; quarantine failures.
6. Create a dedicated confidential OAuth client with the narrowest practical scope (start with tickets:write; add another scope only if testing proves it is required). [ZD-20]
7. Implement and test form authentication against Zendesk's OAuth flow.
   • Handle token expiry/renewal, secret rotation, revocation, and secure storage.
   • Add timeouts and retry with backoff.
   • Handle 401, 403, 409, 422, 429, and 5xx responses.
   • Re-test before launch because API-token behavior is changing.
8. Make submission idempotent so browser retries do not create duplicate tickets; retain a non-sensitive correlation ID from browser through server logs and Zendesk.
9. Map each broad form category to Issue Category deterministically.

   Website contact-form Issue Category and control mapping

   Issue Category	Group / priority	Required controls
   Legal / Compliance	Legal · High or policy-driven	no_ai_reply; verify authority; restricted notifications; counsel procedure
   DMCA	Legal · Normal/High by deadline	no_ai_reply; statutory-data checklist approved by counsel
   Legal / Compliance	Legal · High by jurisdictional clock	no_ai_reply; identity verification; legal-hold check
   Safety / Abuse	Legal · Urgent/High by severity when security/safety risk exists	no_ai_reply; secure disclosure path; no broad email notification
   Press / Partnerships	Tier 2 · Normal	Structured company/URL fields; acknowledgement; qualification macro
   Technical / App Bug, Account / Login, Streams, Requests, Payments, Payouts, Equipment, Refund request, or Other	Tier 1 · Normal	Product/platform metadata; normal routing; AI Tier 1 and Copilot eligibility

10. Verify the parser creates the ticket from the existing form payload.
    • Set requester to the submitted email address.
    • Set subject to the selected dropdown value.
    • Add the submitted description as the ticket message so AI can read it.
    • Set Issue Category, group, priority, source tags, attachments, and correlation ID from the parser mapping.
11. Keep API-created form tickets outside the email AI-agent trigger.
    • Do not clone the email AI-agent trigger for the API channel.
    • Require Channel = Email for the email AI agent.
    • Add no_ai_reply defensively for every sensitive category. [ZD-21]
12. Create the three confirmation email paths.
    • DMCA confirmation.
    • Law-enforcement confirmation.
    • General confirmation for all other categories.
13. Test that the submitted email address becomes the Zendesk requester.
14. Build monitoring for submission volume, success/failure rate, latency, CAPTCHA failures, 429s, OAuth failures, attachment failures, duplicates, and Zendesk ticket-creation confirmation.

Email channel

1. Create and verify only the required external support addresses; document the purpose, owner, brand, default group, and AI eligibility of each.
2. Configure forwarding from the company mail provider to Zendesk and verify forwarding in Admin Center. [ZD-23]
3. Publish and validate SPF, DKIM, and DMARC alignment for outbound Zendesk mail; test deliverability to major providers. [ZD-24]
4. Configure incoming SPF/DKIM/DMARC/ARC authentication at the chosen strictness; test direct and legitimately forwarded mail before enforcing. [ZD-25]
5. Set sender name, personalized-reply behavior, reply-to identity, agent signatures, and support-team signature; verify the AI-agent sender is unmistakably automated.
6. Customize both HTML and plain-text email templates; keep the design simple, accessible, responsive, and consistent with DMARC-safe sender identity. [ZD-26]
7. Review default requester/CC notification triggers and prevent duplicate acknowledgements or replies when the email AI agent responds.
8. Configure human notification triggers for received request, public reply, solved ticket, assignment, and escalation; exclude internal notes from customer email.
9. Restrict broad internal email notifications for sensitive legal/security tickets; notify only the designated group or on-call target.
10. Decide linked versus attached files, maximum sizes, private attachment behavior, and prohibited file types; test every path. [ZD-27]
11. Enable simplified email threading only after checking placeholders and notifications; test reply, forward, CC, changed subject, inline image, out-of-office, and mail-loop scenarios. [ZD-28]
12. Create and monitor views for suspended mail, authentication failures, forwarding errors, bounces, and unrecognized senders.
13. Run deliverability tests from Gmail, Microsoft 365, Apple/iCloud, Yahoo, corporate gateways, and forwarded aliases; inspect headers and confirm correct ticket threading.

Help center and knowledge

1. Activate one public help center for the production brand; keep restricted/internal procedures out of the public article set.
2. Remove Zendesk request-form links from the Help Center theme. [ZD-30]
3. Remove sign-in and request history UI if the customer portal is out of scope.
4. Keep messaging mobile SDK only; leave the Web Widget off the website and Help Center. [ZD-31]
5. Disable community and article comments unless there is a staffed moderation and response process.
6. Customize the Help Center theme for brand, mobile layout, accessibility basics, 404 handling, and print readability.
7. Create a small, stable category/section hierarchy based on user questions rather than internal departments.
8. Use one article for one question/decision wherever practical; put the direct answer first, then prerequisites, numbered steps, exceptions, and escalation path. [PT-02]
9. Track article owner, review date, product scope, locale status, and retirement rule.
10. Remove conflicting, obsolete, duplicate, marketing-heavy, or unsupported claims; never publish secrets, internal escalation contacts, or private procedures.
11. Use customer vocabulary in titles and headings; add synonyms and labels only where they improve retrieval.
12. Preview each article in Help Center search, AI-agent answers, and mobile SDK links before publishing.
13. Verify /hc/sitemap.xml, robots behavior, canonical URL, HTTPS, metadata, public access in an incognito session, and appearance in Google/Bing search tooling.
14. Create a knowledge feedback loop using failed searches, zero-result searches, article votes, AI fallbacks/escalations, Copilot gaps, and repeat contacts. [PT-03]
15. Suppress the Zendesk request form in the Help Center theme.
    • Remove the request-form helper and fields from new_request_page.hbs.
    • Render a localized explanation/link to the company-owned contact form instead.
    • Check article request callouts, search/error pages, and notification links after theme updates.
16. Set the End users → Anybody can submit tickets setting for the chosen intake model.
    • If new email senders are allowed, keep Zendesk open and suppress only the public form surface.
    • If only known users are allowed, close Support and test form-created requesters, mobile identities, email replies, and suspended tickets.

iOS Messaging channel — admin setup

1. Create production and test iOS Messaging channels in Admin Center and attach the correct brand.
2. Share the iOS channel keys and environment names with the mobile team. [ZD-33]
3. Confirm authenticated messaging uses backend-issued JWTs and stable external user IDs. [ZD-34]
4. Configure APNs for the iOS Messaging channel and confirm push opens the right conversation. [ZD-35]
5. Approve the iOS support entry point, bot name/avatar, colors, and customer-facing text.
6. Confirm the iOS app sends only approved support metadata: app version, OS, locale, support context, current screen, and authenticated user ID.
7. Confirm iOS handoff creates the expected Zendesk ticket with AI context, Issue Category, requester, and Tier 2 routing.
8. Confirm the iOS kill switch can hide support entry or stop new Messaging conversations without an app release.

Android Messaging channel — admin setup

1. Create production and test Android Messaging channels in Admin Center and attach the correct brand.
2. Share the Android channel keys and environment names with the mobile team. [ZD-37]
3. Confirm authenticated messaging uses backend-issued JWTs and stable external user IDs. [ZD-38]
4. Configure FCM v1 for the Android Messaging channel and confirm push opens the right conversation. [ZD-39]
5. Approve the Android support entry point, bot name/avatar, colors, and customer-facing text.
6. Confirm the Android app sends only approved support metadata: app version, OS, locale, support context, current screen, and authenticated user ID.
7. Confirm Android handoff creates the expected Zendesk ticket with AI context, Issue Category, requester, and Tier 2 routing.
8. Confirm the Android kill switch can hide support entry or stop new Messaging conversations without an app release.

Advanced AI agents — Messaging and Email

1. Create AI-agent use cases for the approved Tier 1 contact reasons. [PT-04]
2. Set the AI-agent operating rules for in-scope use cases, prohibited actions, human requests, uncertainty, privacy, knowledge, languages, tone, and incidents.
3. Create the Messaging AI agent using the production brand/knowledge base; configure a factual business profile, transparent bot name/avatar, tone, default language, and only fully supported translation languages.
4. Create the Email AI agent using the same approved knowledge source but channel-specific behavior, sender identity, response length, escalation message, and threading tests.
5. Connect only approved knowledge sources and define search rules by locale, labels, article scope, and channel where necessary. [ZD-42]
6. Customize and test system replies.
   • Welcome/greeting and explicit automated identity.
   • Knowledge reply and no-answer behavior.
   • Clarification and empty-message behavior.
   • Unsupported language.
   • Fallback, escalation, failed escalation, and after-hours handoff.
   • Feedback/BSAT and wrap-up. [ZD-43]
7. Configure immediate escalation for explicit human requests, repeated failed searches, unsupported requests, negative/high-risk situations, authentication failure, action failure, and prohibited topics.
8. Create AI-agent instructions for terminology, source grounding, disclosure, uncertainty, privacy, response length, links, and prohibited behavior. [ZD-44]
9. Create generative procedures only after the underlying human process is approved.
   • State use case, required parameters, step order, conditions, success, failure, and escalation.
   • Ask for confirmation before consequential actions.
   • Do not automate law-enforcement, DMCA, privacy, security, legal-hold, irreversible, or high-impact decisions.
   • Test, approve, activate, monitor, and retain rollback history. [ZD-45]
10. Choose the reply method for each use case: generative procedure for flexible resolution, or dialogue where a scripted flow is required and supported. [ZD-85]
11. Build AI-agent actions with least privilege and defensive controls.
    • Use allowlisted endpoints, strict input/output schemas, server-side authorization, idempotency, safe retry, audit correlation, and secret redaction.
    • Keep backend response under Zendesk’s 30-second requirement and return safe structured errors. [ZD-46]
    • Start read-only; separately approve every write action and its rollback.
12. Connect the Messaging AI agent as default responder only to the iOS and Android production channels after test-channel approval.
13. Connect the Email AI agent only to approved customer-support addresses.
    • Keep Channel = Email and Received at = approved support address constraints.
    • Do not support the API channel used by the website form.
    • Exclude users/organizations tagged no_ai_reply or equivalent. [ZD-47]
14. Verify the email AI agent strips quoted history/signatures, asks clarifying questions, handles sequential generative procedures, and escalates complex requests safely. [ZD-48]
15. Create a version-controlled AI evaluation set.
    • Answerable, unanswerable, ambiguous, typo-heavy, hostile, slang, unsupported-language, and multi-intent requests.
    • Explicit human request, repeated fallback, after-hours, disconnection, action timeout/error, and unavailable team.
    • PII, legal categories, prompt injection, knowledge poisoning, and requests to ignore policy.
    • Email quoting/signatures/footers/attachments and mobile metadata/authentication cases.
16. Set launch thresholds for factual correctness, source fit, generative-procedure completion, unauthorized actions, legal replies, escalation, latency, and language quality.
17. Run pilot testing in closed channels, then a small production cohort; review every contained/resolved conversation during the initial pilot. [PT-05]
18. Configure and monitor current automated resolution tiers/allowance; set usage notifications, billing owner, dispute/review process, and budget guardrail. [ZD-49]
19. Define emergency stops: deactivate affected channel/agent, turn off email automation, disable actions, and revert the last generative-procedure or knowledge change.

Zendesk Copilot

1. Open Admin Center → AI overview and confirm which AI and Copilot features are enabled for this rollout. [ZD-51]
2. Enable intelligent triage for only intended channels and configure topic, sentiment, language, and approved entities.
   • Review detected topics before using them in routing.
   • Create custom topics only where the standard model is insufficient.
   • Add entity synonyms and false-positive tests.
   • Exclude sensitive values that should not be extracted or exposed.
   [ZD-52]
3. Use intelligent-triage fields only after checking accuracy by channel, Issue Category, and language.
4. Maintain Intelligent Triage topic mappings into Issue Category field 46045543672219 from the Intent field 46042145719195.
   • Keep custom topics aligned to Equipment, Payouts, Streams, Requests, Payments, Safety / Abuse, and Account / Login.
   • Keep default-topic mappings aligned to Account / Login, Payments, Payouts, Refund request, Equipment, DMCA, Technical / App Bug, and Other.
   • Keep the form's explicit Issue Category as the higher-trust value when form and topic disagree.
5. Enable sentiment detection only after deciding whether sentiment changes priority or remains reporting-only; test frustrated-but-low-risk and neutral-but-urgent tickets before routing on sentiment.
6. Configure entity detection for useful structured values such as app versions, device platform, legal reference numbers, jurisdiction, and urgency.
7. Turn on ticket summaries for the pilot group and train agents to check the ticket history before acting.
8. Turn on enhance-writing tools by group; publish communication guidelines and require agents to review accuracy, commitments, tone, and privacy before sending.
9. Enable quick answers and similar tickets for appropriate groups; verify source visibility and prevent agents from copying obsolete or customer-specific data.
10. Enable merge suggestions only for groups trained on requester identity, channel history, legal holds, sensitive-category separation, and irreversible merge consequences.
11. Enable suggested first replies for a low-risk pilot group only after macros and public knowledge are clean.
    • Suggested first replies can draw from macros/help-center content and sometimes LLM-generated content; agents must verify every suggestion.
    • Auto assist takes precedence when both features produce suggestions. [ZD-53]
12. Identify the first three to five Auto Assist use cases from repetitive, multi-step human work; exclude autonomous legal analysis and high-risk decisions.
13. Configure Copilot rewrite guidelines for greeting, signature, banned promises, brand terms, privacy language, and tone.
14. Turn on Auto Assist for the pilot group and intended tickets using agent_copilot_enabled. [ZD-54]
15. Create one approved Auto Assist procedure per operational problem.
    • Write short, ordered steps directed at the agent.
    • Reference the correct public article, internal procedure, macro, fields, and action.
    • Include prerequisites, branching, stop conditions, manual checks, and escalation.
    • Track version, test cases, and rollback.
    [ZD-55]
16. Review, edit, test, and publish AI-generated procedure drafts before use. [ZD-56]
17. Create Auto Assist actions with least privilege, explicit agent approval, strict parameters, idempotency, safe failure messages, and rollback.
    • Use read-only actions first.
    • Require an additional confirmation for refunds, deletions, account changes, or external side effects.
    • For legal categories, use procedures to guide human verification/escalation; do not create actions that decide legal validity.
    [ZD-57]
18. Test each procedure/action against qualifying, near-match, non-match, conflicting, incomplete, sensitive, multi-intent, wrong-language, and failure cases.
19. Train agents to inspect sources, edit suggestions, reject unsafe/incorrect output, report problems, and remain accountable for every sent reply or approved action.
20. Train Tier 2 agents to use Copilot as the escalation playbook after AI Tier 1 handoff.
    • Read the AI conversation summary and source ticket history before acting.
    • Use Copilot for next-step guidance, suggested replies, procedures, and action prompts.
    • Confirm facts, policy fit, customer impact, and required approvals before sending or taking action.
    • Flag missing, wrong, or confusing Copilot guidance through the agent feedback process.
21. Configure group-level access for Auto Assist, enhance writing, similar tickets, merge suggestions, and suggested first replies; default new/high-risk groups to off until trained. [ZD-58]
22. Configure the Copilot Agent Productivity dashboard and review usage weekly. [ZD-59]
23. Enable Admin Copilot only with two-person review for production changes.
    • Admin Copilot is included with Suite Professional as of May 2026 and does not consume the monthly Copilot allowance. [ZD-60]
    • Because Professional lacks the account audit log, record Admin Copilot changes in the external configuration register.
24. Review Admin Center Home recommendations weekly during build and approve changes manually.
25. Validate the Copilot stack in UAT: summaries, suggested replies, quick answers, similar tickets, Auto Assist, actions, merge suggestions, and live translation.

Routing, business rules, schedules, and SLAs

1. Set the single Professional-plan business schedule, holidays, and time zone before building business-hour triggers, automations, SLAs, or messaging responses. [ZD-61]
2. Use push routing with auto-accept for email and messaging escalations.
3. Configure agent statuses, staged email/messaging capacity, reassignment timing, focus mode, and skills timeout.
   • Stage 1: 2 messaging conversations and 6 email tickets per agent.
   • Stage 2: 4 messaging conversations and 4 email tickets per agent.
   • Stage 3: 6 messaging conversations and 2 email tickets per agent.
4. Create queues for urgent legal/security, AI escalations to Tier 2, SLA risk, Tier 1 work, and manager review. [ZD-62]
5. Design trigger categories and naming before creating triggers.
   • 00 · Guardrails / exclusions
   • 10 · Intake normalization
   • 20 · Classification / priority
   • 30 · Group / skills / routing
   • 40 · AI / Copilot enablement
   • 50 · Notifications
   • 60 · Integrations
   • 90 · Cleanup / closure
6. For every trigger, capture purpose, exact conditions, actions, ordering dependency, test case, and rollback. [PT-06]
7. Build deterministic intake triggers first: normalize source/Issue Category/platform, apply tags, set priority, assign group, then notify.
8. Route sensitive Issue Categories to Legal with no_ai_reply before AI/Copilot eligibility rules.
9. Use intelligent-triage topic/sentiment/language/entity in routing only with confidence/accuracy monitoring and a safe default queue.
10. Create automations only for time-based work: pending reminders, stale on-hold review, solved-to-closed, escalation reminders, and integration cleanup.
    • Automations run hourly, not at an exact minute, and can affect at most 1,000 tickets per hourly run. [ZD-63]
11. Define achievable SLA policies by priority/category and specify whether targets use business or calendar hours.
    • First reply, next reply, periodic update, requester wait, agent work, and total resolution as appropriate.
    • Do not assume an SLA applies to an AI-agent-only messaging ticket; it starts only after human escalation makes the ticket editable. [ZD-64]
12. Create SLA-warning views/triggers and test achieved, breached, reopened, pending, on-hold, AI-escalated, and retroactively applied scenarios.
13. Run collision tests across channel, Issue Category, priority, language, event log, and notifications.
14. Export the final rules, fields, forms, groups, queues, schedules, webhooks, and channel settings as the launch baseline.

Agent operations and training

1. Create focused shared views: unassigned, my open work, messaging escalations, email support, API/contact-form intake, legal/DMCA, privacy, security, partnerships, SLA at risk, suspended, integration failures, and stale pending/on-hold.
2. Create approved macros for acknowledgement, missing information, identity/authority verification, AI escalation follow-up, partnership qualification, pending reminder, resolution, and internal escalation.
3. Ensure macros set the correct comment visibility, status, fields, tags, group, priority, and next owner—not just response text.
4. Write concise SOPs for each Issue Category, status, escalation, attachment rule, legal hold, incident path, and outage fallback.
5. Train agents in Agent Workspace, messaging handoff, email threading, public versus internal comments, requester/CC handling, views, statuses, SLAs, macros, search, and knowledge feedback.
6. Train agents on AI boundaries: AI-agent history, AI-only read-only tickets, escalation context, Copilot source checking, editing/rejecting suggestions, and reporting unsafe output.
7. Train legal/security handlers separately on verification, minimum disclosure, attachments, preservation, legal hold, internal-notes discipline, and approved templates.
8. Run role-based simulations and require passing results before production access.
9. Publish a one-page outage procedure for form, email, SDK, AI agent, Copilot, routing, and Zendesk platform incidents.
10. Confirm supervisors know how to monitor queues, availability/capacity, SLA risk, AI escalations, Copilot adoption, and suspended tickets.

Reporting and monitoring

1. Create a simple reporting field map for KPIs, tags, channels, AI outcomes, time zone, and filters.
2. Build an executive dashboard: demand, channel mix, category mix, backlog, first reply, resolution, SLA attainment, reopen/repeat rate, and CSAT/BSAT where used.
3. Build an operations dashboard: queue age, unassigned work, capacity, status aging, pending/on-hold aging, priority, SLA risk/breach, and escalations.
4. Build a contact-form dashboard: submissions, success/failure, latency, duplicates, spam/CAPTCHA, attachment failure, category, and correlation IDs.
5. Use the AI-agent reporting dashboard for volume, contact reasons, containment, escalation, verified resolutions, and customer feedback. [ZD-65]
6. Use the Copilot Agent Productivity dashboard for adoption, accepted suggestions, procedures, and group-level usage.
7. Segment all performance by channel, platform, app version, locale, Issue Category, group, priority, human/AI outcome, and authenticated/anonymous status where privacy permits.
8. Account for AI-agent ticket reporting limits and Zendesk Explore retention. [ZD-66]
9. Set alerts for email auth, form/API failure, OAuth renewal, push failure, AI spend, harmful output, backlog, and SLA breach.
10. Validate each dashboard against a hand-checked ticket sample before sharing; annotate go-live and configuration-change dates.

UAT and production readiness

1. Create a UAT checklist for fields, rules, channels, language, AI, Copilot, reports, security, and rollback.
2. Test every broad website form category end to end through parser, requester email, subject, ticket body, routing, confirmation email, and closure.
3. Test email end to end: direct mail, forwarded mail, reply/CC, attachments, threading, authentication, AI reply, human escalation, after-hours, bounce, spam, and suspended ticket.
4. Test iOS and Android admin outcomes: channel key, authenticated user, metadata, push, AI answer, and Tier 2 handoff.
5. Run the AI evaluation set and log pass/fail, source used, defect, and resolution.
6. Run Copilot tests in auto-accepted Agent Workspace tickets for summary, reply guidance, procedures, actions, and dashboard events.
7. Run basic security tests: scope enforcement, malicious form payloads, rate limits, JWT expiry, user switching, and unauthorized ticket access.
8. Run basic privacy tests: notification redaction, requester deletion/forgetting, retention, legal hold, and AI logs.
9. Run load/resilience tests on the company form endpoint, OAuth renewal, Zendesk 429 handling, push bursts, and dependency timeouts without creating duplicate tickets.
10. Test every emergency stop and rollback; measure recovery time and verify no stuck tickets, duplicate replies, or orphaned conversations.
11. Complete accessibility review for the Help Center theme, email template, and admin-controlled support copy.
12. Obtain written sign-off from operations, mobile, web/integration, security, privacy/legal, knowledge, AI, reporting, and executive sponsor.
13. Complete language UAT for English, Spanish, and French where each is launched.
    • Test website intake and requester-language mapping.
    • Test email/dynamic content and help-center hierarchy/search.
    • Test both AI agents, native translation, mobile UI/push, accessibility/RTL, and legal escalation.
    • If nobody can validate a language, document the fallback process instead of claiming full support.

Cutover and rollback

1. Publish the cutover plan with timing, validation, rollback trigger, and rollback action.
2. Freeze nonessential changes and export the final baseline.
3. Confirm staffing, agent statuses, group membership, schedule, queues, auto-accept, staged capacity, and escalation contacts.
4. Verify help center activation, public/incognito access, sitemap, no Zendesk request link, no Web Widget, and approved article set.
5. Verify support-address forwarding, DNS authentication, templates, notifications, suspended-ticket view, and deliverability.
6. Deploy the form parser/OAuth client and submit one production canary for each broad category.
7. Activate the Messaging AI agent on iOS/Android channels and the Email AI agent on approved support addresses only; verify exclusions before the first live request.
8. Enable Copilot only for trained pilot groups and approved ticket conditions; verify the Auto Assist tag/trigger.
9. Confirm the first mobile production cohort produces expected auth, push, AI, and escalation events in Zendesk.
10. Run production smoke tests and compare actual ticket events, notifications, routing, AI/Copilot behavior, and dashboard data to expected results.
11. Open a launch channel for issues, decisions, and workarounds; keep customer PII out of it.
12. Trigger rollback if agreed thresholds are breached: disable form/SDK feature flags, deactivate affected AI channel/action, turn off email automation engine, revert rules/content, and communicate fallback.
13. Run one multilingual canary per launched locale through AI resolution and human takeover.

Hypercare and continuous improvement

1. Review form failures, suspended tickets, queues, unassigned work, SLA risk, AI escalations/resolutions, harmful output, and Copilot anomalies at least daily during hypercare.
2. Sample human-resolved, AI-resolved, AI-escalated, and Copilot-assisted tickets by category/channel/language; log accuracy and process defects separately.
3. Review contact-form abuse controls and false positives without weakening protection for convenience.
4. Review AI resolution-tier usage and allowance weekly; investigate spikes and dispute incorrect tier assignments through the documented process.
5. Review Copilot exposure, acceptance, edit/rejection, procedure gaps, and agent feedback weekly; retire low-value or unsafe suggestions.
6. Update knowledge from failed searches, repeated human replies, AI fallbacks, and Copilot gaps; re-run affected AI tests before publication.
7. Review intelligent-triage topic/entity accuracy monthly and after material product or policy changes.
8. Review triggers, automations, macros, views, queues, SLAs, skills, OAuth clients, webhooks, agents, and AI/Copilot access quarterly.
9. Patch both Messaging SDKs on a defined cadence after release-note review and regression testing; rotate APNs/FCM/JWT/OAuth secrets before expiry.
10. Run 30-, 60-, and 90-day outcome reviews against baseline; approve the next use case only after launch controls are stable.

Final acceptance gates