The request that sat in a queue nobody opened
A support manager called me about a service request that had gone eleven days without a first response. It had been created properly, categorised properly and routed properly. The queue it reached had been built two years earlier for a second line team that no longer existed under that name, and the people who once watched that list had moved elsewhere in the business.
Nobody had retired the queue, because deleting things in a live service application keeps getting deferred to next quarter. The assignment rule pointing at it still matched. The request went exactly where the configuration said it should go, which was a list no employee had opened since the reorganisation.
Routing in Oracle CX is a short sequence of decisions, and most of the pain comes from the third and fourth rather than from rule syntax. The decisions below are stable. Setup task names, screens and individual options are not, because they move between releases and differ across the service modules in Oracle Fusion Cloud, so confirm every name in your own environment.
A queue should describe work, not a team name
A queue named after a team carries an expiry date, because the team will be renamed, merged or split within three years while the rules keep pointing at the old shape. A queue named after a kind of work outlives that.
The test I use in workshops is one question. What does a person need in order to resolve this request. If the answer describes a capability, such as billing adjustments or hardware replacement, you have described a queue. If it names a manager or a floor of a building, you have described group membership, which belongs with the people rather than the routing.
Granularity follows. Too many queues and each one is thin and easy to forget. Too few and every request needs the triage step routing was meant to remove. Start with one queue per kind of work you would staff differently at two in the morning. What a queue can hold varies between service modules and releases, so check what your instance supports.
When two rules match, somebody has to know which one wins
Most routing incidents I have investigated did not involve a broken rule. They involved two rules that both matched the same request and an administrator who could not say which one applied. The request sat in a defensible queue, just never the one the business expected.
Assignment rules evaluate in an order you control, and the behaviour on multiple matches is what to pin down first. Some configurations stop at the first match. Others keep evaluating and the last match wins. Which one your rule set does depends on the release and on how the set is defined, and I will not guess it for you. Build two deliberately overlapping rules in a test environment and watch where the request lands.
Then order from most specific to most general and put the catch-all last. Keep the set small enough that one person can hold it in their head, because long rule sets decay the same way in every tool, which is why lead routing rules stop making sense after a few years of additions. Write the intended precedence beside the rules, since the order is a business decision the configuration only records.
The fallback queue is the configuration people skip
If you change one thing after reading this, make it the default destination for requests that match nothing. It is the least interesting piece of routing configuration and the one that prevents the most damage, because work matching no rule has to land where a person looks every day.
Two failures end up there. The first is a request whose attributes match no rule, which happens constantly in the month after go-live and whenever someone adds a category without touching the rules. The second is a request routed correctly into a queue with no active members, after a leaver or a long holiday. Both need a destination with a named owner behind it.
Make the fallback uncomfortable on purpose. Report the count daily for the first few weeks, treat every arrival as a routing defect with a cause, and fix the rule instead of moving the request by hand. A fallback queue that stays empty is evidence the rules cover the real work. A fallback nobody reports on becomes the second place requests disappear.
Reassignment and the milestone clock
Milestones attach time commitments to a service request, and the moment you allow reassignment you create a question the room usually cannot answer. When a request moves from one queue to another, does the commitment clock restart, continue running, or stay pinned to the original target time. The answer changes the numbers in every service report you publish.
I will not tell you what your configuration does, because milestone behaviour depends on the release, on how the milestone is defined and on whether the change is a queue change or an owner change. Test it. Create a request, let it accrue elapsed time, move it between queues, then compare the target time and the elapsed figure before and after. Repeat for each milestone type.
Write the answer down where the reporting team can find it. The difference between a restarted clock and a preserved one shows up as a swing in the compliance percentage your service manager presents each month, and that conversation goes badly when the first honest explanation arrives in the meeting. Pause and hold states deserve the same test.
Seeing a request and owning it are different things
Visibility and accountability get conflated in almost every implementation I review. Someone who can see a request is able to help with it. Someone who owns a request answers for it. Configure those two ideas into one setting and you produce queues that forty people can read and nobody works.
Keep one accountable party at any moment, an individual or a queue with a named responsible manager, and let visibility be the broader of the two, since the queue is not the owner in any service tool. If you cannot name the human who answers for a request in a queue, that queue is unstaffed, whatever the membership list shows.
Reopen is the path nobody tests. A resolved request the customer replies to often routes somewhere different from where it was resolved, because the rules evaluate against current field values and resolution changed several of them. It lands in a general queue while the person who did the original work never hears about it.
Decide deliberately. Returning the request to the last owner suits a continuation of the same problem, and running it through the rules again suits a reopen with a new reason. Both are defensible. Find out which your configuration does by reopening a request in a test environment and following it.
Count how often a person moves the work by hand
The honest measure of whether routing works is the number of requests a human reassigned after they landed. Everything else is opinion. Pull the count of first reassignments inside the first hour of a request's life, express it as a percentage of requests created, and report it weekly to the same people.
A high reassignment rate points at the rules rather than at the people in the service centre, because the rules encode a model of the work that does not match how the work is done. Look at which queue requests leave and which they arrive at. Two or three pairs will account for most of the volume, and each one is a missing condition in a rule or a queue drawn around the wrong thing.
Before routing goes live, sit with the service manager and confirm each of the following against the configuration itself rather than the design document. Teams running a second service tool should apply the same measure there, the way we frame it for omni-channel routing in Service Cloud.
- Every queue has a named person who answers for the work in it, and that person knows they do.
- A default destination exists for requests that match no rule, and somebody opens it daily.
- Two deliberately overlapping rules were tested, and the winning rule was predicted correctly first.
- A queue with no active members was tested, and the request did not stop there in silence.
- Reassignment was tested against each milestone type, and the effect on the clock is written down.
- A reopened request was followed to its destination, and that destination was the intended one.
- The first-hour reassignment rate is reported from week one, with a name against the number.
