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. Define service hours, supported languages, customer geographies, holidays, after-hours behavior, and emergency exceptions.
3. Inventory all current intake paths.
4. Map every request type from receipt to final disposition, including owner, classification, priority, SLA, required data, and escalation.
5. Create a production-change process with requests and approvals. [PT-07]

Subscription and environment

1. Verify the contract shows Zendesk Suite Professional, Zendesk Copilot, and the current Advanced AI-agent/resolution allowance needed for launch.
2. Confirm the account is on the current post–March 10, 2026 AI-agent architecture and note any account-specific rollout banners or migration notices. [ZD-06]
3. Record the account owner, billing admins, contract renewal date, data-hosting region, subdomain, brand limit, agent seats, light-agent seats, and resolution allowance.
4. Create separate nonproduction channels rather than assuming a native sandbox exists.
   • Dedicated test support address.
   • Dedicated iOS and Android test Messaging channels and channel keys.
   • Internal-only knowledge articles or test brand if available.
   • Test user accounts and closed agent group.
   • Feature flags in both mobile apps and website integration.
5. Confirm Advanced AI-agent workspace permissions for the AI owner and backup; do not give broad access to every agent.
6. Confirm Explore access for report builders and dashboard viewers.
7. Disable unlicensed or unused products and remove trial integrations so they cannot create tickets or expose customer data.
8. Subscribe administrators to Zendesk status and release notifications; schedule a final release-note check immediately before production cutover.

Security, privacy, and compliance

1. Open Admin Center → Security overview and resolve every relevant recommendation displayed for the account. [ZD-07]
2. Require SSO through the company identity provider where available; test the documented SSO bypass/recovery process with a tightly controlled break-glass admin. [ZD-08]
3. Require two-factor authentication for all team members; download and review the 2FA status report before launch and quarterly. [ZD-09]
4. Limit admins to the minimum necessary people; remove dormant agents immediately and review seats/access monthly.
5. Set the security notification email to a monitored security mailbox and document the response owner.
6. Use a distinct OAuth client for every integration; never use an API token for this new 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.
7. Store OAuth client secrets, mobile JWT signing keys, APNs credentials, FCM service-account material, and webhook secrets only in an approved secret manager.
8. Decide whether agents may use the Zendesk Support mobile app; disable access if it is not required.
9. Document data categories collected in each channel, lawful purpose, data owner, retention period, access boundary, export process, and deletion process.
10. Configure ticket, attachment, end-user, and AI-agent-ticket retention/deletion schedules approved by legal and security; test on nonproduction data before activation. [ZD-11]
11. Define the process for access, correction, export, deletion/forgetting, legal hold, and preservation requests; ensure legal holds override routine deletion.
12. Remove unnecessary personal data from email notifications and webhook payloads; use internal notes for internal-only context.
13. Decide attachment handling per channel.
    • Messaging does not currently support private attachments; do not solicit secrets, credentials, government IDs, legal evidence, or other sensitive files in mobile messaging. [ZD-12]
    • For website/email attachments, test private-attachment behavior, requester access, notification content, and retention before enabling.
14. Review Zendesk’s AI-agent data processing, DPA, subprocessors, and generative-reply privacy documentation with privacy counsel. [ZD-13]
15. Create an incident runbook for credential leakage, unauthorized disclosure, prompt injection, harmful AI response, compromised help-center content, spam attack, and form abuse.

Brand, identity, and localization

1. Create or confirm the single production brand; set its name, logo, favicon, colors, default language, host mapping, support addresses, and help-center association.
2. Choose and validate the Zendesk subdomain before launch; document ownership and renewal of any custom support/help-center domain.
3. Map a branded help-center host such as help.example.com, validate DNS and SSL, and confirm both the custom and Zendesk URLs redirect/canonicalize correctly. [ZD-14]
4. Approve customer-visible names for the human support team, messaging AI agent, email AI agent, and sender identity; clearly identify automated agents as automated.
5. Approve tone, terminology, capitalization, prohibited phrases, signature style, legal footer, privacy notice, and accessibility language.
6. Choose supported locales and fallback language; prepare dynamic content, email copy, mobile strings, system replies, macros, and knowledge translations before enabling a locale.
7. 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. Build a language register from customer and market data: locale/code, volume, channel, use cases, legal risk, AI-agent support, conversation-translation support, help-center availability, SDK UI support, reviewer, and launch tier. [ZD-71]
2. Define and publish the promise for each locale: full self-service plus translated human support, AI-only with translated escalation, human response after translation review, or unsupported. Do not advertise a locale until every required layer in the coverage table passes.
3. Set the account default language and activate every approved additional language in Admin Center. Enabling a language is only configuration; it does not translate email notifications, rules, macros, knowledge, or app-owned strings. [ZD-70]
4. Add an explicit preferred-language selector to the company-owned website form, pass the normalized locale through the backend, store the submitted value, and set the requester language through an approved rule/API mapping. Treat browser/device locale and AI detection as hints when they conflict with an explicit choice.
5. Enable Copilot intelligent-triage language detection on the intended channels; measure accuracy by language and channel before using it in triggers, views, or reports. Create an Unknown/Needs review fallback and never route to nonexistent language-skilled agents. [ZD-52]
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 to accept or correct the detected language, turn translation on/off per conversation, inspect Show original and Show translation, and escalate when meaning is ambiguous. Prohibit copying customer data into consumer translation tools. [ZD-81]
9. Create an approved, case-sensitive do-not-translate glossary for brand/product names, URLs, commands, policy terms, agency names, legal citations, abbreviations, and identifiers; assign a glossary owner and change process. [ZD-72]
10. Replace customer-facing email, trigger, automation, macro, status, and system-message text with dynamic-content placeholders; create and activate a reviewed variant for every enabled language and test the default-language fallback. [ZD-73]
11. Enable help-center languages separately from Support languages and set the translated help-center name. Verify URL locale, browser/session/profile preference behavior, locale switcher, and fallback to the default help-center language. [ZD-74]
12. Translate the help-center hierarchy in order—category, section, then article—plus theme snippets, navigation, metadata, and search terms. Do not publish orphan translations whose parent pages are missing. [ZD-75]
13. Use AI article translation only as a draft. Apply the glossary, retain the source/version relationship, obtain a qualified review for high-impact content, add any required AI-translation notice, and note that AI article translation does not support content blocks. [ZD-76]
14. Assign an owner, reviewer or vendor, locale status, last source revision, translation revision, review date, and staleness rule to every translated article and dynamic-content item; unpublish stale translations when meaning materially changes. [PT-08]
15. Activate only languages listed as supported for current AI-agent use cases/generative replies/agentic AI; test native script, dialect, formality, RTL/vertical text where applicable, mixed-language messages, language switching, transliteration limitations, and unsupported-language fallback. [ZD-78]
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 every supported language after knowledge, instructions, procedure, model, or system-reply changes.
17. Localize and test app-owned iOS and Android support-entry strings, SDK overrides, notification copy, accessibility labels, error states, dates/numbers, truncation, pluralization, and RTL. The SDK’s built-in UI strings do not translate AI, agent, or integration-authored conversation content. [ZD-79] [ZD-80]
18. Commission native/qualified language UAT for every launched locale because the agent team cannot validate fluency internally. Test ordinary support, slang/typos, mixed language, ambiguous dates/numbers, attachments, AI resolution, human takeover, translated reply, and high-risk escalation; store reviewer and evidence.
19. Report by requester/detected language: volume, AI resolution, escalation, translation use, first reply, resolution, reopen, CSAT, error/complaint rate, and fallback rate. Sample translations monthly and pause a locale when quality or reviewer coverage falls below its launch threshold.
20. Apply the Opus language checklist: one supported-language list controls AI agents, Help Center, mobile SDK strings, dynamic content, macros, triggers, automations, CSAT, and legal intake copy.
21. Set every agent's Support profile language to the agents' working language and train agents to write short, literal sentences before translation; no idioms, internal shorthand, or mixed instructions.
22. Decide whether the "Translated by AI" disclosure stays visible on async replies; document the policy owner because hiding it is a customer-facing disclosure choice.
23. Define escalation behavior for languages the AI agent can answer but human agents cannot realistically handle after handoff.
24. Test translation against right-to-left languages, non-Latin scripts, romanized non-Latin input, long messages, rich text, PII-heavy messages, and mixed-language threads on both mobile platforms.

People, groups, roles, and skills

1. Create the minimum operational groups, with named primary and backup owners.
   • Customer Support.
   • Trust & Safety / Legal Intake.
   • Partnerships / Business Development.
   • Zendesk Administration / Integration Monitoring.
   • Optional product groups only where separate ownership truly exists; do not create language groups without language-qualified staff.
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. Do not create language skills: the human agents do not possess them. Create skills only for verified expertise that improves assignment, such as iOS, Android, DMCA, law enforcement, privacy, security, or partnerships.
5. Assign expertise skills only to qualified agents, define backups, and configure a skills timeout so work cannot remain stranded; translation is an Agent Workspace aid, not an agent skill. [ZD-16]
6. Create test users for anonymous contact intake, authenticated app users, user switching, duplicate-email cases, unsupported languages, suspended users, and each legal intake category.
7. 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. Create a required controlled Request category dropdown as the source of truth, not free-form tags.
   • Customer support.
   • Law-enforcement request.
   • DMCA/copyright request.
   • Privacy/data-rights request.
   • Security/vulnerability report.
   • Partnership/business inquiry.
   • Press/media.
   • Other legal or business request.
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. Approve the form’s categories, required fields, conditional fields, instructions, privacy notice, prohibited content warning, and confirmation text with legal and security.
2. Collect the minimum data necessary for each category; do not require legal-request details from partnership users or vice versa.
3. Use server-side schema validation and normalization for category, name, email, organization, jurisdiction, reference number, subject, description, URLs, 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 token expiry/renewal, secret rotation, revocation, secure storage, timeouts, retry with backoff, and handling for 401, 403, 409, 422, 429, and 5xx responses.
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 category deterministically.

   Website contact-form category and control mapping

   Category	Group / priority	Required controls
   Law enforcement	Trust & Safety / Legal · High or policy-driven	no_ai_reply; verify authority; restricted notifications; counsel procedure
   DMCA / copyright	Trust & Safety / Legal · Normal/High by deadline	no_ai_reply; statutory-data checklist approved by counsel
   Privacy / data rights	Privacy / Legal · High by jurisdictional clock	no_ai_reply; identity verification; legal-hold check
   Security report	Security · Urgent/High by severity	no_ai_reply; secure disclosure path; no broad email notification
   Partnership	Partnerships · Normal	Structured company/URL fields; acknowledgement; qualification macro
   General support	Customer Support · Normal	Product/platform metadata; normal routing and Copilot eligibility

10. Set ticket source fields/tags, brand, requester, subject prefix, category, group, priority, comment, attachments, and correlation ID in the API payload; do not rely on agents to re-key form data.
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. Send one branded confirmation containing the Zendesk reference number, the category received, a safe expectation statement, and a warning not to email additional sensitive data unless instructed.
13. Decide whether to create/verify requester profiles server-side or use the Requests API; if using anonymous Requests API, explicitly test the 2026 email-verification/suspended-ticket workflow and rate limits. [ZD-22]
14. Build monitoring for submission volume, success/failure rate, latency, CAPTCHA failures, 429s, OAuth failures, attachment failures, duplicates, and Zendesk ticket-creation confirmation.
15. Create a dead-letter/replay process that preserves idempotency and does not expose sensitive payloads in ordinary logs.
16. Test the form with keyboard only, screen reader, mobile browsers, long names, international characters, RTL text, large payloads, malicious HTML, script strings, duplicate clicks, network interruption, and expired OAuth credentials.

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 the Submit a request link/helper from every help-center template and remove any new-request page links from article, search, error, header, and footer templates. [ZD-30]
3. Remove the sign-in/request-history UI if the customer portal is not part of the design; test direct URLs so hidden navigation does not create a false security assumption.
4. Do not automatically embed the Messaging Web Widget in the help center and do not install it on the website; messaging is mobile SDK only. [ZD-31]
5. Disable community and article comments unless there is a staffed moderation and response process.
6. Customize the theme for brand, responsive design, keyboard navigation, visible focus, color contrast, skip links, semantic headings, alt text, 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. Assign every article an owner, reviewer, approval date, review frequency, product/version 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 and test every article on desktop/mobile, in help-center search, from AI-agent answers, and through 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. Remove the request-form helper and fields from new_request_page.hbs; render a localized explanation/link to the company-owned contact form instead. Test /hc/{locale}/requests/new, direct ?ticket_form_id=… URLs, article request callouts, search/error pages, notification links, and signed-in/signed-out states after every theme update.
16. Decide and document the End users → Anybody can submit tickets setting.
    • If new unsolicited email senders must be accepted, keep the account open, retain anonymous-request verification, suppress the Zendesk form in the theme, and document that theme suppression is a presentation control.
    • If only pre-provisioned users may email, close Support and test company-form API creation, mobile identities, new senders, CCs, replies, suspended tickets, and user provisioning before launch.

iOS Messaging SDK

1. Create a production iOS Messaging channel and a separate test channel; associate the correct brand and record each channel key/environment.
2. Confirm the app’s deployment target supports the current SDK. As of iOS SDK 2.40.0 (July 21, 2026), the minimum is iOS 16. [ZD-32]
3. Pin an exact, currently supported SDK version through Swift Package Manager or the approved dependency manager; do not use a floating “latest” dependency. [ZD-33]
4. Initialize the correct channel key once, handle initialization failure, and keep test/prod selection behind environment configuration—not user input.
5. Use authenticated messaging if the app has authenticated users.
   • Generate signed JWTs only on the company backend with stable unique external IDs.
   • Set the AuthenticationDelegate before SDK initialization and refresh expired JWTs without interrupting the conversation. [ZD-34]
   • Log out/invalidate on app sign-out, account switching, deletion, and compromised sessions.
   • Prevent an anonymous conversation from being created before authentication completes.
6. Configure APNs credentials, token registration/update, foreground/background handling, notification permissions, and deep linking to the correct conversation. [ZD-35]
7. Define the support entry point, new-conversation behavior, conversation-list behavior, unread badge, back/dismiss navigation, and re-entry after app termination.
8. Configure colors, title, avatar, customer message colors, actionable colors, status-bar behavior, dark mode, and Dynamic Type; verify contrast in every state.
9. Implement supported Zendesk events for messaging open/close, conversation start/open, messages shown, unread count, failed messages, connection changes, AI-to-human request, assignment, and notification open.
10. Add approved messaging metadata such as app version, OS, locale, product area, subscription tier, and current screen; never send secrets or unnecessary PII.
11. Decide whether Zendesk internal SDK analytics remain enabled; update privacy disclosures and consent behavior accordingly.
12. Review Zendesk’s included privacy manifest and add every optional data type collected by the app to the app-level privacy declarations and App Store disclosures. [ZD-36]
13. Test VoiceOver, Dynamic Type, keyboard/switch controls where applicable, RTL, all enabled locales, offline/retry, slow network, attachment errors, denied permissions, expired JWT, user switching, reinstall, and app upgrade.
14. Release behind a remote feature flag; stage through internal/TestFlight cohorts and retain an immediate disable path that does not require a new App Store release.

Android Messaging SDK

1. Create a production Android Messaging channel and a separate test channel; associate the correct brand and record each channel key/environment.
2. Confirm prerequisites and pin an exact supported SDK version. As of Android Messaging SDK 2.41.0 (July 29, 2026), the current minimum remains API 21 with Java 8; Zendesk has announced that the next major version will require API 24. Verify release notes again at build freeze. [ZD-37] [ZD-82]
3. Add the approved Zendesk Maven repository and dependency; verify dependency lockfile, R8/ProGuard behavior, APK/AAB size, and supply-chain scanning.
4. Initialize the correct channel key in the Application lifecycle, handle failure, and keep test/prod selection in protected build/environment configuration.
5. Use authenticated messaging if the app has authenticated users.
   • Set the authentication delegate before initialization and call loginUser() with a backend-issued JWT.
   • Refresh expired/invalid JWTs and handle AuthenticationFailed events without creating a duplicate anonymous user.
   • Invalidate/logout on sign-out and account switching. [ZD-38]
6. Configure FCM v1 service-account fields in Admin Center, register/update device tokens, and implement either Zendesk’s default messaging service or a tested custom FirebaseMessagingService. [ZD-39]
7. Implement Android 13+ notification permission handling, foreground/background delivery, multiple-notification behavior, tap/deep-link behavior, and token refresh.
8. Define support entry point, conversation list/new conversation behavior, unread badge, Back navigation, process death, activity recreation, multi-window, and deep links.
9. Configure theme colors, dark mode, font scaling, TalkBack labels/order, RTL, and large-screen layouts; verify contrast and touch targets.
10. Implement supported events and app analytics for open/close, conversation lifecycle, unread count, failures, connection state, AI-to-human request, assignment, and notification open.
11. Add only approved metadata and decide whether Zendesk internal analytics—enabled by default in current Android SDKs—remain enabled. [ZD-40]
12. Test TalkBack, font scaling, RTL/locales, offline/retry, Doze/battery optimization, network switching, denied permissions, expired JWT, user switching, attachment errors, process death, reinstall, and upgrade.
13. Release behind a remote feature flag through internal testing and staged Play rollout; retain a server-side disable path.

Advanced AI agents — Messaging and Email

1. Identify AI use cases from real or representative demand; launch only high-volume, low-risk, well-documented use cases with a clear successful outcome. [PT-04]
2. Create a written AI policy: in-scope tasks, prohibited topics/actions, human-request handling, uncertainty threshold, privacy rules, approved knowledge, languages, tone, and incident owner.
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 concise, non-conflicting instructions for terminology, source grounding, disclosure, uncertainty, privacy, response length, links, and prohibited behavior; test every instruction before activation. [ZD-44]
9. Create generative procedures only after the underlying human process is approved.
   • State trigger/use case, required facts, 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.
   • Version, owner, test, approve, activate, monitor, and retain rollback history. [ZD-45]
10. Build 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.
11. Connect the Messaging AI agent as default responder only to the iOS and Android production channels after test-channel approval.
12. 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]
13. Verify the email AI agent strips quoted history/signatures correctly, asks useful clarifying questions, handles sequential procedures, and escalates multiple or complex requests safely. [ZD-48]
14. 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, credentials, sensitive attachments, legal categories, prompt injection, knowledge poisoning, and requests to ignore policy.
    • Email quoting/signatures/footers/attachments and mobile metadata/authentication cases.
15. Set acceptance thresholds before activation: factual correctness, citation/source fit, procedure completion, zero unauthorized actions, zero autonomous legal replies, escalation precision/recall, response latency, and language quality.
16. Run pilot testing in closed channels, then a small production cohort; review every contained/resolved conversation during the initial pilot. [PT-05]
17. Configure and monitor current automated resolution tiers/allowance; set usage notifications, billing owner, dispute/review process, and budget guardrail. [ZD-49]
18. Document emergency stops: deactivate affected channels/agent, turn off the email automation engine, disable actions, disable mobile feature flags, and revert the last procedure/knowledge change.

Zendesk Copilot

1. Open Admin Center → AI overview and inventory every Suite AI and Copilot feature, its default state, owner, eligible group, data source, risk, test status, and rollout decision. [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 in workflows only after measuring classification accuracy by channel/category/language; keep deterministic contact-form categories authoritative.
4. Train custom topics for the core request taxonomy: account_access, app_bug_report, dmca_intake, partnership_request, law_enforcement, privacy_request, and billing_payment; keep the form's explicit request type as the higher-trust value when the two 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 mappings for useful structured values such as order IDs, case numbers, app versions, device platform, legal reference numbers, jurisdiction, and urgency; exclude sensitive values that should not be copied into broadly visible fields.
7. Turn on ticket summaries for the pilot group; verify summaries distinguish requester statements from verified facts and do not replace reading sensitive ticket history.
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 communication guidelines for Copilot rewrite tools: greeting style, signature handling, banned promises, brand terminology, privacy language, and professional tone; test that rewriting does not create duplicate signatures or commitments.
14. Turn on Auto Assist for a dedicated pilot group and enable it only on intended tickets using a documented trigger/tag such as 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.
    • Assign brand, owner, review date, version, test cases, and rollback.
    [ZD-55]
16. Review, edit, test, and explicitly publish AI-generated procedure drafts; never treat generated drafts as approved policy. [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; verify suggestions are not offered to excluded groups/tickets.
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. 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]
21. Configure the Copilot Agent Productivity dashboard and establish weekly review of exposures, acceptance, edits/rejections, procedure usage, adoption by group, and anomalies. [ZD-59]
22. Enable Admin Copilot only with a two-person review practice for production changes; inspect payload previews, document approval, and independently test the resulting configuration.
    • 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.
23. Review Admin Center Home recommendations weekly during build for unused triggers, macro cleanup, automation risks, and Auto Assist performance; approve changes manually instead of applying recommendations blind.
24. Validate the full Copilot workspace stack in UAT: summaries, sentiment/tone analysis, suggested replies, quick answers, similar tickets, Auto Assist procedures, action approvals, merge suggestions, and live translation on escalated messaging and email threads.

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. Choose push versus pull routing. For human escalations across email/API/messaging, configure omnichannel routing if agents should receive work automatically.
3. Configure agent statuses, email capacity, messaging capacity, reassignment timing, auto-accept decision, focus mode decision, and skills timeout.
4. Create the minimum queues and order them by explicit business impact: verified urgent security/legal, AI messaging escalations, SLA risk, standard support, partnerships. [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, document purpose, owner, inputs, exact conditions, actions, ordering dependency, anti-repeat condition, test cases, and rollback. [PT-06]
7. Build deterministic intake triggers first: normalize source/category/platform, apply tags, set priority, assign group, set skills, then notify.
8. Build high-risk guardrails before general AI/Copilot rules; a sensitive category must receive no_ai_reply and the legal/security group before any AI eligibility rule can match.
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 a collision test for every rule stack: one test ticket per channel/category/priority/language plus combined conditions; inspect the full event log and all notifications.
14. Export or document the final triggers, automations, SLAs, views, macros, fields, forms, groups, skills, 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 request 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 data dictionary for every KPI, field, tag, status, channel, AI outcome, time zone, filter, exclusion, owner, and refresh cadence.
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 and conversation logs for volume, contact reasons/use cases, knowledge performance, containment, escalation, verified resolutions, resolution tier, customer feedback, and conversation journey. [ZD-65]
6. Use the Copilot Agent Productivity dashboard for Auto Assist exposure/acceptance, procedure use, suggested first replies, similar tickets, merge suggestions, quick answers, macros, and writing tools by group/agent/channel.
7. Segment all performance by channel, platform, app version, locale, request category, group, priority, human/AI outcome, and authenticated/anonymous status where privacy permits.
8. Account for reporting limits: AI-agent-only tickets have special API/Explore behavior, and standard Explore retention is limited; design long-term exports if trend history must exceed Zendesk retention. [ZD-66]
9. Define alert thresholds and recipients for email forwarding/authentication, contact-form/API failure, OAuth renewal, SDK push failure, AI resolution spend, AI escalation spike, harmful output, routing 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 traceable test matrix linking every requirement, field, rule, channel, locale/translation, AI behavior, Copilot feature, report, security control, and rollback to a test and owner.
2. Test every website form category end to end through Zendesk assignment, notification, SLA, views, reports, requester reply, 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 on supported OS versions/devices with authenticated and anonymous users, logout/switch, push, unread count, attachments, network failure, accessibility, locales, AI resolution, and human escalation.
5. Run the full AI evaluation set and document pass/fail, observed output, source/procedure/action used, reviewer, defect, and resolution.
6. Run Copilot tests in real Agent Workspace tickets: triage classification, summary, first reply, similar tickets, merge, writing, Auto Assist procedure, action, source, group access, and dashboard event.
7. Run security tests: secret exposure, scope enforcement, malicious payloads, injection, stored XSS, attachment malware, rate limit, replay, JWT expiry, user switching, unauthorized ticket access, and webhook verification.
8. Run privacy tests: data minimization, notification redaction, sensitive attachment path, 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 website form, help center theme, email template, and both SDK experiences.
12. Obtain written sign-off from operations, mobile, web/integration, security, privacy/legal, knowledge, AI, reporting, and executive sponsor.
13. Obtain qualified-language UAT sign-off for every launched locale across website intake, requester-language mapping, email/dynamic content, help-center hierarchy/search, both AI agents, native human translation, mobile UI/push, accessibility/RTL, and legal escalation. The monolingual agent team cannot self-certify translation quality.

Cutover and rollback

1. Publish a timed cutover plan with owner, prerequisite, action, validation, rollback trigger, rollback action, and communication for every step.
2. Freeze nonessential configuration and content changes; export/document the final baseline.
3. Confirm staffing, agent statuses, group membership, skills, schedule, holidays, queues, capacity, and escalation/on-call contacts.
4. Verify help center activation, host mapping, SSL, 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 website form endpoint/OAuth client and release the form behind a feature flag; submit one production canary for each 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. Release mobile support feature flags to the first production cohort; monitor initialization, auth, push, conversation, AI, and escalation events.
10. Run production smoke tests and compare actual ticket events, notifications, routing, AI/Copilot behavior, and dashboard data to expected results.
11. Open a staffed launch channel and record issues, severity, owner, workaround, decision, and resolution; never paste customer PII into the launch channel.
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 production multilingual canary per launched locale through AI resolution and human takeover; verify the original remains visible, both directions translate correctly, localized notifications/content render, and the unsupported/high-risk fallbacks stop substantive automation.

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