Users might often tell you what they think they want, but what they ask for may not necessarily be the best for them. As a UX designer, one should strive to understand the users' thought process and suggest alternatives that they weren't even aware of.
I believe that in this case you could observe what the users are actually doing once they have the results. Consider this pseudo-code that describes their behaviour when dealing with numeric data:
- find old value
- find new value
- mentally subtract them
if difference > 0
then check manual and find that the next action is XXX
elif difference < 0
then lookup action in manual, it is YYY
if no difference
then do ZZZ
Perhaps it would be better to add another column to the table, call it difference
to display the delta (so they don't have to subtract it in their heads, which could lead to errors). You can also use colour-coding, red for delta < 0
, green for delta > 0
and otherwise gray. Of course, colours depend on the nature of the data.
You can also add another column called "Next action" which will display XXX
or YYY
- so users don't have to look it up (it takes time and is prone to errors).
They might be even happier if you give them a concise history of what happened, using a sparkline:

Now consider textual data:
- find old value
- find new value
- are they the same?
if identical
then do XXX
else
which part of the string changed?
- OR maybe they actually ask in how many places are there changes?
Depending on what the actual question is (you can try and elicit it in a think-aloud test, or by interviewing them), you will choose an approach. A typical one would be a visual diff, like many git
clients do:

This is better than displaying a crossed-out old value, because if the next question is "so what has changed exactly?" they'll have to mentally compare the crossed out and the new string. It is better to give it to them on a plate.