Custom Domain Demo Links for Agencies

A custom domain demo link means the demo you send runs on a hostname you own, something like demos.youragency.com, instead of on your demo vendor's shared domain. The page itself is identical. What changes is the address the prospect reads in your message, sees in the browser bar, and gets in the link preview when your email client unfurls it. That address is the last piece of a white-label setup, and it is the piece most agencies leave switched off.

It matters because the domain is the only part of your demo that gets evaluated before anyone clicks. Everything else you have branded, the logo, the accent color, the call to action, is downstream of a decision the prospect has already made about whether the link looks like it came from a real operator. A hostname they have never seen, belonging to a company they have never heard of, is working against you at exactly the wrong moment.

This covers what the domain actually communicates, where a vendor hostname quietly costs you, what a custom domain does not fix, and the practical setup decisions worth thinking through once rather than three times. It is written for agencies and consultants who sell AI agents and whose entire pitch is that they build and run these systems themselves.

What the link says before anyone clicks

Cold outreach is read in fragments. A sender name, a subject line, a first sentence, and a URL. The URL is doing more work than its size suggests, because it is the one element in the message that cannot be written to flatter you. Copy is an assertion. A domain is a fact.

When the fact reads demos.youragency.com, the message is coherent: this person has infrastructure, this is a thing they run. When it reads as a hostname belonging to a software company, the message splits in two. The prospect now has a sender and a tool, and their instinct is to attribute the impressive part to the tool.

Where prospects actually see the hostname

This is not only about the visible link text. The domain surfaces in more places than most people account for.

• Hover and long-press previews. Anyone cautious enough to check a link before clicking sees the real destination, no matter what the anchor text says.
• Link unfurls. Email clients, Slack, and LinkedIn generate preview cards that usually include the source domain in small text under the title.
• The browser bar after the click. It stays there for the entire session while the prospect explores the demo.
• Anything they forward. When the owner sends the demo to a partner or an office manager, the domain travels with it and gets a second round of scrutiny from someone with no context.

Where a vendor domain quietly costs you

There are three distinct costs, and they are worth separating because only two of them are about perception.

The white-label contradiction

If you have already set your agency logo, your accent color, and your own call to action, the vendor hostname is the one surviving inconsistency. Prospects rarely articulate this. They just register that something about the setup does not line up, and mild incoherence in a cold message reads as low effort. The white-label demo software guide covers the rest of the branding surface; the domain is the part that guide cannot solve with a settings toggle.

Discoverability of your stack

A curious prospect will look up an unfamiliar domain. Some will find the vendor and conclude that what you sold as your capability is a subscription they could buy. That conclusion is usually wrong, since the work is in the targeting, the build, the delivery, and the follow-through, but you do not get to make that argument if the prospect quietly reprices you before the call. Owning the hostname does not hide anything dishonestly. It simply keeps the conversation about the outcome rather than about procurement.

Shared link reputation

This one is mechanical rather than psychological. Spam filtering considers the domains a message links to, not just the sending domain. A vendor's shared hostname accumulates whatever reputation every operator on the platform produces, and you have no control over that pool. A domain you own has a reputation you are solely responsible for, which cuts both ways: nobody else can damage it, and nobody else can carry you. For an operator running consistent, permission-respecting outreach, having your own is the safer position.

The prospect is not comparing your demo to another demo. They are deciding whether you are a real operator or somebody forwarding a trial. The domain answers that before the page loads.

What a custom domain does not change

Worth being clear, because it is easy to over-invest here. A custom domain does not make a weak demo convincing. It does not improve the quality of the agent, the accuracy of the research behind it, or the relevance of the prospect you picked. It removes a specific, small, avoidable friction. That is the whole job.

It also does not change what the demo is. A demo remains a demonstration, and it should keep saying so. Running it on your domain does not license you to imply the agent is already deployed on the prospect's business, and it does not turn an in-demo booking into a real calendar write. Branding that oversells is a liability the moment someone tests it.

Practical setup: what to plan for

The mechanics are simpler than the decisions around them. Get the decisions right first.

Use a subdomain, leave your root alone

Point a subdomain at the demo platform rather than your apex domain. Your main site keeps working untouched, and a subdomain of a domain the prospect can look up inherits whatever recognition that domain already has. Keep the name short and self-explanatory: demos, preview, or try are all fine. Avoid anything that reads as a tracking hostname, because those get eyed suspiciously.

DNS, certificates, and the wait

In practice this is one DNS record at your registrar pointing the subdomain at the platform, after which certificates are issued automatically so the link loads over HTTPS. Most changes resolve within the hour, though propagation depends on the TTL your provider had set. Two things worth checking before you send anything: that the certificate has actually issued, and that the link loads on mobile data as well as on your own network, since local DNS caching will happily show you a working page while everyone else gets an error.

One agency domain, not one per client

The instinct to give each client their own domain is understandable and usually wrong. Per-prospect branding belongs inside the demo, not in the hostname, and one domain per client multiplies DNS maintenance while destroying the consistency that makes your link recognizable across a follow-up sequence. One agency-owned hostname, reused across every demo you build, is the maintainable shape.

Treat it as a one-time setup, not a per-send step

Configure the domain once, verify it once, and then forget it. If a platform asks you to do domain work per demo, that is a workflow problem worth raising before you commit, because at any real volume of personalized demos a per-send manual step is the thing that quietly stops you sending.

The rest of the branding surface

A domain on its own is not white labeling. The full surface an agency should expect control over is short enough to check in a demo call with any vendor.

• Agency name. Displayed as the party presenting the demo, in the footer or attribution area.
• Logo. Yours, rendered cleanly at the sizes actually used, not stretched into a fixed box.
• Accent color. Applied consistently, so the demo does not look like a template with one recolored button.
• Call to action.Your wording, pointing at your booking link, not a generic "get started".
• Custom domain. The hostname, covered above.

Notice what is not on that list: the prospect's own branding, which is a separate axis. In a per-prospect demo the prospect's business is the subject of the demo, while your agency is the party presenting it. Those two identities sit in different places on the page and should not be collapsed into one setting.

When it is not worth doing yet

If you have sent fewer than a handful of demos and you are still working out which niche responds, the domain is not your constraint. Send the demos, learn what lands, and configure the hostname when your message is stable enough that the link is being read rather than ignored. The setup takes minutes whenever you get to it, and doing it early does not compound. What does compound is the number of prospects who have seen a coherent, branded link from you, which only starts once you have something worth sending.

How this works in Ciela

Ciela is the demo platform for AI agencies and AI consultants, and the branding controls are part of the core product rather than a premium add-on. Each demo link carries your agency name, logo, accent color, and call to action, and can run on your own custom domain, configured once per agency and applied to the demos you build afterward.

Worth repeating because it shapes how the domain gets used: Ciela has no built-in send channel. You build the demo, copy the link, and send it through Instantly, Apollo, Clay, HeyReach, Smartlead, or whatever you already run. The custom domain is what makes that pasted link look like it came from you rather than from a tool, which is the entire point of configuring it. For how to run the conversation once the prospect has clicked, see the guide to demoing AI agents to clients, and the agent build library for the builds each demo maps to.

The full picture of how this category works sits in the pillar on demo software for AI agencies, and pricing shows what is included.