A customer asks a difficult product question. Your best specialists are busy, but several capable generalists are free. Should the customer wait a little longer for the closest match, or should the queue widen now?
That is the decision behind bullseye routing. Set each wait threshold at the point where the likely value of extra expertise no longer justifies more customer delay. Do not copy a sample timer. Use your own conversation evidence, preserve the earlier specialist groups when the pool expands, and test the complete assignment and fallback path before release.
Start with the cost of waiting
Microsoft describes bullseye routing in Dynamics 365 Contact Center as a progressive assignment method. A conversation starts with a targeted user group. As its wait time reaches configured thresholds, more groups become eligible. Earlier groups stay active and keep higher priority rather than being replaced (Microsoft configuration guide).
That makes the first design question practical, not technical. What does the customer gain by waiting for the narrowest group? A billing specialist may prevent a costly correction. A general product question may not deserve the same delay. Write down the decision the first group is uniquely qualified to make. If you cannot name it, the first ring may be too narrow.
Use evidence from the affected support operation. Review wait distribution, first-group acceptance, later transfers and work that genuinely needs specialist authority. Averages hide the longest waits.
Map groups by safe capability
A bullseye level should mean “these people can safely own this work,” not “these people have a more senior title.” Build the first group from representatives who can complete the specific task. Add a second group that can resolve the common variants. The broadest group should still be qualified to take a useful next action, not merely available.
Microsoft says user groups can reflect skill, language, region or another useful attribute. The platform still checks presence, capacity and configured skills. Queues sharing one playbook must also share its user groups. Otherwise, use separate playbooks.
| Routing decision | Evidence to inspect | Safe action | Warning sign |
|---|---|---|---|
| Keep the narrowest group | Specialist acceptance and first contact resolution | Preserve a short exclusive window | Most work is transferred or is routine |
| Add the next group | Wait distribution and broader group competence | Widen before delay becomes unreasonable | The new group cannot complete the common task |
| Add the broad group | Long waits and peak capacity | Include every genuinely qualified owner | Availability is being mistaken for competence |
| Use the fallback | No eligible owner after all levels | Offer an owned alternative | The conversation remains waiting without a promise |
Set thresholds from observed tradeoffs
Freeze a baseline for one queue. Record when a suitable specialist became available, when a broader representative could have accepted, whether a transfer followed and whether the customer abandoned. Remove personal identifiers. Keep timing and outcome, not transcripts.
- 1Name the specialist valueState what the narrowest group can safely resolve that the wider group cannot.
- 2Build qualified groupsInclude only people who can own a useful next action for this work.
- 3Choose cumulative timesSet each expansion point from observed waits and the value of added expertise.
- 4Prove the runtime pathTest presence, capacity, skills, priority, transfer reset and fallback.
- 5Release one queueChange one threshold at a time and keep the prior playbook ready.
Choose a conservative first threshold that gives the best-fit group a real chance without consuming the customer's patience. Set the next threshold from the delay you can defend for the capability added. Keep urgent or sensitive work on a separate path.
Dynamics 365 measures these thresholds cumulatively from the first human assignment attempt. They are not fresh timers after each expansion. The configuration guide also documents platform minimums, allows consecutive levels to share a time while preserving their priority order, and says a transfer to another queue restarts evaluation at the new queue's first level. Those details belong in your test sheet because a mistaken timer model can make a reasonable design behave badly.
Test the complete assignment path
Create synthetic conversations for the main work types. Hold representative presence and capacity deliberately so each test reaches a different level. Confirm the shared inbox shows one continuous customer history and a clear owner after assignment.
For every case, capture the arrival time, groups eligible at each point, representative selected, skills and capacity considered, assignment time, any transfer, and final outcome. Use assignment rules to keep ownership explicit outside the Dynamics test as well.
Test at least these conditions:
- A specialist accepts before expansion.
- The next group joins at the intended cumulative time.
- An earlier group becomes available later and keeps priority.
- The assignment strategy chooses among several eligible people.
- A new queue restarts evaluation.
- The named fallback runs when nobody is eligible.
Do not approve a playbook because the natural-language draft looks sensible. Microsoft says the system converts a published playbook into a structured runtime format. Read validation warnings, publish only in a controlled environment, and verify the behavior with diagnostics and test conversations.
Keep expansion separate from overflow
Bullseye expansion and overflow solve different problems. Bullseye keeps the conversation in its queue while widening eligible representatives. Overflow changes the destination or outcome when the queue cannot serve the customer under defined conditions. Mixing them makes failures hard to interpret.
Test the bullseye levels first. Then add priority or overflow behavior as a separate scenario. If no qualified person can own the work, use an honest callback, alternative queue or other approved fallback. A fast wrong assignment is not a service improvement.
The release plan listed public preview in July 2026 and general availability for October 2026, while warning that planned dates and functionality can change (Microsoft release details). Confirm availability, licensing and geography in the actual environment before making a customer promise.
Release one queue and review real outcomes
Start with one voice or messaging queue, stable groups and a limited observation window. Freeze unrelated automation changes. Watch waits by level, assignments, transfers, abandonment, callbacks and customer corrections. Review the longest waits individually.
Do not use these results to rank or punish representatives. They are evidence about routing design and capacity. Adjust one threshold or group boundary at a time, repeat the same synthetic tests, and keep the prior playbook ready for rollback.
DripTell can keep conversation history, ownership and a human handoff together across channels, but it does not choose Dynamics thresholds for you or replace tenant-specific testing. If your team is coordinating AI assisted routing with a broader customer journey, talk to the implementation team before expanding beyond the first queue.
Frequently Asked Questions
What is a bullseye routing wait time
It is the cumulative time from the first human assignment attempt at which another configured user group becomes eligible for the conversation.
Should every queue use the same thresholds
No. Use separate settings when customer urgency, specialist value, staffing pattern or shared user groups differ. One convenient timer can hide very different service risks.
Does a wider level replace the specialist group
No. Microsoft documents cumulative expansion. Earlier groups remain eligible and retain higher priority after later groups join.
What should block release
Stop if groups are not safely qualified, cumulative timing is misunderstood, transferred conversations restart unexpectedly, diagnostics disagree with the design, fallback has no owner, or the feature is unavailable in the intended environment.
Want help applying this guide?Ask the DripTell team
From reading to action
Want help applying this to your business?
Share your details. We will read the article you are on and start with a useful answer for your team.
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
