Sentiment-driven priority scoring

Priority scoring produces a number on a ticket and an ordering in a queue view. That is the entire mechanism. It does not assign, does not close, does not promise a response time, and does not tell the customer anything. An agent still opens whatever is in front of them.

Be exact about what reordering costs. Moving one ticket up moves another down. A support org that pushes a distressed message to the top has delayed somebody else's, and that somebody may be waiting on a refund they need this week. Priority is a zero-sum edit to a shared list.

SentiSum and Kustomer sit in the class of tools that can read tone and write a field. They do not decide your priority policy. What counts as urgent at a hotel marketplace is a business judgment about which customers can be kept waiting, and that judgment belongs to named people.

Keep the score off the customer's view and out of the reply. Nobody should be told they were scored calm. The number is an internal ordering aid with a short life, and it should be recomputed rather than remembered.

Three inputs go into this score, and each needs a source you can point at. Sentiment comes from the customer's own messages. Customer tier comes from the account record, not from the tone of the email. Language cues are specific phrases the org has agreed carry stakes: cancel, chargeback, regulator, my flight is tomorrow.

Account data has to be attached before the score runs. If tier, plan, and booking status are missing, the score is being computed from tone alone. Pull that context at intake, using something like CRM, order history, and plan data attached as structured fields, and score only tickets that have it.

Set a ceiling. The score is allowed to move a ticket within its band, and it is not allowed to jump a ticket over a defined class of work. Safety issues, legal notices, and anything a compliance rule already governs sit above the scored band and are ordered by a person.

Set a floor as well, and treat it as the more important half. No ticket may be pushed down indefinitely because it scored low. Define an age at which any ticket rises regardless of score, and make that age visible in the queue view. Without a floor, quiet customers wait forever and nobody notices.

If any of the three inputs is unavailable, return no score rather than a partial one. An unscored ticket sits in arrival order, which is a defensible default.

Tone is the weakest of the three inputs and should carry the smallest weight. People write politely when something is badly wrong. People write furiously about a minor annoyance. A model that reads emotion accurately still cannot read consequence.

Stated stakes deserve the most weight, because the customer has told you what is at risk. A guest whose check-in is tonight has a deadline. A guest asking about a stay in November does not. Deadlines in the text are the cleanest urgency signal a support org gets.

Show the three components separately in the queue view, not just the total. An agent looking at a high score should see that it came from a same-day check-in rather than from anger. A single blended number hides which input fired, and it is the reason agents stop believing the ordering.

Recompute on every customer reply. A ticket that opened calmly and turned urgent should move. A ticket scored high on a first angry message should drop back when the customer confirms the workaround helped. A stale score from Monday ordering a Thursday queue is worse than no score.

Priority and assignment are separate problems. Order tells you what to pick up next. Who picks it up is decided by an optimization over queue depth, shift coverage, and ticket sentiment, and the two should not be collapsed into one rule. Revenue exposure is a third field again, set by flagging revenue-at-risk and VIP accounts.

This scenario is made up. A hotel booking marketplace runs a scored queue with three components and a two-day floor. Two tickets arrive within a few minutes of each other on a Friday afternoon.

The first is from a loyalty-tier member and reads as very angry. The property charged a resort fee that was not shown at booking. The amount is small. The stay ended three weeks ago. Sentiment scores strongly negative, tier is high, and the stakes phrase list finds chargeback in the last line.

The second is polite and short. A family with no loyalty tier writes that the confirmation number does not appear at the property and they arrive at nine tonight. Sentiment reads neutral. Tier is standard. The stakes list finds a same-day check-in and the phrase we are already driving.

With stakes weighted above tone and tier, the second ticket ranks higher. The queue view shows why: same-day arrival, active booking, no room confirmed. The first ticket still ranks well above the day's average, because chargeback language and a high tier both count, and it is a refund dispute rather than a stranded family.

A third ticket that afternoon reports a broken lock on a guest room door. That is a safety class, so it sits above the scored band entirely and a team lead orders it by hand. The score never had a vote on that one.

Sentiment models fail in patterns that are worth naming, because each one has a fix.

Politeness masks severity. Customers who write formally, who are writing in a second language, or who assume complaint is rude will describe a serious failure in flat prose. If tone drives the score, those people wait longest. Weight tone lightly and let the stakes list carry the ticket.

Escalation language becomes a lever. Once customers learn that strong words move the queue, some will use them, and the ones who will not are penalized for good manners. Watch for the same account repeatedly scoring high on tone alone, and cap how much tone can contribute.

Tier weighting turns into a service tier nobody sold. If a paid plan quietly buys a place in line, that is a commercial decision and it needs an owner outside support. Write down what tier is worth in the score, and be able to say it out loud to a customer.

Sarcasm, translated text, and short messages all read badly. Two words and a screenshot give the model almost nothing. Score those tickets low-confidence and leave them in arrival order rather than guessing. Deadline prediction is a separate model, covered by forecasting which tickets are likely to miss their target.

Any agent can pin a ticket to the top of their own queue, and any team lead can reorder the shared queue. Neither action requires approval. Both require a reason code from a short list: customer deadline, safety, legal, known incident, manager request.

Overrides are the primary evidence that the weights are wrong. A reason code appearing many times in a week points at a signal the score does not read. The support ops lead reviews that log weekly and changes the weights, with a date and a note explaining what changed.

Weight changes are not an agent-level setting. One owner edits them, publishes the version, and tells the team. Two managers tuning the same score in opposite directions produces a queue nobody can explain to a customer who asks why they waited.

Run the first month in shadow mode. Compute the score, show it in a side column, and let the team work the queue as they always have. Compare what the score would have promoted against what agents actually picked up. Where the two disagree, the agents are usually reading something the model was never given.