Joe OviedoThere’s a question I used to save for the end of a website project: “Who has access to the domain?” It seemed reasonable. First we had to decide what to offer, write the page, and make sure it all made sense. Close to launch, someone would give us access and we’d connect whatever was needed.
Now I like to ask much earlier. Not because I want to start a conversation about sales with DNS. It’s because sometimes the answer is, “Someone who no longer works here bought it.” That changes what I can promise for Friday.
The page loads. What about everything else?
Imagine we’re getting ready to launch a workshop. The page opens at the business’s domain. The form saves registrations. I run a test from my computer, see my name on the list, and think we’re done. But when I register with my personal email, I can’t find the confirmation. The dashboard says it was sent.
I used to start with the email: check the subject line, cut the copy, send another test. Today, before touching the message, I’d ask something more basic: what address sent it, and who can check how it’s configured?
The page loading doesn’t answer that. A domain can take you to the website even if the email service isn’t set up properly to send confirmations on behalf of the business. And even if it is, “sent” doesn’t tell me whether the recipient found the message. Those are different checks. If I assume both passed because I saw a new registration, I can spend an afternoon rewriting an email nobody has read.
Who can fix it without asking a favor?
What worries me isn’t finding a missing setting. We can fix that. It’s discovering the problem after people have already signed up and not knowing who can make the change.
The person who edits the page may not manage the domain. Whoever built the form might not have access to the email service. And the sender address can look professional even if no one reads the replies. From the outside it’s one business. On the inside, there may be three accounts and no one who knows who has access to each.
I don’t need everyone to be able to change everything. I do want the business to keep control and everyone to know whom to ask. If the person who built the page leaves, the domain shouldn’t go with them. And if someone replies to say they can’t find the workshop link, I want that reply to reach someone who can help, not an address nobody checks.
The test I’d run before inviting anyone
I’d go through the journey from the outside: open the URL we’ll share, register with an email address outside the team, find the confirmation, open the link, and reply. Then I’d check that the reply reached the person who will handle it. If something fails, I’d note where it stopped and who can fix it. It doesn’t have to turn into an audit to be useful.
I’d also decide what we can keep doing in the meantime. If we don’t have access to the domain, we can finish the page and test the form in a staging environment. What I wouldn’t do is send traffic to find out, with real registrations, whether people got the instructions we promised. We’ll have enough to learn from the launch. We can check this first.
That’s why I count the domain and email as part of the funnel. To someone signing up, the page, the confirmation, and the reply to their question aren’t three systems. They’re three moments in the same conversation. If they have to contact us somewhere else to find out whether registration worked, it hardly matters that the dashboard says everything went fine.
← Back to the Journal