Blind counts: designing against anchoring at the cash drawer

A blind count asks the cashier to count the drawer and submit the number before the system shows how much cash should be there. I designed it that way for Tigg POS because an expected amount on screen works as an anchor: anchoring research shows that people adjust too little from a number they have just seen, so a visible target invites the cashier to recount until the count agrees, or simply to type the target. Hiding the expected amount until after the count keeps the count independent, at the cost of one extra step and a little less help for the cashier.

This post explains how the blind count works in Tigg's cash sessions, the behavioural reasoning behind it, and what it costs. The full design is in the cash sessions case.

What is a blind count?

At the end of a shift, the cashier closes the session. Closing has two phases:

1. Count. The cashier enters a total, or counts note by note from Rs 1,000 down to Rs 1. Nothing on screen says what the answer "should" be, and there is no note field yet.
2. Review. After Submit Count, the system fetches the expected cash and shows expected, counted, the difference and a plain-language result: balanced, short or excess. If the drawer is not balanced, a note becomes required before the session can close.

The decision was deliberate from the start, not something I added after testing. My goal was simple to state: reduce the bias towards matching the expected amount.

How anchoring affects a cash count

Anchoring is one of the three heuristics Tversky and Kahneman described in their 1974 paper in Science. In their best-known demonstration, people watched a wheel of fortune produce a number between 0 and 100, said whether a quantity was higher or lower than it, and then estimated the quantity. The arbitrary number moved the answers: the median estimates of the percentage of African countries in the United Nations were 25 and 45 for groups given 10 and 65 as starting points. The paper also reports that payoffs for accuracy did not reduce the effect.

Later work suggests this is not only an effect on beginners. In a 1987 study by Northcraft and Neale, both amateurs and professional real estate agents gave property values that moved with the listing price they had been shown. Strack and Mussweiler (1997) explained anchoring as selective accessibility: comparing yourself to a number makes information that agrees with it easier to bring to mind.

A cash count is not an estimate in the same sense. It is supposed to be a measurement. But a count at the end of a long shift involves small judgements: whether to recount a bundle, whether a stack "looks right", whether a Rs 300 gap is worth another five minutes with a queue waiting. Those are the moments where a target on screen can pull. I didn't test this with cashiers. I designed on the assumption that the research applies closely enough, and I think it's the safer assumption for anything that touches money.

Showing the expected amount vs a blind count

Question	Expected amount shown while counting	Blind count
Is the count independent?	No: the target is in view	Yes, at the moment of counting
Can the cashier self-correct?	Yes, by recounting towards the target	Only after submitting, in the review
What happens to a real shortage?	Easy to absorb into a "recount" or a typed target	Shown as a named difference
Note when unbalanced	Easy to skip if the numbers are made to agree	Required when short or over
Steps at close	One	Two: count, then review
Network dependency	Expected amount loaded with the form	A second request after Submit Count

The blind count is not a new idea; the principle of counting before you see the target is simple. What I had to design was how it feels at a POS counter: what the cashier sees in each phase, and what happens when something goes wrong in between.

How to design a blind count

These are the rules I followed, and the ones I would follow again.

Remove the target from the moment of counting

The count phase shows only what the cashier needs to count: the denominations, a live total of their own count, and Submit Count. No expected cash, no difference, no hint in colour.

Name the result in words

After the count, the review says "Short by Rs 300" in words, not only in red. A small difference is easy to miss in a chart or a colour. In the sample session in the case, Rs 300 is under 2% of the drawer, and it still needs an owner and a reason.

Ask for a reason only when something is wrong

The note is optional when the drawer is balanced and required when it is short or over. A note that is always required soon becomes "ok", typed forty times a week. Asking only when the numbers disagree keeps it rare, so it is more likely to get a real answer.

Mussweiler, Strack and Pfeiffer (2000) found that asking people to consider why an anchor might be wrong reduced its effect. The required note is not a debiasing exercise in that sense. But it does the same kind of work after the fact: it asks the cashier to explain the difference, not to make it disappear.

Design the in-between state

Fetching the expected amount is a network request. If it fails, the cashier stays on their count, sees "Couldn't fetch the expected cash. Please try again." and can submit again without losing anything. A blind count that throws away the count on a failed request would teach people to count less carefully.

What a blind count costs, and its honest limit

The costs are real, and I'd rather name them than hide them.

• An extra step at close. Two phases instead of one.
• No self-correction against the target. A cashier who miscounts by a note finds out in the review, not before.
• A second network request at the moment the cashier wants to go home.
• It can feel like distrust. That is my concern, not something I have evidence for. The plain-language result and the optional note when balanced are meant to make the close feel routine rather than suspicious.

And the limit: during an open session, the Cash Drawer card on the session detail shows the running expected cash, because people need to see the drawer build up through the day. A cashier who wants the target can find it. The two-phase close removes the target from the moment of counting; it does not make the whole product blind. If I changed one thing, it would be an optional blind mode for the whole session, chosen by the owner, because some shops would want it and others wouldn't.

What I know and don't know

The blind count shipped with cash sessions in June 2026. The CEO has reported to me that the feature is live and properly used by real shops. Measured outcome: none. I don't know how often drawers close short, or whether notes on short closes say anything useful.

If I could measure one thing, it would be the share of verified sessions that close balanced, short or excess, alongside how many imbalanced closes carry a note longer than a word or two. A blind count that works should produce visible, explained differences, not fewer differences.

For the input rules that sit inside the same flow, read empty is not zero.

References

• Tversky, A., & Kahneman, D. (1974). Judgment under uncertainty: Heuristics and biases. Science, 185(4157), 1124–1131. https://doi.org/10.1126/science.185.4157.1124
• Northcraft, G. B., & Neale, M. A. (1987). Experts, amateurs, and real estate: An anchoring-and-adjustment perspective on property pricing decisions. Organizational Behavior and Human Decision Processes, 39(1), 84–97. https://doi.org/10.1016/0749-5978(87)90046-X
• Strack, F., & Mussweiler, T. (1997). Explaining the enigmatic anchoring effect: Mechanisms of selective accessibility. Journal of Personality and Social Psychology, 73(3), 437–446. https://doi.org/10.1037/0022-3514.73.3.437
• Mussweiler, T., Strack, F., & Pfeiffer, T. (2000). Overcoming the inevitable anchoring effect: Considering the opposite compensates for selective accessibility. Personality and Social Psychology Bulletin, 26(9), 1142–1150. https://doi.org/10.1177/01461672002611010