Queue Design and Structure Best Practices – Assembled

Queues are one of the most important configuration decisions in Assembled. They determine how your contact volume is grouped for forecasting, scheduling, real-time monitoring, and reporting.

Getting queue design right early saves time later. Getting it wrong usually shows up as inaccurate forecasts, confusing staffing requirements, or large volumes of tickets sitting in No queue. This article explains how to design queues around staffing reality, so your forecasts and staffing plans stay accurate as your support operation grows.

Note: Many of the concepts below work slightly differently under the Salesforce Cases Lifecycle model. If you have specific questions about that setup, reach out to your support team.

The one principle to remember: A queue is the core unit in Assembled — it's what you generate requirements within, and the level you staff against. Design queues around who works the tickets, not around your contact platform's views and tags or around individual channels. If the same agents handle the work, it usually belongs in the same queue.

In this article

• What is a queue in Assembled?
• How Assembled assigns a ticket
• How channels work within a queue
• When should you create a separate queue?
• How to set up a queue
• Reference
  • How queues drive requirements
  • Writing queue rules
  • Exclusions vs. No queue
  • Fallback queues
  • Parent/child queues
• Keeping queues healthy
• Example structures
• Need help?

What is a queue in Assembled?

Your contact platform organizes how tickets are handled — through views, inboxes, and tags. Assembled queues organize how teams are planned. These are different concepts, and queues are not meant to mirror your contact platform structure one-to-one. A queue is the level you actually staff to, and the unit Assembled generates a requirement for.

It helps to think of queues in terms of supply and demand. When you create a queue, you're segmenting your demand — the work to be done. Assembled then builds staffing requirements from the combined volume of each queue-and-channel combination, so you can plan your supply (your agents) against it. In other words, you're breaking demand apart now so you can manage supply later, which is why you should design queues around how you'll staff the work.

A queue in Assembled isn't necessarily the same as a queue in your contact platform. In particular, Assembled queues aren't used for routing — routing stays in your contact platform — so there's no need to mirror that structure here. Designing around staffing instead will give you the most accurate plan.

Assembled does provide reporting, but its primary purpose is staffing, forecasting, scheduling, and real-time management. Build your queues with those jobs in mind; Assembled isn't meant to report on everything at the lowest level of granularity. It complements your contact platform and helps you plan for the work that arrives there — it doesn't replace it.

Keep in mind: The two most common setup mistakes both come from treating a queue as a categorization system (like contact-platform tags) rather than as a staffing unit:

• One queue per contact-platform view. If one team handles tickets from 100 views, you likely need one queue in Assembled, not 100.
• A separate single-channel queue for each channel. Because a single queue already plans each of its channels independently, you can add phone, chat, and email to one queue instead of building three — even when different teams staff them.

How Assembled assigns a ticket

It helps to know the order in which a ticket moves through Assembled, because several design decisions depend on it:

1. Integration data is pulled in from your contact platform(s).
2. Channel mapping happens in the backend — the ticket is assigned to a channel.
3. Exclusion rules are applied — the ticket may be removed from planning.
4. Queue rules are applied — the ticket is matched to a queue.
5. Fallback rules apply, if you've configured any.
6. Anything still unmatched lands in No queue.

The key takeaway is that channel mapping happens before queue mapping. You can't route a ticket to a channel using a queue rule because the channel is already decided by the time queue rules run. In practice this makes your queues simpler.

How channels work within a queue

When you add multiple channels to a single queue, you are not blending them. A queue named Support with Phone, Email, and Chat selected effectively becomes three planning units — Support – Phone, Support – Email, and Support – Chat — and each gets its own requirement, calculated with a methodology suited to that channel.

Because of this, there's nothing to gain from creating three single-channel queues, such as Support Phone – Phone, Support Email – Email, and Support Chat – Chat. You'd just be duplicating the channel in the queue name and giving yourself more to click through in Assembled.

If you genuinely want channel-specific queues, that's completely fine. But you usually don't need them: since each channel in a queue is already planned independently, one queue with multiple channels works even when different teams staff each channel. Make it your default wherever that's a viable option.

When should you create a separate queue?

The test is always staffing: do the same people work it? If so, keep it together.

Less is more: Every queue you create brings its own forecast model, its own staffing parameters, and ongoing maintenance with it. When in doubt, lean toward fewer queues. Assembled is meant to be easy to use, and unnecessary complexity works against that rather than making your plan more accurate.

Good reasons to use separate queues

• Different agent groups own the work (for example, Tier 1 vs. Tier 2).
• Language-specific staffing.
• Different SLAs or service goals.
• Inconsistent skilling (see below).

Cross-training is one of the clearest signals. A body of work handled by a group of cross-trained agents is usually synonymous with a single queue, so broad multi-skilling points toward combining. The exception is when skilling is inconsistent: don't group agents together unless they all, or nearly all, share the same skills.

Reasons that are not enough to split

Keep these in a single queue:

• Multiple views, inboxes, or tags in your contact platform handled by one team. Use OR-based rules instead.
• Multiple channels, even when a different team owns each one. Each channel in a queue is planned independently, so use channel mapping.
• Multiple brands handled by the same team.
• Tickets from multiple contact platforms. You can handle these in a single queue, and you'll see a separate line within the queue for each source.
• Labeling preferences that don't affect staffing.

How to set up a queue

1. Go to Settings > Queues and exclusions.
2. Add a queue.
3. Associate the relevant channels with the queue.
4. Add queue matching rules.
5. Set rule priority anywhere queues or rules can overlap.
6. Add exclusions for non-plannable traffic.
7. Optionally configure fallback queues, only where there's genuine ambiguity.
8. Save, and remap historical tickets if needed.
9. Validate your Assigned, No queue, and Excluded counts.

Start simple. You don't need a perfect queue architecture on day one. Begin with queues that match your largest groups of agents, add complexity only when there's a clear operational reason, and refine over time.

Verifying your setup

You don't have to validate queues on your own. Our support team can confirm everything is mapping as expected.

Reference

How queues drive requirements

Every unique channel + queue combination gets its own:

• Volume forecast.
• SLA configuration.
• Required staffing calculation.

Writing queue rules

A ticket belongs to only one queue. Assembled assigns each ticket to at most one queue at a time. To keep assignment predictable:

• Keep rules as distinct as possible, and avoid unnecessary overlap.
• Where overlap is intentional, control it deliberately with priority.

Exclusions vs. No queue

Excluded tickets and No queue tickets are not the same thing. Use exclusions for traffic you don't want in planning at all, such as spam, bot-only interactions, and other non-operational inbound.

Keeping queues healthy

Watch your No queue volume. On Settings > Queues and exclusions, No queue means a ticket arrived on a tracked channel, didn't match any queue rule, and wasn't excluded. Keep this number close to zero. A high No queue count usually means:

• Missing or incomplete queue rules.
• Mismatched rule criteria (a wrong field, a stale tag, or a typo).

Example structures