Skip to main content

Queue Design and Structure Best Practices

  • Updated

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?

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. See How channels work within a queue.

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. If you have tickets tagged support arriving across phone, chat, and email, a single rule (tag = support) is enough — Assembled sorts them into the right channels for you.

Note: Custom channel mappings can be configured in the backend. Reach out to support if you need this.

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. Blended staffing is something you schedule separately; it isn't controlled in queue configuration.

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.

You'll assign agents to queues and channels elsewhere in Assembled, not in queue configuration, so this doesn't need to shape how you set up the queue itself. It's entirely possible to have some agents working a single channel within a queue alongside others who work all of them.

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. If only some of the agents are multi-skilled, break the work into separate queues and assign agents to multiple queues later where needed. In short, total multi-skilling tends toward one queue; partial multi-skilling tends toward separate queues.

Splitting demand doesn't fragment your agents. Assigning one agent to more than one queue is completely normal. A bilingual agent can sit in both a German queue and a French queue, count as productive toward both, and you'll still see the requirement for each language distinctly. So when staffing genuinely differs, don't avoid splitting out of concern for shared agents.

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 (one queue, multiple channels).
  • 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. For example, add tag = support from your ticketing platform and phone queue = support from your phone platform within the same queue, and Assembled will handle both.
  • 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 (see Writing queue rules).
  5. Set rule priority anywhere queues or rules can overlap.
  6. Add exclusions for non-plannable traffic (see Exclusions vs. No queue).
  7. Optionally configure fallback queues, only where there's genuine ambiguity (see Fallback queues).
  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.

Tidy the view. If your Queues and exclusions page gets noisy, use the Hide rules toggle to make it easier to read.

Verifying your setup

You don't have to validate queues on your own. Our support team can confirm everything is mapping as expected, and we're glad to help, especially if you've made a lot of changes. If you'd like to spot-check yourself, you can:

  • Look for queues showing zero volume, which usually points to a rule problem.
  • Audit tickets directly from the count cards to see what matched.
  • Use Search by platform ID, and download case data to cross-reference if needed.
  • Reconcile against a contact-platform export over a short time window.

Either way, reach out and we can validate the setup with you.

Reference

How queues drive requirements

Every unique channel + queue combination gets its own:

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

Behind the scenes, Assembled splits each queue's requirement into 15-minute intervals. This is also why queue sprawl creates planning overhead quickly: each extra queue, and each unnecessary channel split, is another forecast unit to maintain.

If a queue receives fewer than roughly 50 contacts per day, spreading that small a volume across 15-minute intervals produces little useful signal. A good rule of thumb is to merge queues under about 50 contacts per day where you reasonably can, especially if they share the same agents.

This isn't a hard rule, though. As a general principle, the more you aggregate volume, the better your forecast accuracy and staffing signal. But a low-volume queue can still be perfectly valid: if a queue is genuinely low volume and independent, go ahead and set it up that way.

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.

Keep in mind: Outside the Salesforce Cases Lifecycle model, a ticket can only appear in one queue at a time, and it will move between queues as changes are made in your contact platform. For example, if a tag or group changes, the ticket re-matches and can land in a different queue, or in an exclusion. The key point is that Assembled doesn't keep a history of these moves: it tracks one ticket in one place, as it is now. So if you need the same work to report in more than one place, you'll need to generate additional tickets within your contact platform.

Rule priority. When a ticket matches more than one queue, priority decides the winner:

  • Higher priority beats lower priority.
  • If priorities are equal, the alphabetically first queue name wins.
  • Priority levels, lowest to highest: None, Lower, Low, Medium, High, Higher.
  • As a tip, give specific or exception-handling rules the highest priority.

AND/OR logic. Rules can be as broad or as specific as you need:

  • Multiple rules within a queue are treated as OR.
  • Conditions within a single rule group can use AND or OR.

For example, a rule that matches only Tier 1 tickets from a specific group would read: Tag is exactly tier1 AND Group is exactly escalations.

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.

Status Meaning
Assigned to queue Ticket matched a queue's rules.
No queue Ticket was tracked but didn't match any rule.
Excluded Ticket matched exclusion logic and is removed from scheduling and reporting volume.

Important: Leaving a ticket unmapped is not the same as excluding it. An unmapped ticket lands in No queue, where it still counts toward channel volume but not toward any queue's volume. Excluding a ticket removes it from planning entirely. Don't rely on No queue as a stand-in for exclusions — map the volume to a queue, or exclude it deliberately.

Fallback queues

Fallback queues are optional. Use them only when there's genuine ambiguity in your contact platform that you can't resolve with rules. A fallback queue can mask a problem rather than fix it, so a better habit is to monitor No queue and resolve those tickets directly by adding a queue rule or an exclusion.

Parent/child queues

You only need parent/child queues if you want a staffing requirement built on aggregated volume rather than on the individual queues' volumes.

If you just want to see the combined requirement of Queue A and Queue B, you don't need a parent queue. You can multi-select queues to view their requirement together. That's different from a parent queue, which maintains its own forecasting model and staffing parameters. Also keep in mind:

  • Parent queue forecasts are not automatic sums of child forecasts.
  • Child actuals can roll up for reporting.
  • Forecasting and staffing settings still need to be configured at the queue level.
  • Aggregating volume changes the staffing math. For phone and chat, the Erlang calculation returns a different requirement for one large volume than for the same volume split across smaller queues, because it assumes economies of scale at higher volumes. So a parent queue's requirement won't match the sum of its children's.

Avoid the temptation to use parent queues purely to tidy up your Queues and exclusions page.

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).

Fix this quickly. The longer rules go unmaintained, the less reliable your data is within Assembled. Map unmatched tickets to a queue or an exclusion rather than leaving them in No queue.

Example structures

Situation Recommended setup
One team, many views — same team handles billing, shipping, and returns across many views One queue with OR-based matching logic.
One team, multiple channels — same agents handle chat, email, and phone One queue with all three channels associated, avoiding separate single-channel queues.
Tiered support — Tier 1 and Tier 2 are staffed separately Separate queues with clear rule boundaries and explicit priority.
Language staffing — English and Spanish teams are scheduled independently Separate language queues aligned to staffing ownership.

Need help?

If you'd like a review of your queue strategy or rule structure, or want us to validate changes you've made, we're glad to help.

Questions? Contact support@assembled.com or reply to your existing support thread, and we'll be glad to help.

Related articles

Comments

0 comments

Article is closed for comments.