Replying by email

How customers continue a conversation by replying to SupportPage notification emails.

Customers can keep a support thread going by email without returning to the web form or status page. This matches how many people already work with support — reply from the inbox they use all day.

How it works

  1. Customer submits the support form.
  2. They receive a confirmation email with a status link.
  3. When your team replies from the dashboard, the customer gets an email with your message.
  4. The customer hits Reply in their mail client and types a response.
  5. Their reply is ingested into the same request thread and visible to your team in ticket detail.

Email replies append to the conversation chronologically, like dashboard replies.

Which address to reply to

Customers must reply to the notification email's reply address — usually a routed address like reply+…@… or a dedicated inbound domain shown in the thread.

What customers should include

  • Keep the subject line — threading headers often depend on it
  • Reply above the quoted history — standard email etiquette helps parsers
  • One issue per thread — new problems deserve a new form submission

When replies do not show up for your team

From the customer's side, the email sent successfully. If your inbox does not show it:

CheckDetail
Reply-To addressCustomer replied to the correct routed address
Forward vs replyForwards break threading metadata
SpamOperator mail filters quarantined the inbound message
DelayInbound processing can take a minute

Operators: see FAQ — email replies not showing.

Status updates via email

Customers may receive emails when:

  • You send a dashboard reply
  • Status changes (if enabled for your account)

Each email should include a link back to the status page for full history.

Customers without email

SupportPage is email-centric. If a customer cannot use email, your team must coordinate through other channels manually — there is no SMS or chat bridge in core product docs.