What is this?

There's no single "correct" way to set up an inbox in ArminCX. The right structure depends on your team, your ticket volume, and how responsibilities are split. This article walks through the five most common structuring patterns, when each one works, and how to combine them for a client's specific setup.

The five structuring patterns

Channel-based

The most commonly used pattern. Tickets get split by channel (email, WhatsApp, Instagram, etc.), sometimes further split by language for routing.

Works best for:

• CS teams of mostly generalists, where everyone can handle every topic

• Setups where language-based routing matters

Works worst for:

• Teams of specialists

• Teams with a high first response time, where time-critical topics risk sitting too long

Topic-based

Tickets get split by topic (e.g. shipping, returns, orders, product), often alongside a couple of channel-based folders for anything that doesn't fit a topic.

Works best for:

• CS teams of mostly specialists, or teams handling time-critical topics

Works worst for:

• Teams of generalists

• Teams at risk of getting bored of one topic or cherry-picking easy tickets

• Adds team-lead overhead
  🚨 Tickets that don't clearly match a topic folder risk getting lost. Don't use this pattern for analysis purposes alone, tags handle that better.

Agent-based

Tickets get split by the agent responsible, sometimes combined with a status split underneath.

Works best for:

• Teams with clear per-ticket responsibilities

• Can work well for specialist teams with smart routing

Works worst for:

• Teams without a strong team feeling

Good to know: Agent-based structuring makes performance differences between agents highly visible, for better or worse.

Status-based

Tickets get split purely by status (open, on hold, resolved, closed), sometimes combined with an agent split.

Works best for:

• Almost any team with no special requirements and lower ticket volume

• Quick to set up

Works worst for:

• Teams where incoming ticket volume outpaces what agents can resolve, since this creates a real risk of chaos

⚠️ The pattern to avoid

Splitting by topic but forgetting to also split by status usually ends in an unreadable inbox. If you're combining structures, always keep status in the mix somewhere. A topic split without a status split is the most common way an inbox turns into a mess.

The truth lies in between

For most clients, the best setup is a mix of the patterns above, based on their specific needs. A team of generalists with a couple of specific responsibilities, for example, can run a Channel-based setup with dedicated folders layered in for the specialist areas (e.g. a "B2B" folder for a B2B department, or dedicated folders for a logistics team). Other clients run one base pattern with dedicated variations for particular departments.

The question to always come back to: do you work with generalists or specialists, and how does your ticketing setup need to reflect that?

⚙️ Getting there

1. Check how the client's inbox looked before ArminCX (Zendesk, Gorgias, etc.).

   • Did it work well for them? Measure this against KPIs like FRT, CSAT, and backlog. Copy the setup and improve on it iteratively.

   • Could it be improved? Rebuild it together based on their needs.

2. Check whether the client's ArminCX team is made up of specialists or generalists.

   • Specialists → Topic-based or Agent-based, with variations.

   • Generalists → Channel-based, with variations.

   • Just one team member, low ticket volume, and/or heavy automation already in place → Status-based.

3. If the team is mostly generalists but a few members (e.g. finance or logistics) also handle a small ticket volume, build a generalist setup with dedicated folders for those members.

4. If the business has high-priority tickets like cancellations or refunds, and FRT isn't fast enough to catch them within a generalist setup, build dedicated folders for them.

5. Keep the setup lean. The more structure you add, the higher the risk of tickets flying under the radar.

6. Never build an inbox setup for analysis purposes only. Use the dashboard for analytics. The inbox is where the work happens (and where KPIs get made or broken), not where you monitor them.

You're all set and good to go!