Complaints That Route Themselves

The Company

Hesselink Consumer Goods makes ceramic homeware — bowls, plates, mugs, serving pieces — and sells it direct to consumers through their own webshop and to independent homeware retailers across Europe. They're based in Utrecht, about 54 people, and they've built a decent reputation for quality. The problem with selling breakable things to both individual customers and wholesale buyers is that when something goes wrong, the complaints look completely different from each other, and they come in through the same inbox.

The Pain

Mireille runs customer experience. On a normal Monday she might open her inbox to find a complaint from someone in Lyon whose mug arrived cracked, a message from a retailer in Copenhagen whose entire order of 200 pieces was the wrong glaze finish, and a webform submission from a Berlin customer who got someone else's parcel entirely. These are three completely different problems. One needs a replacement sent. One needs logistics and the account manager looped in immediately. One needs a warehouse investigation. But until Mireille reads each one properly, works out what it actually is, figures out whose problem it is, and writes a first response, nothing moves. She's doing triage by hand, every day, before she can do anything else.

The Move

The pipeline connects to Hesselink's inbound complaint channel — email and webform — and processes each submission the moment it arrives. It pulls out the relevant details: what type of complaint it is, which SKU is mentioned, the order value, whether the customer is a direct consumer or a wholesale account, and what the overall tone is. It then runs that information through an LLM that assigns a severity level and routes the case to the right team. At the same time it drafts a first-response email that actually references the specific issue — not a generic "we've received your message", but something that names the product and acknowledges what went wrong. And it creates a pre-populated case record in the helpdesk with a suggested resolution path already filled in.

So when Mireille or a team member opens a ticket, the work of understanding it is already done. They're reading a case that says: wholesale account, glazing defect across a bulk order, high severity, route to logistics and account management, suggested next step is X. They're not starting from a blank ticket.

The blind spot

Most people look at this and think it needs a developer and a proper integration project. It doesn't have to. Tools like Make or Zapier can connect a webform or email inbox to an LLM step and then on to most helpdesk systems without writing any code. The actual work is figuring out what you want the classification to do — and that's a conversation, not a build.

The pattern

The same approach fits in a few other ordinary situations:

• A warranty claims inbox at a furniture or appliance brand, where claims need to be checked against purchase dates and routed to different teams depending on what's covered
• An inbound supplier query inbox at a food or drinks importer, where questions need sorting by urgency and department before anyone can act
• A returns authorisation process at any e-commerce business where the reason for the return determines what happens next