Building Ghost Inbox: How We Wired Resend + Discord Into a Full Two-Way Customer Messaging System
Every small business owner knows shared-inbox chaos. Emails get missed. Replies leave from personal accounts. Nothing is tracked against the customer or the order.
Ghost Inbox is WordSmith's answer — a module, not a third-party CRM tax.
The problem we refused to ignore
Customer email is still how a huge amount of real work arrives: address fixes, "where's my order," wholesale questions, press, partnerships.
Typical "solutions" are:
- A shared Gmail that everyone half-watches
- A per-seat helpdesk that costs more than the volume justifies
- Forwarding rules that create three copies and zero accountability
We wanted something that fits the Launchpad model: owned infrastructure, logged in the client database, operable by the team where they already coordinate — Discord — without forcing a second product religion.
The flow, end to end
- Inbound — a customer emails the business address.
- Resend — captures inbound and fires a webhook to our Ghost Inbox API route.
- Parse + persist — sender, subject, and body land in
contact_submissions(client DB). - Discord — a thread opens in the private ops server so the team can see and assign context.
- Reply — someone answers in Discord like any other message.
- Outbound — the bot posts to our reply API; Resend sends email with the proper
In-Reply-Toheader so the customer sees a clean thread.
The Discord bot runs as a persistent process (not a flaky serverless timeout). Every message is logged in the dashboard. Threads are searchable. Replies are timestamped.
Why this belongs on the Launchpad
Ghost Inbox is not a sidecar SaaS. It is a module that sits next ot orders, customers, and activity log:
- The same auth and operator shell as the rest of the dashboard
- Records you can report on later (volume, response latency, repeat senders)
- No per-seat licensing spiral for a five-person shop
This is the kind of infrastructure that used to mean "buy a $300/mo tool and hope." We built it into the platform so messaging is part of the operating system, not another login.
What operators feel day to day
- One place to see what came in
- Replies that stay in the customer email thread
- Less "who answered this?" archaeology
- A path to connect messages to customers and orders as the rest of the data layer matures
Honest constraints
Inbound webhooks and bot processes need operational care — signature verification hardening, uptime, and channel hygiene. That is exactly why WordSmith runs it as managed infrastructure instead of handing you a brittle DIY script.
If your "CRM" is still a shared inbox, you do not need another spreadsheet. You need a message path that lands in a system you actually operate.