Reply detection implemented

A sequence that cannot detect replies is operationally blind — it continues sending follow-ups to contacts who have already engaged, replied, or expressed interest. The next scheduled step lands in the inbox of a prospect who replied two days ago asking for a demo, with no human having seen the reply and no system action taken. iso-25010:2011 reliability.fault-tolerance marks this as a reliability gap: the system lacks a mechanism to adapt its behavior to the most important signal a sequence can receive. In practice, the absence of reply detection turns outreach sequences into one-way blast channels that actively frustrate engaged prospects.

Implement inbound email handling via your ESP's webhook — SendGrid Inbound Parse, Postmark Inbound, or Mailgun Routes are all drop-in options. Register a POST handler at a stable path like /api/webhooks/inbound-email.

// POST /api/webhooks/inbound-email — SendGrid Inbound Parse example
export async function POST(request: Request) {
  const formData = await request.formData()
  const from    = formData.get('from') as string
  const to      = formData.get('to') as string
  const subject = formData.get('subject') as string
  const text    = formData.get('text') as string

  const contact = await db.contact.findFirst({ where: { email: extractEmail(from) } })
  if (!contact) return new Response('ok')

  await handleReply({ contactId: contact.id, from, to, subject, body: text })
  return new Response('ok')
}

If your ESP does not offer inbound routing, use IMAP polling on a dedicated reply-to mailbox (e.g., replies@yourdomain.com) as a fallback. The route must be actively receiving events — a placeholder route with no ESP configuration does not satisfy this check.