The order those items are in came from somewhere. It reflects a decision about what matters more than what else — which customer waits, which invoice gets paid this week, which exception gets looked at before the close. That is a prioritization policy. In our experience it is rarely one anybody can attribute to a person, a date, or a reason.
Often it turns out to be a sort order. Sometimes a default that shipped with the module.
Sequencing Used to Be Visible
The reason this goes unnoticed is that the decision moved without anyone announcing it.
Deciding what gets worked first used to be a supervisor’s job. It happened in the open, at a desk or a whiteboard, and it was arguable — you could go and say a particular account should jump the queue, and get an answer with a reason attached. It was inconsistent and it was sometimes unfair, but it was legible, and it belonged to somebody whose name you knew.
Now the same decision is made by configuration, at scale, before anyone arrives. It is more consistent and considerably more defensible than a supervisor’s mood. It is also rarely examined, because it no longer looks like a decision. It looks like a screen.
Where the ERP Is Actually Deciding
Worth being specific, because the mechanisms are ordinary and that is exactly why they escape review.
- Default sort order. Oldest first is not a neutral display choice. It is a policy — first in, first out — chosen over “largest value first” or “closest to a deadline first.” Most queues inherit it without discussion.
- Planning priority. In Dynamics 365 Supply Chain Management this is an explicit, named object: priority models with a numeric scale, coverage codes set to priority, and a setting that caps supply priority at the priority of the demand it is linked to. Priorities are set per order line. So the sequence in which demand gets met is a configured policy with its own setup page — which makes it more discoverable than most items on this list, and no more frequently revisited.
- Allocation and reservation rules. Which order gets scarce stock is decided by reservation policy and the order in which on-hand is consumed. That is sequencing with a direct revenue consequence attached.
- Credit limits and holds. An order on credit hold has not been deprioritized. It has left the fulfillment queue. This is a stronger intervention than any ordering rule and it is usually treated as a finance control rather than a sequencing one.
- Approval thresholds and routing. A threshold decides which items reach a person prospectively at all. Sub-threshold items are typically still posted and logged and remain available for sampling — but they are out of the forward queue, which is where the work actually gets allocated.
- Escalation hierarchies. Not just that something escalates, but who it escalates to, after how long, and who it auto-delegates to when they are away. That chain is where a good deal of real sequencing power sits.
- Batch and job schedules. What runs overnight determines what exists to be worked in the morning. A posting job at two produces a different Tuesday than one at six.
- Agent confidence thresholds. The newest and fastest-moving. Where an agent handles the routine and escalates the rest, its threshold sets both the size and the composition of the human queue — composition because confidence tracks how typical an item is, so what lands with a person skews systematically toward the novel and the awkward. Tune the threshold and you have reshaped somebody’s day from a screen that looks like a technical setting.
The Thing That Makes It Invisible
No individual ever experiences a sequencing decision. They experience their queue.
The policy only exists in aggregate — across a month, across every item worked, deferred, escalated or never surfaced — and aggregate is the one view that is not on anyone’s screen. Each person sees a list that looks reasonable. The pattern those lists add up to is nowhere.
That is why this can run wrong for years without producing a complaint. Complaints come from people, and people cannot see it.
Three Ways It Goes Wrong
- Urgency displaces value. Most defaults sort on time, because time is unambiguous and value is contested. So the oldest item wins rather than the most consequential one. Nobody defends value-blind ordering as a way of maximizing value — they defend it, reasonably, as a way of being fair, which is a different claim and worth separating.
- Every queue is efficient and the flow is not. Local sequencing rules can each be sensible while the handoffs between them stall. Optimizing a queue and optimizing a process are different activities, and only the first has an obvious owner.
- Silent triage. The most consequential items are the ones that never appear — filtered by status, below a threshold, on hold, routed to a queue nobody works. Absence generates no signal, so this failure conceals itself.
And One That Happens After Sequencing
Worth separating from the three above, because it is a response to measurement rather than a property of the ordering rule.
Once queue depth is reported, work gets shaped to clear it. In service operations this has a name — cherry-picking — and the research literature on performance-based contracting calls the two halves creaming and parking: take the easy items, set the hard ones aside. Throughput improves while the underlying position does not.
It is not inevitable. It arrives wherever people can choose their own next item and difficulty is visible before they choose. Push-assigned work with no self-selection largely prevents it, which is itself a sequencing design decision.
Where the Argument Cuts the Other Way
System sequencing is mostly an improvement, and the point is not to hand this back to a supervisor with a whiteboard.
Configuration is consistent where a person is variable, applies the same rule to the customer nobody likes, produces evidence of what was worked and when, and removes a real administrative burden from people with better things to do. Human sequencing was also biased — it was simply biased less inspectably. Arguing to hand sequencing back wholesale would be arguing for less fairness and less auditability.
There is a second point that costs the thesis something. Some sequencing genuinely should not be adjustable on request. Change-controlling ordering rules is often what keeps a control effective: a queue any manager can reorder is a queue that will be reordered under pressure by whoever is loudest. What makes that a control is not rigidity itself but the fact that changes require authorization and leave a trace — and where that holds, the right answer to “why is this the order?” may simply be “because it is not ours to change.”
Making the Rule Explicit
None of what follows requires reconfiguring anything. It requires describing what is already happening.
- Write the sequencing rule for each significant queue in one sentence of business English. Not the sort expression — the intent. “Oldest first, regardless of value.” Where that sentence cannot be produced, that is the finding.
- Separate urgent from valuable, deliberately. Most defaults conflate them because time is easy to sort on. Deciding which should dominate, per queue, is a short conversation that rarely happens.
- Look at the aggregate once. For one month: what got worked, what aged, what escalated, and what sat untouched. The last category is the interesting one and the hardest to produce, which is informative in itself.
- Ask what never appeared. Below threshold, on hold, wrong status, routed elsewhere. Highest-value question on this list, because the answer is invisible by construction.
- Treat the batch schedule as a business policy. It determines what work exists each morning, so it wants a business owner alongside the technical one.
- Treat an agent’s confidence threshold as a workload control. Whoever tunes it is sizing and shaping a person’s day.
The Broader Version
There is a general pattern here that reaches past queues.
Systems increasingly make small allocative decisions at a volume no person could — what surfaces, what waits, what routes where, what never appears at all. Individually each is trivial. In aggregate they constitute an operating policy, and they are seldom described as one, because each was configured as a technical detail by somebody competently solving a narrow problem.
Which brings it back to the thing that makes this hard to see at all: no individual ever experiences a sequencing decision. They experience their queue. The policy is real, it is running today, and it is only legible from a vantage point nobody currently occupies.
DAX Software Solutions tends to encounter this while doing something else. Optimization and rescue work surfaces it — you go in to look at performance or a stalled process, and among what you find is a set of sequencing, threshold and routing rules nobody has revisited since go-live, quietly setting the shape of people’s work. Our guide to rescuing an underperforming ERP treats batch schedules and workflow design as things to examine rather than assume, which is the same instinct applied one layer down.
Describing what the rules currently are is cheap. It is also the step that tells you whether changing them is worth doing. Worth a conversation if you suspect the order of your queues is currently unattributable.