Want help applying this guide?Ask the DripTell team
A planning report can look precise and still be wrong. Suppose the same messaging queue appears in a regional group and again in a product group. Both plans count the same conversations. The staffing total rises, but customer demand has not changed.
The practical answer is simple: define each planning group around a stable combination of queue and channel, place that combination in one group only, and share service objectives only when the work genuinely behaves alike. Microsoft calls a planning group the foundation for forecasts, capacity plans, schedules, and performance reports. That makes the boundary an operating decision, not an administrative label.
Start with a boundary people can explain
A group should answer three questions without opening the software. Which demand enters? Which team owns it? Which clock and service promise apply?
- Demand scopeList every queue and channel combination included in the group.
- Single placementConfirm each combination appears in one planning group only.
- Named ownerAssign the team responsible for accepting and recovering the work.
- Shared objectivesRecord the time zone, service target, shrinkage, occupancy, and concurrency.
- Change evidenceKeep the author, effective date, reason, and affected plans for every edit.
Microsoft's planning group guidance says a group combines queue and channel pairs, a time zone, and service objectives. It also says one queue and channel combination can belong to only one planning group. That rule prevents the same volume entering two forecasts.
Do not begin with team names such as General Support or Tier Two. Those names change. Start with observable work. Voice calls in the billing queue are one combination. Messaging conversations in the billing queue are another. They may belong together, but first record them separately.
If you run a shared support operation, name one owner for this map. A diagram with no accountable maintainer becomes stale as soon as someone adds a queue.
Map every queue and channel before grouping
Export or list every active queue. For each queue, add every channel that can deliver work, the operating time zone, the team that can accept it, and the service objective. Then mark the proposed group exactly once.
The useful review is not whether every row has a value. It is whether two rows describe the same incoming work. A renamed queue, a routing alias, or a shared overflow destination can hide duplication. Trace one real conversation from entry to ownership. If it appears in two planning scopes, fix the boundary before forecasting.
| Decision signal | Keep combinations together when | Split them when | Risk if ignored |
|---|---|---|---|
| Demand pattern | Peaks and quiet periods are similar | One stream peaks at different hours or seasons | The average hides a shortage |
| Handling effort | Work needs comparable time and skill | One stream needs specialist or longer work | Staffing is shifted to the wrong work |
| Service promise | Response targets and operating hours match | Targets, time zones, or coverage differ | A shared target misstates performance |
| Ownership | The same team can accept the work | Different teams control acceptance and recovery | Demand is counted without a clear owner |
A team inbox can preserve assignment and history, but the planning map still needs an explicit demand boundary. Inbox visibility does not prove that a forecast is scoped correctly.
Share objectives only when the work behaves alike
Microsoft documents service level, target answer time, shrinkage, occupancy, and concurrency as planning-group objectives. Reusing one set of values is convenient. It is only honest when the grouped work shares those assumptions.
Voice and messaging are the obvious test. Voice normally has concurrency of one. Messaging may allow more than one simultaneous interaction, depending on the operating model. Combining both under one unexplained concurrency value can produce a tidy plan that nobody can defend.
The same caution applies to time zones. A global label is not enough. If one queue follows Dubai business hours and another follows Amsterdam coverage, separate them or document exactly how the schedule crosses those clocks. Keep the decision and its reason in the customer record context, not only in one planner's notes.
Connect forecast capacity and schedule in order
A forecast estimates incoming volume and handling time. A capacity plan applies service objectives to calculate required representatives. A schedule turns that requirement into shifts. Reversing this order makes yesterday's roster look like tomorrow's need.
Microsoft's capacity planning documentation explains that capacity plans can be viewed by channel and queue and that higher shrinkage increases the representatives required to meet the service target. Treat those views as a check on the group boundary. If a group total changes unexpectedly, drill back to the combinations inside it before changing headcount.
Automation rules can route work, while AI assistance may affect how much human work remains. Neither should silently rewrite the planning scope. Record when a routing or automation change takes effect, then compare demand before and after that date.
Audit the group before publishing a schedule
Run four checks. First, every active queue and channel pair appears once. Second, every group has one owner and time zone. Third, its service objectives match the work inside it. Fourth, the forecast, capacity plan, and shift plan refer to the same group.
Use a closed historical period for the rehearsal. Sum the group combinations and compare the result with the original channel and queue reports. A mismatch needs an explanation, not an adjustment hidden in shrinkage or occupancy.
Keep access to planning changes limited and reviewable through your security controls. The important evidence is who changed the boundary, what moved, when it became effective, and which published plans were affected.
When the map passes, publish the schedule. When it does not, stop. A delayed plan is easier to repair than a confident plan built on demand counted twice.
Frequently Asked Questions
What is a support planning group
It is a defined set of queue and channel combinations that share a time zone and service objectives for forecasting, capacity planning, scheduling, and reporting.
Can one queue belong to two planning groups
The queue name can appear with different channels, but the same queue and channel combination should belong to only one planning group. This avoids double counting the same demand.
Should voice and messaging be in one group
Only when their demand pattern, ownership, service objectives, time zone, and concurrency assumptions can be planned together honestly. Otherwise split them.
How often should planning groups be reviewed
Review them whenever queues, routing, channels, ownership, operating hours, or service targets change, and before using a new group to publish schedules.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy