# Migrate from Zendesk to AI: a support migration playbook

> Migrate from Zendesk to AI with a playbook: audit content, export data, map macros, parallel run, and cut over without losing history.

- **Published:** July 15, 2026
- **Category:** Guides
- **Author:** Udit Goenka
- **URL:** https://communicate.so/blog/migrate-from-zendesk-to-ai

---

> **TL;DR:** To migrate from Zendesk to AI means moving from a ticket-and-macro helpdesk to an AI-agent-first setup, where an agent answers the repetitive majority from your own knowledge and people handle the rest. This playbook walks the whole move in order: audit your content and macros, export your data, turn macros into agent knowledge, connect your data sources, run the two systems in parallel, cut over, and measure the result. It stays fair about where a legacy helpdesk like Zendesk is genuinely strong, so you keep what works instead of throwing it away. Done carefully the migration is low-risk, because the parallel run proves the agent before you trust it, and you never lose your history in the process.

---

Most migration guides sell you the destination and skip the journey. They promise an AI agent that resolves everything, then leave you staring at years of tickets, hundreds of macros, and a live queue you cannot pause while you rebuild it. The gap between the pitch and the actual move is where migrations stall.

**This playbook takes the honest path through that gap.** Migrating from a legacy helpdesk to an [AI agent](/ai-agents) is not a rip-and-replace, it is a sequence: understand what you have, move it cleanly, teach the agent from it, prove the agent in parallel, then cut over on evidence. Each step exists to lower the risk of the next one, so you are never betting your support queue on a system you have not tested.

It is written for the person who owns the decision: a support lead, an ops owner, or a founder weighing whether the switch is worth the effort. It assumes a Zendesk-style helpdesk as the starting point, because that archetype, tickets, macros, triggers, and a help center, is the one most teams are leaving. If you are still deciding rather than executing, the [Zendesk AI alternative comparison](/blog/zendesk-ai-alternative) is the companion read, and this post is the how-to once you have chosen to move.

## What migrating from Zendesk to AI actually means

The phrase gets thrown around loosely, so it is worth pinning down before you plan anything. Migrating to AI is not swapping one inbox for another that happens to have a bot bolted on. It is a change in how the work gets done, from routing every ticket to a person to letting an agent resolve the repetitive majority and escalating the rest.

**A legacy helpdesk is built around the ticket.** Every question becomes a ticket, a person reads it, applies a macro or writes a reply, and closes it. Automation exists, but it is rule-based: triggers, macros, and routing that a human still drives. 

The model assumes a person is in the loop on almost every conversation, which is why headcount scales with volume.

**An AI-agent-first setup inverts that assumption.** The default handler is an [AI agent](/ai-agents) that reads the question, retrieves the relevant facts from your connected knowledge, and answers directly, so a person only enters when the agent should not answer alone. The queue still exists for the hard cases, but it is smaller, because the documented and repetitive questions never reach a human in the first place.

The migration, then, is the work of moving from the first model to the second without losing what the first one held. Your tickets, your macros, and your help center are all knowledge, just knowledge shaped for people rather than for retrieval. The playbook is mostly about reshaping that knowledge so an agent can use it, then proving it works before you rely on it.

It helps to name the destination precisely. In an agent-first setup, the agent grounds its answers in the [data sources you connect](/data-sources) rather than a general model's guesswork, and it hands off when retrieval finds nothing, so a wrong-but-fluent answer is designed out rather than hoped away. That grounded, escalation-first behavior is the whole reason the migration is worth doing, and it is the standard to hold your new setup to.

## Where a legacy helpdesk like Zendesk is genuinely strong

A fair migration starts by admitting what you are leaving behind is good at some things. Zendesk did not become the archetype by being bad, and pretending otherwise leads you to discard features you will miss. Knowing its real strengths tells you what your new setup has to match, not just what it can improve on.

**Mature ticketing and workflow are the clearest strength.** A legacy helpdesk has spent years refining triggers, SLAs, routing rules, and reporting, and that depth is real. If your support runs on complex escalation paths, tiered teams, and detailed SLA tracking, an agent-first tool has to cover those workflows or the migration trades one problem for another.

**Breadth of channels and integrations is the second.** Established helpdesks connect to a long list of channels and third-party apps out of the box, which a newer tool may not match. This is exactly where you have to be honest about your own needs, because a tool like Communicate runs only a web widget, live chat, and email, so if you depend on channels beyond those, that gap is a real reason to stay or to split your setup.

**The macro library is a strength hiding as a chore.** Years of macros are a distilled record of how your team answers, and that is precisely the material an agent learns from best. So the right frame is not that macros are legacy baggage, it is that they are training data you already paid to create, which the [AI support agent implementation guide](/blog/ai-support-agent-implementation) treats as a head start rather than a cleanup task.

The honest limit worth stating is that none of these strengths is free. Deep workflow power comes with configuration overhead, broad channel support comes with cost, and a large macro library comes with drift, where old macros quietly describe flows that changed. The migration is a chance to keep the strengths and shed the drift, but only if you audit rather than lift and shift.

## Step 1: Audit your content and macros

![Line-art diagram of support tickets and macros being sorted into covered, stale, and missing knowledge for an AI agent](https://communicate.so/blog/migrate-from-zendesk-to-ai-content-audit.png)

You cannot migrate what you have not measured, so the first step is an honest inventory of what your helpdesk actually knows. The goal is to separate the knowledge worth moving from the noise worth leaving, before you touch an export. Skip this and you carry years of contradictions straight into the agent.

The audit is a matching exercise between demand and supply. Demand is what customers actually ask, which your ticket history records. Supply is what your macros and help center actually answer, and where the two line up cleanly is where the [AI agent](/ai-agents) will resolve fastest once it is trained.

Run it as a concrete sequence rather than a vague review. The steps below turn a fuzzy sense that your content is messy into a ranked list of what to migrate, rewrite, and retire, which is the output the next steps need.

- 1. Pull your highest-volume ticket themes and list them by frequency, so you know which questions matter most.

- 2. Inventory every macro and tag each as current, stale, or duplicate, noting which underlying question it answers.

- 3. Map each high-volume theme to the macro or help-center article that answers it, and flag themes with no clear answer.

- 4. Mark stale content that describes a price, flow, or policy that has since changed, because that is worse than a gap.

- 5. Rank the gaps and stale items by ticket volume, so you fix the highest-impact knowledge first.

Two patterns show up in almost every audit. The first is the silent gap, a high-volume question your team answers well but no macro or article records, because the knowledge lives in senior agents' heads. The second is the stale macro, technically present but describing something that changed, which an agent will confidently repeat unless you catch it, the exact risk the [AI support agent implementation guide](/blog/ai-support-agent-implementation) warns about.

Do not aim for a perfect audit before moving on. Aim to cover your top themes by volume, because a small number of question types usually drives most of your traffic. The long tail gets closed later using the agent's own escalation data, which points straight at the next thing to write.

## Step 2: Export your data from the legacy helpdesk

![Line-art illustration of tickets, macros, and help-center articles exporting cleanly out of a legacy helpdesk into a portable archive](https://communicate.so/blog/migrate-from-zendesk-to-ai-data-export.png)

With the audit done, you know what is worth moving, and now you get it out. Exporting matters for two separate reasons: you need the content to train the agent, and you need the history preserved so migrating does not mean losing years of record. Treat those as two goals, because they have different destinations.

**Your help center is the cleanest export.** Published articles are already written to answer customer questions, so they are the highest-value, lowest-noise material to feed an agent. Most helpdesks let you export articles in a structured form, and Zendesk documents its own export options on [its site](https://www.zendesk.com), which is the authority to check for the current mechanics rather than any third-party summary.

**Macros are the second export, and the highest-value one.** Each macro is a canned answer your team trusted enough to reuse, which makes the library a compact map of your best replies. Export them as text you can review, because the next step turns them into agent knowledge, and you want the wording in front of you when you do.

**Ticket history is the third, and it is about record, not training.** You rarely feed raw tickets to an agent, because they are noisy and full of one-off context, but you do want them archived so nothing is lost. Export them to your own storage in a durable format, and note that data-protection rules like the [GDPR](https://gdpr.eu) govern how you keep and eventually delete personal data, so plan retention deliberately rather than hoarding everything forever.

A practical warning on exports: they are only as useful as they are complete and readable. Check that attachments, links, and formatting survive the export, because an article that loses its structure becomes harder to chunk for retrieval later. Verify a sample by hand before you trust the whole batch, since a silent formatting break is easy to miss and expensive to discover after cutover.

One more honest note on ownership. A migration is the moment to confirm you can get your data out of the new tool too, not just the old one, so you are not trading one lock-in for another. Communicate supports self-serve export and cascading delete, so the [data you connect](/data-sources) stays yours to remove or take elsewhere, which is a fair question to ask any vendor before you commit.

## Step 3: Map macros to knowledge and connect data sources

![Line-art diagram of macros transforming into answerable knowledge-base articles and connecting to an AI agent as data sources](https://communicate.so/blog/migrate-from-zendesk-to-ai-macro-mapping.png)

This is the step where the migration changes shape, from moving data to teaching an agent. A macro and an agent-ready article look similar but serve different readers, so the mapping is a rewrite, not a copy. Get this right and the agent inherits your team's best answers; get it wrong and it inherits their worst habits.

**A macro is written for an agent who already has context.** It often assumes the human knows which product, which plan, and which situation applies, so it skips the framing a customer would need. An [AI agent](/ai-agents) retrieves passages in isolation, so each answer has to stand on its own, which means the mapping adds back the context the macro left out.

**Lead with the question a customer would actually type.** Retrieval matches the customer's phrasing against your text, so an article titled around the real question retrieves better than one named after an internal feature. Write the heading the way a frustrated customer would search, and include their words, so "my card was declined" and "payment failed" both find the same answer.

**Make each article self-contained and single-topic.** A macro that bundles billing, refunds, and cancellation into one block gives retrieval a muddy target, so split it into focused articles that each answer one thing plainly. This structural discipline is also what makes content chunk well for retrieval, a point the [how to build an AI customer support agent](/blog/how-to-build-an-ai-customer-support-agent) guide treats as the core of the knowledge layer.

Once the articles are shaped, you connect them as [data sources](/data-sources), which is the fast part. Ingestion itself takes an afternoon, because the real work was the rewrite that came before it. The agent then answers by retrieving from what you connected rather than from a general model, so the quality of this step sets the ceiling on every answer it will ever give.

It is worth being clear about what the model does and does not decide here. Communicate runs a single model, gpt-4o-mini through [OpenRouter](https://openrouter.ai), with response and prompt caching to keep cost and latency down, which is a deliberate simplicity. The content you connect drives answer quality far more than the model badge, so one well-tuned model on clean knowledge beats a model-picker sitting on messy data.

## Step 4: Parallel run before cutover

![Line-art illustration of an AI agent drafting answers alongside a live helpdesk queue during a parallel evaluation period](https://communicate.so/blog/migrate-from-zendesk-to-ai-parallel-run.png)

This is the step that turns migration from a leap into a controlled test, and it is the one most teams skip to their cost. Running the agent in parallel means it works your real queue without customers depending on it yet, so you see how it performs on genuine questions before you trust it live. The parallel run is your safety net, and it is cheap insurance against a bad cutover.

**Test with real questions, not clean ones.** Demos use the three tidy questions the agent answers perfectly, but customers send half-typed, misspelled, context-free messages, and those expose the gaps. Pull the ugly questions from your own ticket history and run them at the agent, because they are the ones that decide whether it is ready.

Score each answer on three axes rather than a gut feeling. Was it factually correct against your own docs, did it match your voice and tone, and did it escalate cleanly when it should not have answered at all. The third axis matters most, because an agent that guesses on an out-of-scope question fails no matter how fluent it sounds.

Set a go or no-go bar before you see the results, so a fluent but wrong answer counts as a failure rather than a maybe. A common bar is high factual accuracy with zero invented answers on out-of-scope questions, judged on your own test set. Communicate's one-time $1 activation includes 100 test credits for exactly this kind of trial, so you can run the ugly questions through the real agent before committing to [credit-based usage](/pricing).

The honest reason to insist on this discipline is the failure rate of AI projects that skip it. RAND's 2025 review of more than 2,400 enterprise AI initiatives found roughly 80% failed to deliver measurable value, mostly on operational discipline rather than model quality ([RAND](https://www.rand.org)). A parallel run is operational discipline made concrete, and it is the difference between the agents that work and the ones that quietly do not.

Watch specifically for the failure modes your content causes. A wrong-article retrieval means two topics are too similar, so split or clarify them. A confident answer to a question you have no article for means the agent is not escalating when it should, which is a guardrail problem you fix before, not after, real customers arrive.

## Step 5: Cut over and measure

When the parallel run clears your bar, you cut over, and the way you do it decides how calm the switch feels. A cutover is not a single dramatic switch-flip, it is a staged handoff where the agent takes more of the real queue as it earns trust. Staging it means a problem surfaces on a slice of traffic, not all of it.

**Start with a bounded slice of live traffic.** Point one channel, or one topic, or a share of conversations at the agent first, and keep the rest on your existing flow. This is where the [Shared Inbox](/shared-inbox) matters, because presence-based human takeover lets a person step onto any conversation the moment they are viewing it, so the agent never talks over a human mid-reply.

**Keep the human handoff clean from day one.** The agent should route a conversation to a person the instant it should not answer, without the customer starting over. This is not optional polish, because repeating yourself is one of the top customer frustrations, with Zendesk's 2024 CX Trends research finding 74% rank it among their biggest annoyances ([Zendesk](https://www.zendesk.com/blog/customer-service-statistics/)).

**Measure resolution, not deflection.** Deflection counts a customer who gave up as a success, which flatters the numbers and hides real dissatisfaction. Track confirmed resolution on agent-only conversations, escalation rate broken down by reason, and response time, using the built-in [analytics](/pricing) tied to real conversations rather than a blended dashboard.

Expand the agent's share as the numbers hold, and pull it back on any topic where they slip. The escalation data is your roadmap for what to fix next, because every escalation is a question the agent could not answer, which points straight at the next article to write. A migration that ends at cutover is unfinished; the loop of measure, fix, and expand is where the real gains compound.

The prize for getting this loop right is large and well documented. Gartner has projected that by 2029, agentic AI will autonomously resolve 80% of common customer service issues without human intervention ([Gartner](https://www.gartner.com)). Those are precisely the documented, repetitive questions your migrated macros and articles now answer, which is why the content work of the earlier steps is what decides how much of that volume the agent can safely carry.

## A migration-readiness comparison

Before you commit to a date, it helps to see the two models side by side on the dimensions that actually decide the move. The table below is not a scoreboard where more checkmarks wins, it is a fit map, because the right answer depends on which rows matter most to your support. Read it as a way to name your own trade-offs, not to declare a winner.

| Dimension | Legacy helpdesk (Zendesk archetype) | AI-agent-first setup |
| --- | --- | --- |
| Resolves repetitive questions automatically | ✗ (rule-based only) | ✓ |
| Mature ticketing, SLAs, and routing depth | ✓ | ✗ (varies by tool) |
| Broad channel and integration breadth | ✓ | ✗ (web, chat, email here) |
| Scales without adding headcount | ✗ | ✓ |
| Answers grounded in your own knowledge | ✗ (agents apply macros) | ✓ |
| Human takeover for hard cases | ✓ | ✓ |
| Setup is mostly editorial, not configuration | ✗ | ✓ |

Read the rows where the agent-first column shows a checkmark as the reasons to move, and the rows where the legacy column does as the things you must not lose in the process. If your support leans on the workflow-depth and channel-breadth rows, a staged or hybrid move protects them while you gain the automation. If it leans on the repetitive-volume rows, the case for migrating is strong and the sooner you start the audit, the better.

The comparison also frames the honest question of whether to move at all. If most of your rows favor the legacy column, the [Zendesk AI alternative comparison](/blog/zendesk-ai-alternative) may talk you out of migrating right now, which is a fair outcome. Choosing the model honestly is more valuable than forcing every team onto an agent because the technology is available.

## Where Communicate fits, honestly

**Here is the plain truth this playbook will not dress up: Communicate is a focused tool, not a full Zendesk replacement for every team.** Its live channels are the web widget, live chat, and email, plus in-app messages, analytics, and scoped actions, all running from one AI agent and one knowledge base. If you need channels beyond those, or the deepest enterprise ticketing workflows, an established helpdesk may still serve you better, and you should know that before you evaluate.

What Communicate does well is the agent-first half of this playbook. The agent trains on your own data through grounded retrieval and hands off when it is unsure, which is exactly the behavior the earlier steps are building toward. For teams whose support lives on a website, a chat window, or email, that focus is a feature, because a smaller tool doing the core job well beats a sprawling one you half-configure.

The handoff is built the way this playbook demands. The [Shared Inbox](/shared-inbox) uses presence-based human takeover with a per-turn backstop, so when a person is viewing a conversation the AI steps back, and the agent never speaks over a human mid-reply. That is the mechanic that makes a cutover safe, because it means the agent carrying volume and a person handling judgment can share the same queue without collision.

On pricing there is no free tier, which is a deliberate choice rather than an oversight. Entry is a one-time $1 activation that confirms you are a real person and includes 100 test credits, then [credit-based usage](/pricing) from there, which keeps support cost predictable rather than tied to headcount. The activation credits are enough to run the parallel-run test from Step 4 before you spend anything more.

On security, Communicate encrypts data at rest, offers TOTP two-factor authentication, isolates each workspace, and supports self-serve export and cascading delete, so the [data you migrate](/data-sources) stays portable. It is GDPR-ready but not certified, with no SOC 2, HIPAA, ISO 27001, or SSO, and it runs in a single region. That posture is stated plainly rather than buried, and questions go to communicate@support.communicate.so.

## Key takeaways

- Migrating from Zendesk to AI is a sequence, not a switch: audit, export, map macros to knowledge, connect data sources, parallel run, cut over, and measure.

- Be fair about the legacy helpdesk. Its ticketing depth, channel breadth, and macro library are real strengths, and your macros are training data you already paid to create.

- The parallel run is the safety net. Test the agent on your own ugly questions and set a go or no-go bar before cutover, so a fluent-but-wrong answer counts as a failure.

- Cut over in stages and measure confirmed resolution, not deflection, using escalation data to point at the next article to write.

- Communicate is a focused agent-first tool for web widget, live chat, and email, not a full replacement for every enterprise workflow, so match it to your channels honestly.

Ready to run the parallel-run test on your own migrated content before betting your queue on it? [Start with a one-dollar account activation](/pricing) that includes 100 test credits, connect a sample of your exported help center, and score the agent on your real questions. If you are still weighing the move itself, the [Zendesk AI alternative comparison](/blog/zendesk-ai-alternative) and the [AI support onboarding checklist](/blog/ai-support-onboarding-checklist) are the right next reads.

## Frequently asked questions

### What does it mean to migrate from Zendesk to AI?

It means moving from a ticket-and-macro helpdesk to an [AI-agent-first setup](/ai-agents), where an agent resolves the repetitive majority of questions from your own knowledge and people handle the rest. The agent becomes the default handler, not an add-on a human still drives. Your tickets, macros, and articles move too, reshaped into knowledge the agent can retrieve.

### Do I lose my ticket history when I migrate?

No, if you plan the export. You archive your ticket history to your own storage in a durable format so the record survives the move, even though you rarely feed raw tickets to the agent. Keep data-protection rules like the [GDPR](https://gdpr.eu) in mind, and set a deliberate retention plan rather than keeping everything forever.

### Is Zendesk bad? Why would I leave it?

Zendesk is not bad, and this playbook is fair about it. Its ticketing depth, channel breadth, and mature workflows are genuine strengths. Teams leave when their support is dominated by repetitive, documented questions that an AI agent can resolve automatically, which is where the rule-based model stops scaling without more headcount.

### How do I export my data from Zendesk?

Export your help-center articles, your macros, and your ticket history separately, because they have different destinations. Check [Zendesk's own site](https://www.zendesk.com) for the current export mechanics rather than a third-party summary, since it is the authority on its own tooling. Verify a sample by hand to confirm formatting, links, and attachments survived before you trust the whole batch.

### What happens to my macros in the migration?

Your macros become agent knowledge, and they are the highest-value material you have. Each one is a canned answer your team trusted, so the library is a compact map of your best replies. You rewrite them into self-contained, single-topic articles and connect them as [data sources](/data-sources), which the agent then retrieves from.

### Why do I have to rewrite macros instead of copying them?

A macro assumes a human who already knows the context, so it often skips the framing a customer needs. An AI agent retrieves passages in isolation, so each answer has to stand on its own. The rewrite adds back the context the macro left out and leads with the question a customer would actually type.

### What is a parallel run and why does it matter?

A parallel run is a period where the agent works your real queue without customers depending on it, so you can score its answers before cutover. It is the safety net that turns migration from a leap into a controlled test. Skipping it is the most common reason AI support projects fail after launch.

### How do I know when the agent is ready to go live?

Set a go or no-go bar before you see results, judged on your own test set. A common bar is high factual accuracy with zero invented answers on out-of-scope questions, plus clean escalation when it should not answer. Deciding the threshold in advance keeps you honest, because it is easy to talk yourself into shipping a fluent agent that quietly fails.

### How long does a migration from Zendesk to AI take?

Most of the time goes into the content work, not the technical setup, because connecting data sources takes an afternoon while auditing and rewriting content takes longer. Plan the audit, export, and macro mapping as the bulk of the effort. The [AI support agent implementation guide](/blog/ai-support-agent-implementation) walks that groundwork step by step.

### Can I run the agent alongside my helpdesk during the switch?

Yes, and you should. The parallel run does exactly this, letting the agent draft answers on real questions while your existing flow still serves customers. At cutover you stage the handoff, pointing a slice of live traffic at the agent first and expanding as the numbers hold.

### What if I need channels Communicate does not support?

Then Communicate may not be your full replacement, and this playbook says so plainly. Its live channels are the web widget, live chat, and email, plus in-app messages, so if you depend on channels beyond those, a hybrid setup or a different tool is the honest answer. The [Zendesk AI alternative comparison](/blog/zendesk-ai-alternative) helps weigh that trade-off.

### How does the agent hand off to a human?

It routes a conversation to a person the moment it should not answer, without the customer starting over. Communicate's [Shared Inbox](/shared-inbox) uses presence-based human takeover, so when a person views a conversation the AI steps back, with a per-turn backstop that stops it talking over a human mid-reply. A clean handoff is what makes a cutover safe.

### How accurate is the agent after migration?

Accuracy comes mostly from grounded retrieval and clean content, not the model badge. RAND found roughly 80% of enterprise AI initiatives failed to deliver measurable value, mostly on operational discipline ([RAND](https://www.rand.org)). Test the agent on your own real questions and hold it to your accuracy bar before you trust it with live traffic.

### What should I measure after cutover?

Measure confirmed resolution on agent-only conversations, escalation rate broken down by reason, and response time, on your own volume rather than a blended dashboard. Communicate's [analytics](/pricing) tie those to real conversations, so escalations point straight at the next article to write. Resolution, not deflection, is the number that maps to a genuinely good agent.

### Why measure resolution instead of deflection?

Deflection counts a customer who got a wrong answer and gave up as a success, which flatters the numbers and hides dissatisfaction. Resolution counts only conversations the agent actually solved. Measuring deflection is how a migration looks successful on a dashboard while customers quietly get worse answers.

### Will an AI agent replace my whole support team?

No, and a vendor claiming it will is overselling. An agent can resolve the repetitive majority, but some conversations always need human judgment and empathy, a point usability researchers like the [Nielsen Norman Group](https://www.nngroup.com) have long made. The realistic goal is to let the agent carry volume and route the judgment calls to people.

### How much does the AI side cost to run?

Communicate has no free tier. Entry is a one-time $1 activation that confirms you are a real person and includes 100 test credits, then [credit-based usage](/pricing) from there, which keeps cost predictable rather than tied to headcount. The activation credits are enough to run the parallel-run test before you spend more.

### Which model does Communicate use?

It runs a single model, gpt-4o-mini through [OpenRouter](https://openrouter.ai), with response and prompt caching to keep cost and latency down. That is a deliberate simplicity, because the [data you connect](/data-sources) drives answer quality far more than the model badge. One well-tuned model on clean knowledge beats a model-picker on messy data.

### Is my migrated data safe and can I get it back out?

Communicate encrypts data at rest, offers TOTP two-factor authentication, isolates each workspace, and supports self-serve export and cascading delete, so your data stays portable. It is GDPR-ready but not certified, with no SOC 2, HIPAA, or ISO 27001, and a single region, a posture documented on the [security page](/security). Confirming you can export from any new tool is a fair question to ask before you commit.

### Where do I start if I have decided to migrate?

Start with the audit in Step 1, because everything downstream depends on knowing what your content covers. Then export, map your macros to knowledge, and run the agent in parallel before cutover. The [how to build an AI customer support agent](/blog/how-to-build-an-ai-customer-support-agent) guide and the [AI support onboarding checklist](/blog/ai-support-onboarding-checklist) are the companion reads for the build itself.