CUSTOM DOMAIN
You learn to recognize it by the second line. A customer pasted a CNAME target and the domain still will not verify. Or the mail records went in but email bounces, because the MX priority landed in the wrong field. Or a TXT record got wrapped across two lines by a text editor nobody asked to help. You have seen this ticket before. You have seen it a hundred times.
That is the tell. A hard problem shows up once and teaches you something. A structural problem shows up on repeat, wearing slightly different clothes each time, and teaches you nothing except that the process is broken.
The same four mistakes, over and over
None of these tickets are technically difficult. That is what makes them maddening. They are error-prone by design, because you are asking a person to transcribe machine-precise values by hand. The same four failure modes account for nearly all of them, and each one traces back to the same root cause: a human typing a value that a machine should have written.
| Ticket type | Root cause | With one-click setup |
|---|---|---|
| Missing trailing dot on a CNAME | Target hand-entered, so the record points somewhere subtly wrong | Cannot happen: records are applied by template, not typed |
| Wrong MX priority | Priority typed into the host field instead of the priority field | Cannot happen: the customer never touches a field |
| Split TXT verification record | Value wrapped across two lines when it was pasted | The full value is written in one piece, exactly as issued |
| Expired verification token | Setup took longer than the token stayed valid | The record is written in about 30 seconds, before it can expire |
Every one of these is a copy-and-paste operation that went sideways. The customer did not misunderstand DNS. They were handed a set of values and a form with too many fields, and the odds caught up with them.
Fluency is not the same as good operations
Good support teams respond to this the way good teams always do: they write it down. They build playbooks so detailed that an agent can walk a customer through a given service's setup half asleep. Which field. Which value. What the trailing dot is for. Why the record has not propagated yet, and why you cannot tell whether the fix worked until it does.
That fluency feels like competence. It is worth being honest about what it actually is. When your team can recite a fix in their sleep, it means the same failure has visited often enough to be memorized. The playbook is not a trophy. It is a scar.
The point
When your agents can recite the fix from memory, that is not mastery. It is evidence the system is forcing humans to compensate for a defect.
And these tickets are expensive twice. They come in high volume, so they eat a real share of the queue. They also resolve slowly, because you often cannot confirm a fix until records propagate. So the agent applies a change, waits, checks again, waits again. A ticket that should take two minutes stretches across an afternoon of returning to the same thread.
Delete the category, not the ticket
The usual instinct is to make the ticket faster: a better help article, a clearer screenshot, a shorter script. Sixteen help articles later, the ticket still arrives. You are optimizing a process that should not exist.
The one-click flow removes the transcription entirely. Custom Domain detects the customer's DNS provider, shows them the exact records, and writes those records at their provider with one-click consent. The customer never types a value. Watch what happens to each ticket type when that is true:
- Wrong-value tickets nearly vanish, because the customer cannot mistype a value they never type.
- Missing-record tickets vanish, because the full record set is applied together, not one field at a time.
- Conflict tickets shrink, because the consent flow detects and surfaces an existing conflicting record before anything is changed, instead of after email quietly breaks.
There is a pattern worth sitting with. Some customers hit the manual setup, failed, and stumbled onto the one-click flow mid-failure. Almost all of them then succeeded. Same person, same domain, same afternoon. The only thing that changed was the process. That is about as clean a proof as support ever gets that the manual path itself was the defect, not the human on the other end of it.
What your team does with the time
Deleting a ticket category does not shrink the job. It moves it. The hours your agents spent teaching people where the priority field lives get spent on the work that is actually hard and actually rewarding: DNSSEC that will not validate, a nameserver migration that has to happen without dropping mail, a zone delegation that needs a careful hand. That is DNS work worth a human. Copy-and-paste transcription never was.
When the DNS step disappears, the queue gets quieter in a specific way. The tickets that remain are the ones that deserve a person's attention. Nobody misses the ticket that arrived a hundred times, and nobody has to write the playbook for it ever again. If you want to see how a one-click connection works, it takes about the same time as reading one of those help articles.
Custom domains, on autopilot
Delete the DNS ticket category for good. Let your customers connect their own domain in one click. We detect their DNS provider, write the records, verify ownership, and issue HTTPS, while they just approve one screen.
Get started