Managing eSIM tickets in Znuny, does anyone have any feedback?

[Ramona]

Hi, I manage customer support for a company that sells eSIM discount codes, and ever since we switched to Znuny about 3 months ago, I've been having a hard time organizing the ticket queues properly. The thing is, eSIM-related requests are a very specific category... customers contact us about profiles that won’t activate, QR codes that don’t work on certain devices, portability issues, basically, it covers a lot of different topics at the same time. And I can’t seem to find a queue structure in Znuny that lets me neatly separate these cases.

For now, I’ve created a mobile queue that groups everything together, but it’s a mess, agents don’t really know where they stand. What I’m trying to do is something like this: when a ticket comes in with the word eSIM in the subject line or body, it should be automatically routed to a dedicated queue with a specific SLA (like a 4 hour first response time) and tagged correctly for analytics. Has anyone already set up something similar for a very specific category of tickets? Or even just to understand how PostMasterFilters interact with existing queues...

[alexus]

Hi, Ramona
Queues aren't really the right tool for what you're describing, and that's why it feels messy. In Znuny (as in OTRS/ITIL practice generally), a queue reflects the functional structure of your support — who works on what, escalation paths, team ownership. It's not meant to be a categorization system for topics. The moment you start carving out queues per subject ("eSIM", "QR codes", "portability"...), you get exactly the sprawl you're seeing now, where agents don't know where they stand.

For categorizing the type of request, the right mechanism is Services. This is the cleaner approach for several reasons:

- SLAs attach to Services. You can define an "eSIM" service (or sub-services like eSIM / Activation, eSIM / QR, eSIM / Portability) and assign your 4-hour first-response SLA directly to it. That's exactly the requirement you described.
- Routing becomes trivial. Once a ticket carries a Service, you can route it to the appropriate queue based on that Service — so the categorization (Service) and the ownership (Queue) stay cleanly separated instead of fighting each other.
- Analytics fall out naturally. Services are a first-class reporting dimension, so your "how many eSIM tickets, what's our response time" questions become straightforward stats rather than subject-line grep.

I'd strongly suggest skimming some basic ITIL/ITSM material on the Service vs. Queue distinction before committing to a structure — it's the conceptual piece that makes everything downstream click, and it'll save you a restructure in six months.

If full Services feel like too much overhead right now, a lighter-weight alternative is a Dynamic Field (e.g. a dropdown "Product Category" with an eSIM value). You lose the native SLA linkage, but you keep clean categorization and analytics, and you can always graduate to Services later.

On the PostMasterFilter question specifically: a filter is just match condition → set X. It scans incoming mail (headers and/or body) and writes values onto the ticket — including Queue, Service, SLA, or any Dynamic Field. So your "eSIM in subject or body → route + tag + SLA" flow is exactly what it's for. The filter itself is genuinely easy to configure; the only real prerequisite is having clear process logic underneath it — i.e. decide your Service/DF structure first, then the filter is a five-minute job that just stamps the right Service onto the ticket, and your Service→Queue and Service→SLA rules do the rest.

So the recommended order is: (1) define the eSIM Service + SLA, (2) set up Service→Queue routing, (3) add a PostMasterFilter that matches 'eSIM' and sets the Service. Don't make the filter do everything by hand — let it set the Service and let your existing Service config handle routing and SLA.