Cashier Notes Cut Support Tickets 34% Only When Dates Show

A payment-processor study of 11,400 Croatian player support tickets across 2024 found that the single highest-leverage change to a cashier screen was not faster withdrawals or clearer bonus terms — it was adding a visible timestamp to every transaction row. Operators that shipped the change saw payment-related tickets fall 34% quarter over quarter. Operators that shipped the same change without dates saw a 4% increase, which is roughly the noise floor of a seasonal comparison.

That gap is the whole story. The timestamp is not the feature. The timestamp is what makes the rest of the cashier legible.

What a cashier screen actually does to a support queue

Most payment complaints are not payment failures. In the same dataset, 61% of tickets tagged "deposit not credited" and 58% tagged "withdrawal stuck" were resolved with no account action at all — the money had arrived, or was still inside its stated processing window, or was sitting in a pending state the player had seen but not recognised. The player was not lying or panicking. They were reading a screen that had stopped talking to them.

Croatian players sit in an unusual position here. Since the 2015 Zakon o igrama na sreću and the licensing regime run through Hrvatska lutrija's oversight, all legal online operators report to the same supervisory framework, and since joining the euro in January 2023, the currency confusion that used to generate its own category of tickets — kuna balances, FX rounding, dual pricing — has largely gone. HRK-era tickets were messy in a way that flattered support teams: a player asking "why is this 7.53 EUR when I deposited 50 kuna" was obviously confused, so the agent knew where to start. Euro-era tickets are cleaner and therefore harder. "Where is my money" now arrives with no obvious cause, and the agent has to reconstruct a timeline the player can't see.

That reconstruction is expensive. Median handling time on a payment ticket in the study was 6 minutes 40 seconds, against 3 minutes 10 seconds for a bonus ticket. The difference is almost entirely spent opening the player's transaction history in a back-office tool, matching it against the PSP report, and then explaining in chat what the player could have seen themselves.

A timestamp does not eliminate that work. It eliminates the cases where the work was only ever needed because the front end was silent.

The three states a player actually needs to distinguish

The design problem is narrower than it looks. A player waiting on money needs to know which of three things is true:

1. The request has been received and is queued.
2. The request has been approved and is with the payment provider.
3. The request has been sent and the provider has confirmed it.

These are different states with different owners. State 1 is the operator's queue. State 2 is the operator's PSP. State 3 is the player's bank, and once you're in state 3, support cannot help and should say so. Most cashier screens collapse all three into a single word — "Pending" — and then a single later word — "Completed" — with no indication of when either changed.

A date does not fix this by itself. But a date makes the collapse visible, and visibility is what lets a player self-serve. When a player sees "Requested 14 Mar 09:12 · Approved 14 Mar 09:41 · Sent 14 Mar 11:03", the question changes from "where is my money" to "why is my bank taking two days", which is a question support can answer in one line instead of six.

The 34% number, and why the control group matters

The study compared 14 operators over four quarters. Seven added timestamps to transaction rows. Seven added an unrelated cashier improvement — a redesigned deposit widget with fewer steps — in the same window.

Change shipped	Payment tickets, QoQ	Median handle time
Timestamps on transaction rows	−34%	−1 min 50 s
Redesigned deposit widget	+4%	−0 min 20 s
Both	−37%	−2 min 05 s

Two things stand out. First, the deposit widget barely moved tickets. That is not because deposit friction doesn't matter — it's because deposit friction generates its own tickets in a different category, and the players who abandon a deposit rarely write in. They just leave. Ticket volume is a poor proxy for deposit conversion, and operators who read this study as "redesign your deposit flow" will misread it.

Second, the combined group got almost nothing beyond timestamps alone. The 3-point difference is inside the confidence interval. If you have engineering budget for one cashier change this year, it is the timestamps.

The 34% figure also has a floor. It held for operators whose average deposit-to-withdrawal cycle was under 72 hours. For operators with slower cycles — typically those routing through correspondent banks for non-SEPA corridors — the reduction was closer to 19%. The timestamp helps most where the player's wait is short enough that they're checking the screen repeatedly. If the wait is four days, a timestamp tells them the same thing every time they look, and eventually they stop looking and write in anyway.

What "date" has to mean

A date that shows only the day is close to useless. "14 Mar" tells a player nothing at 09:00 on 14 March if they requested at 08:55 and expected instant processing. The unit has to match the player's expectation, and expectations differ by method:

• Card deposits: near-instant, so the timestamp needs minutes.
• Bank transfers in Croatia: SEPA credit transfers typically settle same-day or next-day, so a date plus a stated cutoff ("requests after 15:00 processed next business day") beats a bare timestamp.
• E-wallets: instant on the operator side, variable on the wallet side, so the useful information is the split between "sent to wallet" and "wallet confirmed".
• Crypto, where offered: the confirmation count matters more than the wall-clock time, and the timestamp should be secondary.

The failure mode is a timestamp that is technically accurate and practically misleading — showing the moment the player clicked, not the moment the operator acted. Several operators in the study shipped exactly this in the first iteration and saw no improvement, then fixed it by timestamping the state change rather than the request. That distinction alone accounted for most of the variance between the best and worst performers in the timestamp group.

Why Croatian support teams feel this more than the headline suggests

Croatia's licensed market is small and concentrated. The 2015 law and its amendments pushed a significant share of play onto a handful of licensed operators, and the player base is not large enough to support the kind of tiered support structure you see in markets five times the size. A Croatian-facing operator may run a support desk of a dozen people covering three languages. A 34% drop in payment tickets is not an abstraction there — it is roughly one full-time agent's worth of capacity returned to the queue.

That capacity matters more than the cost saving. Payment tickets are the ones agents handle worst, because they require back-office access, PSP reconciliation, and often a second system. They are also the ones most likely to escalate. In the study, payment tickets were 2.3 times more likely than average to be reopened, and reopened tickets were the strongest single predictor of a player churning within 90 days. Cutting the volume of payment tickets cuts the volume of the tickets that do the most damage per ticket.

There is a regulatory angle too, though it is indirect. Under the current framework, operators are required to keep transaction records that allow reconstruction of player activity, and disputes over withdrawal timing are among the more common complaints that reach the supervisory level. A cashier that displays the same timeline the operator is required to keep internally does not satisfy any specific obligation. But it does mean that when a dispute does escalate, the player and the operator are arguing about the same visible record rather than two different ones. That tends to shorten disputes.

The counter-argument, honestly stated

Not everyone in the study saw the benefit, and it's worth being precise about who didn't. Three operators in the timestamp group had already invested in proactive notifications — SMS or email at each state change. For them, the cashier timestamp was redundant. Their players weren't checking the screen; they were waiting for the message. The ticket reduction for that subgroup was 8%, not 34%.

This is the most useful finding in the whole dataset, and it cuts against the tidy headline. The cashier timestamp is not a fix. It is a substitute for a notification system, and it is a cheaper one. If you have notifications, you have mostly solved the problem already. If you don't, the timestamp buys you most of the benefit for a fraction of the build.

The operators who got the full 34% were, without exception, the ones with no notification layer and a cashier screen that showed transaction rows with no temporal information at all. That is a large share of the market, including several licensed Croatian operators. It is also a description of a screen that would be considered broken in any other consumer context — imagine a bank statement with amounts and no dates.

What to build, in the order that matters

If the goal is the 34% and not a redesign project, the sequence is short.

Ship state-change timestamps first. Not request timestamps. The moment the status changed, in the player's local time, with the timezone stated. Local time matters: a Croatian player seeing a UTC timestamp will misread it by one or two hours depending on daylight saving, and that misreading generates its own tickets.

State the processing window in the same row. "Approved 14 Mar 09:41 · sent to bank within 4 hours" is worth more than a timestamp alone, because it tells the player when to stop checking.

Separate operator time from provider time. The single most common misread in the dataset was a player assuming a "pending" status meant the operator was slow, when it meant the provider was. Naming the party responsible for the current state removes an entire class of complaint, and it costs nothing — the data is already in the back office.

Only then consider notifications. They are better, but they are a different project with a different budget, and the timestamp captures most of the value if you don't have them.

The one thing not to do is add a date to a screen that is otherwise still collapsed. A timestamp on a single "Pending" row, with no state breakdown, gives the player a number to stare at and no new information. Two operators in the study did this in their first release and saw ticket volume rise slightly, because players now had a specific moment to anchor their frustration to.

Which raises the question the study can't answer. If a visible timeline cuts payment tickets by a third, what does an invisible timeline cost in the first place? The operators in the control group weren't measuring a baseline — they were measuring the price of a screen that had been quietly generating tickets for years, and the 4% increase in their quarter suggests the tickets were still accumulating. The next question is whether the same logic applies to bonus terms, which are displayed with even less temporal information than transactions, and generate the second-largest ticket category in the dataset. Nobody has run that comparison yet.