Your Resolution Says "Approved," But the Customer Still Emails You Three Days Later

A resolution portal that marks a case "approved" has done half the job. The customer sees approval and assumes the money is already theirs, but the actual funds can take three to five business days to land depending on their bank, and that gap is where a second wave of tickets quietly gets created.

This is not a portal failure. It is a communication gap between what "approved" means operationally and what it means to a customer checking their bank balance.

Where the expectation breaks

When a resolution status changes to approved, most portals send a single confirmation message and stop. The customer reads "approved" as "done," closes the tab, and checks their account the next morning expecting to see the funds.

When the money is not there, because payment processors and card networks have their own settlement timelines that have nothing to do with your resolution portal, the customer does not think "this is normal processing time." They think something went wrong, and they email support to ask where their refund is, essentially recreating the exact WISMO pattern the resolution portal was built to prevent, just one step later in the process.

Treat refund settlement like a second tracking event

The fix mirrors how you already handle shipment tracking. Nobody expects a package to teleport the instant it ships, because tracking pages set the expectation with an estimated delivery window. Refund settlement needs the same treatment.

The moment a resolution is approved, tell the customer explicitly: approved today, funds typically visible in your account within three to five business days depending on your bank. Do not just say "approved," say what happens next and roughly when.

Follow that initial message with one more touchpoint around the midpoint of the typical settlement window, a short note confirming the refund is processing normally. This single follow-up, sent proactively, prevents the vast majority of "where is my refund" emails, because it answers the question before the customer feels the need to ask it.

Segment by payment method, because timing genuinely differs

Not all refund methods settle at the same speed, and treating them identically in your communication creates false expectations. Store credit is close to instant and should be communicated that way. Original payment method refunds through major card networks typically take three to five business days. Buy now, pay later refunds can take longer depending on the BNPL provider's own processing cycle, sometimes a full billing cycle.

If your resolution portal sends the same generic timing message regardless of payment method, you are either overpromising for the slower methods or underselling the speed of the faster ones. Pull the actual method-specific settlement window into your messaging logic rather than using one blanket estimate.

What this does to your support volume

The volume of "where is my refund" tickets that arrive in the days after an approval is a measurable, specific category, distinct from the original resolution tickets you are already tracking. Pull it as its own line item, and you will likely find it is a meaningful chunk of remaining post-resolution contact volume, hiding inside what looks like general support noise.

Closing this gap does not require new infrastructure. It requires adding a status stage and a scheduled follow-up message to a workflow that is probably already built to fire status updates at every other stage of the resolution.

Why this matters more during peak periods

Refund settlement times do not shorten during high-volume periods, but customer anxiety about money does tend to spike, particularly around holiday spending when customers are watching their accounts more closely. A generic "approved" message that would generate a handful of follow-up emails in a normal month can generate a disproportionate spike in December if customers are checking balances daily against a tight budget.

Building the settlement-timing message into your resolution flow now means it is already in place before the season where the gap matters most.

The bigger point about resolution communication

Approval is a milestone, not an endpoint, and treating it as the end of the communication sequence is what creates a second round of support contact for a problem that was already solved. Customers do not need faster refunds nearly as much as they need to know what to expect and when, and that expectation-setting is nearly free to build once the underlying resolution workflow already exists.

ShipAid's Self-Service Resolution Portal sends method-specific settlement timing automatically once a resolution is approved, closing the follow-up gap before it becomes a second support ticket. See how ShipAid keeps customers informed from approval through funds landing.