The blank is the only trace of a skipped step
Open the escalated cases list in Service Cloud on any Monday and sort by escalation reason. Near the top is a block with nothing in that field. The weekly quality report says fourteen percent of escalated cases are missing a reason, and there is a proposal to make the field required. I have watched this meeting happen in three different organisations, and each time the room was solving the wrong problem.
A case that reaches tier two with no escalation reason did not travel the normal path. Somebody moved it by hand, or a flow moved it, or it arrived from a partner portal already flagged, or the agent who escalated it was mid-call and pressed save. In each case the receiving team gets a record they cannot read, and the blank is their one clue about why.
The same thing happens in ServiceNow ITSM with the business service field on an incident. Inbound email actions create incidents without one, assignment rules that depend on it fall through, and the incident lands in a catch-all group. The blank is doing its job. It marks the ticket that needs a human decision. The mistake is to see only the empty cell and miss the work it points at.
Making the field required hides the signal
The standard fix is a validation rule that makes escalation reason required when status changes to Escalated, and the blank rate drops to zero by the next report. What actually happens is that agents pick the first value in the picklist, or the team adds Other so nobody gets blocked, and within a month Other is the most common reason on the board. The field is full and it tells the receiving team less than it did when it was empty.
I reviewed a Service Cloud org where Other accounted for more than half of escalations after a required-field change. The tier two lead had stopped reading the field and was calling the original agent on every case, which took longer than the blanks ever had. The validation rule had turned an honest gap into a confident wrong answer. Honest gaps can be routed. Wrong answers get trusted.
Required fields are right when the person saving the record knows the answer at the moment they save it. The escalating agent usually does know why they are escalating. They do not always know the root category or which contract tier applies, and those are the fields that turn into Other. Make the field required at the transition where the knowledge exists, and leave the rest blank on purpose.
A blank has at least three meanings
Once some blanks are legitimate, you have to say which kind each one is. A blank escalation reason means one of three things. Nobody knows yet. The question does not apply to this case. Or somebody was supposed to answer and has not looked. Those need different handling, and a single empty cell cannot carry the difference.
In Sales Cloud and Service Cloud the cleanest answer I have found is explicit picklist values for the states that are not really answers. Not applicable is a value. Not yet reviewed is a value, set by the flow or the record type whenever a case is created by an integration or from the portal. The remaining blank, the true --None--, now means exactly one thing, which is that a human escalated this case without saying why. That leaves a small population worth working.
ServiceNow choice fields work the same way, and the inbound action or transform map can set a placeholder value on creation so a system-created incident is never confused with a human one. Where I would push back is on adding a separate status field to track the state of every other field. Two or three well-named choices in the field itself are enough. The CRM and service teams that share a customer record need to agree these values once, because the case that opens in Service Cloud often started life as an opportunity and the blank travels with it.
Put the blank where the right person will see it
A blank that only shows up in a monthly quality report will not be fixed by the person who can fix it. The tier two lead needs a list view of escalated cases with no reason, sorted by age, as the first thing on their home page. In ServiceNow the same list belongs on the service desk manager's homepage, filtered to the catch-all assignment group and incidents with no business service. Whoever owns that list works it every morning, and it should be short by ten o'clock.
Ownership is the part that gets skipped. A queue that everyone can see and nobody is assigned to will fill up until it is ignored. I would name the person and give them the authority to bounce a case back to the escalating agent with a one-line question. The argument that queued work needs a business owner applies here in miniature. The blank is a piece of work, and work needs someone whose job it is.
Count blanks by the path they came in on
The quality report that started all this gives a single percentage, and that number is nothing you can act on. Break it out by origin instead. Cases escalated by hand from the console. Cases created by the onboarding flow when an opportunity closes. Cases from the partner portal. Incidents from inbound email. Each path has its own reason for leaving the field blank. If every portal case arrives as Not yet reviewed and stays that way for a week, the portal team owes you a field mapping, and you can show them the count. If the blanks cluster on one agent, that is a coaching conversation, and it can happen with the actual cases open rather than a percentage on a slide.
The same breakdown keeps later analysis honest. A report on escalation reasons that quietly excludes blanks, or lumps them in with Other, will tell leadership that most escalations are about billing when most escalations have no recorded reason at all. Writing down the questions leadership will ask before deciding how to record the answer is the discipline that stops this. If the question is which product line generates the most escalations, then Not applicable and Not yet reviewed have to appear on the chart with their own bars. The data topic hub has more on record states across systems.
What to ask before anyone adds the validation rule
Here is what I say in the meeting when the required-field proposal comes up. Show me the blanks by the path they came in on. Tell me who knows the answer at the moment the record is saved, and whether that is the same person who is saving it. Tell me what the receiving team does today when the field is empty, and how long that takes. If nobody in the room can answer the third question, the validation rule is premature, because we do not yet know what the blank is costing.
Then I ask for the smaller change. Add Not applicable and Not yet reviewed as values. Set the default on integration-created records. Build the list view and name its owner. Run it for a month and bring back the counts by path. Usually the proposal quietly disappears, because the blanks that remain are the ones where a human forgot, and those are few enough to fix with a conversation.
Pull up your escalated cases or your catch-all incident group this week and count the blanks in the one field the receiving team reads first. Then, for each blank, say which of the three states it is in. If you cannot tell from the record, neither can the person who has to work it, and that is the field to start with.
