One Field Closes the Lead Loop in Both Directions

Every API route on this site that handles a form submission sends two emails: one to the visitor confirming their submission, one to us notifying us of the lead. The notification is the one we act on.

When a prospect submits an Operations Engine audit request, the notification lands with their name, email, website, service interests, timeline, budget, and a description of their operational pain. The next step is to reply. That step has friction if replyTo isn't set.

The Notification Side

Default behavior for a from: noreply@... sender: hitting reply writes back to the noreply address. That's a dead mailbox. You copy the email from the body, open a new compose window, paste it in. Two extra steps every time.

const sendNotify = resend.emails.send({
  from: "Twenty One Media <noreply@twenty1-media.com>",
  to: process.env.CONTACT_EMAIL ?? "isaac@twenty1-media.com",
  replyTo: email,
  subject: `New Operations Engine audit request — ${name}`,
  text: notifyText,
});

from stays noreply because that address is warmed and authenticated for deliverability. replyTo is the prospect's actual email. When the notification lands in the inbox and you hit reply, the email client sends directly to the person who filled out the form. No copy-paste, no compose window.

from can't just be a real address here. The route sends from a single authenticated domain. If we set from to a personal address, deliverability degrades and SPF alignment breaks. replyTo is the correct field for routing replies without touching the sender identity.

The Confirmation Side

User confirmation emails flip the pattern. The prospect submits the form and gets a confirmation from "Isaac at Twenty1 Media." If they have a question, they might reply to that email. Without replyTo, their reply goes to noreply@twenty1-media.com and disappears.

const sendUser = resend.emails.send({
  from: "Isaac at Twenty1 Media <noreply@twenty1-media.com>",
  to: email,
  replyTo: process.env.CONTACT_EMAIL ?? "isaac@twenty1-media.com",
  subject: "Your AI audit request — Isaac will reach out soon",
  text,
  html,
});

replyTo is the real inbox here. The confirmation is signed with a person's name. If the prospect replies, it goes to the address that person monitors. Not to noreply. Not to a support queue.

What This Covers

Every lead route on the site follows this pattern: /api/audit-request, /api/skill-clone, /api/toolkit-signup, /api/operations-engine-lead, and /api/contact. The contact route sends only a notification (no user confirmation), and it sets replyTo: parsed.data.email directly.

The result is a bidirectional email thread. The prospect can reply to their confirmation and reach a real inbox. We can reply to the lead notification and reach the prospect. Both ends are wired correctly with one field per send.

Without replyTo set, email from a form route is a one-way push. You get the lead data, but any follow-up requires the prospect to hunt for a contact address or for you to manually compose. That's fine once. It's a broken workflow across five forms.

Two fields per route: replyTo: email on notifications, replyTo: process.env.CONTACT_EMAIL on confirmations. The thread that closes the lead opens itself.