Queue design best practices

Plans and permissions:

• Set up queues: Admin role, or a custom role with Queue configuration set to Can configure queues

Use these guidelines to decide how many queues to create and how to structure them. Queues decide how your contact volume is grouped for forecasting, scheduling, real-time monitoring, and reporting, so a poor structure shows up as inaccurate forecasts, confusing staffing requirements, or many cases in No queue.

The main principle: a queue is the unit Assembled calculates a staffing requirement for, and the level you staff against. Design queues around who works the cases, not around your contact platform’s views and tags or around individual channels. If the same team members handle the work, it usually belongs in the same queue.

You set up queues in Configure > Queues and exclusions. For the steps, see Queues and exclusions.

Note: If you use the Salesforce case lifecycle, some of what follows works differently. For advice on that setup, contact our team.

What a queue is in Assembled

Your contact platform organizes how cases are handled, through views, inboxes, and tags. Assembled queues organize how your team is planned. They’re different concepts, and queues aren’t meant to mirror your contact platform one-to-one.

• Queues segment demand: each queue splits out a piece of the work, and Assembled builds a staffing requirement for each queue and channel so you can plan your team against it. Split demand the way you’ll staff it.
• Queues aren’t used for routing: routing stays in your contact platform, so there’s no need to copy its structure into Assembled.
• Queues are built for planning: Assembled has reporting, but its main jobs are staffing, forecasting, scheduling, and real-time management. It complements your contact platform rather than replacing it, and doesn’t aim to report on everything at the lowest level of detail.

The two most common setup mistakes come from treating queues like contact-platform tags instead of staffing units:

• One queue per contact-platform view: if one team handles cases from 100 views, you probably need one queue, not 100.
• A separate queue for each channel: one queue already plans each of its channels separately, so add phone, chat, and email to one queue, even when different teams staff them. See How channels work within a queue.

How Assembled assigns a case to a queue

Several design decisions depend on the order in which a case moves through Assembled:

1. Data comes in from your contact platforms.
2. The case is assigned to a channel.
3. Exclusion rules are applied, and the case may be removed from planning.
4. Queue rules are applied, and the case is matched to a queue.
5. Fallback queues apply, if you’ve set any.
6. Anything still unmatched shows as No queue.

Because the channel is decided before queue rules run, you can’t use a queue rule to send a case to a channel. This keeps queues simpler: if cases tagged support arrive by phone, chat, and email, one rule (tag is exactly support) is enough, and Assembled sorts the cases into their channels.

To change how cases are mapped to channels, contact our team.

How channels work within a queue

Adding several channels to one queue doesn’t blend them. A queue named Support with Phone, Email, and Chat works as three planning units, Support – Phone, Support – Email, and Support – Chat, and each gets its own requirement, calculated with a method suited to that channel. Blended staffing is something you schedule; it isn’t set in queue configuration.

So there’s nothing to gain from creating three single-channel queues, such as Support Phone, Support Email, and Support Chat. You’d repeat the channel in the queue name and have more queues to manage.

Channel-specific queues are fine if you want them, but you usually don’t need them. Because each channel in a queue is planned separately, one queue with several channels works even when different teams staff each channel. Make it your default where you can.

You assign team members to queues and channels in their profiles, not in queue configuration. Some team members can work one channel in a queue while others work all of them.

How queues drive requirements

Every channel and queue combination gets its own:

• Volume forecast.
• Service level settings.
• Required staffing calculation.

Assembled calculates each requirement interval by interval. This is why extra queues add planning work quickly: each extra queue, and each unnecessary channel split, is another forecast to maintain.

If a queue gets fewer than about 50 contacts a day, spreading that volume across the day’s intervals gives little useful signal. As a rule of thumb, merge queues with fewer than about 50 contacts a day where you reasonably can, especially if they share team members.

This isn’t a hard rule. In general, the more volume you combine, the more accurate your forecast and staffing. But a low-volume queue can still be right: if it’s low volume and staffed independently, set it up as its own queue.

Decide when to create a separate queue

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

When in doubt, create fewer queues. Every queue brings its own forecast, its own staffing settings, and ongoing maintenance, and extra queues add complexity without making your plan more accurate.

Good reasons to use separate queues

• Different groups of team members own the work, such as Tier 1 and Tier 2.
• Different languages are staffed separately.
• The work has different SLAs or service goals.
• Team members’ skills are inconsistent across the work (see below).

Cross-training is one of the clearest signals. Work handled by a group of cross-trained team members usually belongs in one queue. But only group work together if all, or nearly all, of them share the same skills. If only some people can do all of it, split the work into separate queues and assign people to more than one queue where needed. In short, full cross-training points to one queue, and partial cross-training points to separate queues.

Splitting demand doesn’t split your team. A team member can belong to more than one queue: a bilingual team member can be in both a German queue and a French queue, count as productive toward both, and you still see each language’s requirement separately. When staffing really differs, don’t avoid splitting because people are shared.

Reasons that aren’t enough to split

Keep these in one queue:

• Several views, inboxes, or tags in your contact platform that one team handles. Use rules combined with OR instead.
• Several channels, even when a different team owns each one. Each channel in a queue is planned separately.
• Several brands that the same team handles.
• Cases from several contact platforms: one queue can have rules for each platform, and you see a separate line for each source. For example, add tag is exactly support for your ticketing platform and a phone queue rule for your phone platform.
• Labeling preferences that don’t affect staffing.

Write queue rules

Each case belongs to at most one queue at a time. To keep that predictable:

• Keep rules as distinct as you can, and avoid overlap you don’t need.
• Where overlap is intentional, control it with Rule priority.

Keep in mind: A case moves between queues as it changes in your contact platform. If a tag or group changes, the case is matched again and can land in a different queue or in an exclusion. Assembled tracks each case in one place, as it is now, and doesn’t keep a history of these moves. If you need the same work to count in more than one place, create additional cases in your contact platform. This works differently with the Salesforce case lifecycle.

When a case matches more than one queue, Rule priority decides:

• Higher priority wins. From lowest to highest, the levels are None, Lower, Low, Medium, High, and Higher.
• If priorities are equal, the queue whose name comes first alphabetically wins.
• Give specific or exception rules the highest priority.

Rules can be as broad or as specific as you need:

• Separate rules on a queue are combined with OR.
• Conditions within one rule can use AND or OR.

For example, a rule that matches only Tier 1 cases from an escalations group reads: Tag is exactly tier1 AND Group is exactly escalations.

Use exclusions instead of No queue

Excluded cases and No queue cases aren’t the same. Use exclusions for traffic you don’t want in planning at all, such as spam, bot-only conversations, and other inbound that isn’t work for your team.

Important: Leaving a case unmapped isn’t the same as excluding it. An unmapped case shows as No queue, where it still counts toward its channel’s volume but not toward any queue’s volume. Excluding a case removes it from planning entirely. Don’t use No queue as a stand-in for exclusions: map the volume to a queue, or exclude it on purpose.

Use fallback queues sparingly

Fallback queues are optional. Use one only when there’s ambiguity in your contact platform that rules can’t resolve. A fallback queue can hide a problem instead of fixing it, so it’s better to watch No queue and resolve those cases by adding a queue rule or an exclusion.

Use parent and child queues for combined requirements

You only need parent and child queues if you want a staffing requirement built on combined volume, rather than on each queue’s own volume.

If you only want to see the combined requirement of Queue A and Queue B, you don’t need a parent queue: select both queues in the filter to see their requirement together. A parent queue is different, because it has its own forecast and staffing settings.

• A parent queue’s forecast isn’t the sum of its child queues’ forecasts.
• Child queues’ actuals can roll up for reporting.
• Forecasting and staffing settings are still set for each queue.
• Combining volume changes the staffing math: for phone and chat, Erlang C gives one large volume a different requirement than the same volume split across smaller queues, because larger volumes are more efficient to staff. So a parent queue’s requirement won’t match the sum of its children’s.

Don’t use parent queues only to tidy the list on Queues and exclusions.

Set up queues

You don’t need a perfect queue structure on day one. Start with queues that match your largest groups of team members, add more only when there’s a clear operational reason, and refine over time.

1. Add a queue in Configure > Queues and exclusions.
2. Choose the channels for the queue.
3. Add case matching rules. See Write queue rules.
4. Set rule priority wherever queues or rules can overlap.
5. Add exclusions for traffic you don’t plan for. See Use exclusions instead of No queue.
6. Optional: set fallback queues, only where there’s real ambiguity. See Use fallback queues sparingly.
7. Save, and re-sort past cases if needed.
8. Check your Assigned to queue, No queue, and Excluded counts.

For the detailed steps, see Queues and exclusions. To make the queue list easier to read, use the gear icon (Configure columns) to hide the Rule column.

Check your setup

Our team can confirm that cases are mapping as expected, especially after you’ve made a lot of changes, and can review your queue structure or rules with you. To spot-check it yourself:

• Look for queues with no cases, which usually points to a rule problem.
• Open the count cards at the top of Queues and exclusions to see which cases matched.
• Use Search by platform ID in the More actions menu, and download case data to compare if needed.
• Compare with an export from your contact platform over a short time window.

Keep queues healthy

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

• Missing or incomplete queue rules.
• Rule criteria that don’t match, such as the wrong field, an old tag, or a typo.

Fix these quickly: the longer rules go unmaintained, the less reliable your data in Assembled. Map unmatched cases to a queue or an exclusion rather than leaving them in No queue. To find out why a case isn’t where you expect, see A case isn’t in the queue you expect.

Examples