From inbox to ticket, automatically: event-driven email intake

You can build the best portal in the world, and some customers will still reply to an email. That's not a failing; it's how people work. So when we built a query hub for a payroll services client, we made a deliberate decision together: rather than force everyone through the portal, we'd meet customers where they already are, in their inbox.

The result is an email intake pipeline that turns an ordinary email into a fully-formed support ticket, attachments and all, with no one copying and pasting anything.

How it works

The architecture is deliberately loosely coupled, built from small pieces that each do one job:

1. A dedicated inbound email subdomain receives customer queries, so branded addresses can route straight into the platform.
2. An email worker at the edge (running on Cloudflare, deployed from CI/CD pipelines like everything else) listens for incoming mail and hands it off as a message.
3. Azure Functions and queues process each submission: parsing the content, handling attachments, and publishing an event to the platform's event bus.
4. The query hub subscribes to those events and creates the ticket, so an emailed-in query appears alongside queries raised in the portal, ready to be picked up, tagged and answered.

Because every step communicates through events rather than direct calls, each piece can fail, retry, scale or be replaced independently. An email is never silently lost because a downstream service happened to be busy.

A stepping stone to a wider event-driven platform

This project doubled as the proving ground for something bigger: moving the client's platform towards an event-driven architecture on Azure Service Bus. We started the way we'd advise anyone to start: get one safe, well-understood event flowing through the new infrastructure in production, observe it, then expand. The email pipeline was the ideal first passenger: real value, bounded scope, and failure modes we could reason about.

That incremental approach matters. Rewrites are risky; extensions are manageable. Today the event platform carries the email intake flow, and it gives the client a paved road for every integration that comes next.

The takeaway

"Our customers won't use the portal" is one of the most common objections to workflow software, and it's often right. The answer isn't to fight user behaviour; it's to absorb it. If you have a process that still runs on email and you'd like the structure without the retraining, we should talk.