Launching today

Empathy Engine
A human-in-loop support agent that tracks customer signals
14 followers
A human-in-loop support agent that tracks customer signals
14 followers
Empathy Engine is a human-in-the-loop support copilot that tracks communication signals, explains shifts in tone, flags escalation risk, and creates guarded replies with Fireworks AI. Agents can accept, edit, reject, or escalate every suggestion. Built with Supabase, tenant isolation, PII redaction, and Zendesk-ready APIs, it makes customer support more aware—not less human!










The part I would push on is escalation risk from tone. We build on the support side, so this is the thing I get wrong the most.
In e-commerce the anger is usually not about the conversation, it is about the order. Someone is furious because the package is late, and they can stay perfectly polite while about to charge back. The other way too: a lot of people are just blunt by default, short sentences, no please, and a tone model reads that as risk when nothing is wrong.
So tone on its own over-triggers on the blunt customers and under-triggers on the calm one whose problem is actually severe. The thing that predicts escalation for us is order state, not sentiment. Late, refunded and still open, second time asking.
Does the escalation flag see any of that, or only the words in the thread? If it is reading tone without the order behind it, I think it catches the loud tickets and misses the dangerous quiet ones.
@jernej_jan_kocica That is the best observation I've got so far!
You are absolutely right that tone alone can over-flag naturally blunt customers while missing calm customers facing serious problems hence to address this Empathy Engine includes a case-context field so the model can consider information such as the order status, previous contacts, refunds, delays, and the underlying issue alongside the conversation tone for this exact issue.
However, your point suggests we should go further by integrating these operational signals directly and weighting them more heavily when calculating escalation risk!
That's a great idea as it would help distinguish a loud but low-risk ticket from a polite customer who is close to charging back. Thanks for highlighting this as it gives us a very clear direction for improving the product!
How much do you think from your personal experience on how much the tone affects the escalation risk vs experience quality?
@scienceaj Glad it landed. And yeah the case-context field is already most of the way there.
I would not give tone a number for the risk part honestly. I think of them as two separate things. Tone tells you experience quality, how the conversation is going, if the person is getting more annoyed with the agent. For actual escalation it is weak, becuase what makes someone charge back or go public is the order, not how they typed.
So a polite customer sitting on a late refund is calm tone but high risk. A blunt guy whose problem you already fixed sounds angry but there is no real risk left. Different axes.
I could not put a clean percentage on it though. The direction I am sure about, the number no.
@jernej_jan_kocica Ah yes that's a great distinction!
Since the Case Context field is already there, what specific signals would you want it to capture or prioritize? Things like refund status, delivery delay, repeat contacts, unresolved duration, or whether the issue was technically resolved?
I would love to understand what has been most predictive from your experience!
@scienceaj Great question. From our side the ranking is not really what people expect.
The strongest single signal is a repeat contact. Someone coming back a second time means the first answer did not land, and that predicts escalation better than any tone. One catch though, the reopen often comes on a different channel than the first message, email then Instagram, so it only works if you tie identity across channels. Otherwise you undercount the exact tickets that are about to blow up.
Second is money sitting in limbo. Refund requested but not issued, or paid but not shipped. Anger scales with how much of their money is stuck with no answer, not with delivery delay on its own. A delay they were warned about barely escalates, an unacknowledged one does.
I would be careful with "technically resolved" as a positive signal. Resolved in the system but reopened is the highest risk state there is, it reads as done while teh customer is angrier than ever.
If I had to pick one combined trigger it would be money stuck AND the clock running with no human reply. That pair is what actually goes bad.