Craig Stanley
Home / Decisions / Decision theory at work

Expected value on one page

A plain explanation of expected value with a worked example from the service desk, and the two places it misleads.

10 October 2026 · 2 min read · Craig Stanley
In short, explained

If something might go well or badly, think about how good each result is and how likely it is. Then pick the choice that comes out best on average.

Expected value means multiplying each possible result by its chance of happening, then adding them up. It lets you compare choices fairly when you can't be sure how they'll turn out.

Expected value is the probability-weighted sum of outcomes. Use it to compare options under uncertainty, then check two things it hides: the spread of outcomes (risk of ruin) and the quality of the probability estimates.

The idea

You can't know how a choice will turn out. You can estimate how likely each outcome is and what each would be worth. Multiply each value by its probability, add them up, and you have the expected value. Do that for every option and compare.

A worked example

A service desk is deciding whether to let a model auto-close password reset tickets. The numbers below are illustrative.

OutcomeProbabilityValue per ticket
Closed correctly0.95+£4 (agent time saved)
Closed wrongly, user reopens0.05−£12 (extra handling and annoyance)

Expected value per ticket = (0.95 × £4) + (0.05 × −£12) = £3.80 − £0.60 = £3.20.

At 2,000 tickets a month, that's about £6,400 a month in favour of auto-closing, if the estimates hold.

Where it misleads

It hides the spread. Two options can have the same expected value while one occasionally produces a disaster. If one wrong decision could cause a data breach or a safety incident, expected value alone isn't enough. Set a hard limit on the worst case and only compare options that stay inside it.

It's only as good as the probabilities. "0.95" above is a guess until you've measured it. Run a small trial, count the results, and update. The page on calibration covers how to check your estimates.

Using it at work

You rarely need precise numbers. Rough estimates, written down, beat a debate where nobody states what they believe. The value of the exercise is that everyone can see the assumptions and argue about the right ones.

Read next

A question to take awayWhich repeated decision would you trust a cheap model to score first, with a person checking the close calls?

About me

Craig Stanley

Microsoft AI consultant and technical architect, based in Whitley Bay. Over the last few years I've delivered Microsoft 365 Copilot, Copilot Studio agents, Azure AI Foundry work and governance for UK public sector and financial services organisations.

What interests me is the decision underneath the tool: what it costs, what it risks, and whether a small, transparent model can make it better. I write the methods up here and on Substack so anyone can use them.

Find me