Most B2B SaaS support teams send their CSAT survey on a single fixed delay — usually 24 hours after solve — because their old helpdesk only offered one configuration field. That single delay is quietly costing you response rate and warping the signal you do collect. The fix isn't a different number. It's four send rules, each tied to channel, ticket length, and the hour the ticket was solved.

Key takeaways

• A fixed 24-hour CSAT delay is a tooling artifact, not a best practice — it averages out four very different conversation types into one mediocre send window.
• Response rate on chat-resolved tickets drops sharply after the first few hours; email tickets behave the opposite way and benefit from a longer pause.
• Long, multi-touch tickets need the survey delayed until after the first business day so the rating reflects the resolution, not the ordeal.
• Tickets solved late in the day should wait until the next business morning — sending overnight tanks open rates and tags your survey as transactional noise.
• Teams that move from one delay to four typically see meaningful response-rate gains while reducing the "angry venting" tail that pulls scores down.

Why the 24-hour rule exists (and why it's wrong for B2B SaaS)

The 24-hour CSAT delay is folklore from the legacy ticketing era. Older helpdesks shipped with one survey trigger — "X hours after status = solved" — so every team picked a number that felt safe. Twenty-four hours became the default because it's long enough that the customer has probably tested the fix, and short enough that they still remember the interaction.

That logic falls apart the moment you look at the four real conversation types a B2B SaaS support team handles in a week:

• A two-minute chat about a billing toggle.
• An async email exchange spanning three business days.
• A complex bug ticket with engineering involvement.
• A how-do-I question solved with a knowledge base link.

These conversations have nothing in common except a status field. Sending the survey at the same offset for all of them is the support-ops equivalent of running one ad creative against four audiences.

Window 1: Chat-resolved tickets — send within two hours

Live chat conversations are short, synchronous, and emotionally fresh. The customer's window of "I remember exactly how that felt" closes fast. If your survey arrives the next morning, you've lost most of the people who would have given you a five-star rating on the spot, and you've over-indexed on the ones still annoyed enough to remember.

For chat-channel tickets, fire the survey within two hours of solve, ideally embedded in the chat widget itself before the visitor closes the tab. The Helptal chat widget supports a one-click thumbs-up/down rating at end-of-chat, which captures the moment before it evaporates. If you fall back to email for chat survey delivery, target the same business day — not the next morning.

Window 2: Email-resolved tickets under three messages — send next business morning

For short email exchanges (two or three messages, one agent, no escalation), the customer needs a beat to confirm the fix worked. But "a beat" is hours, not a full day.

The sweet spot is the next business morning, between 8 and 10 a.m. in the customer's timezone. This window:

• Gives them time to test the fix.
• Catches them while they're triaging their inbox (high open intent).
• Avoids the "survey arrived during dinner" trap.

If the ticket was solved before noon, you can compress this — same-day at 3 p.m. local works for fast resolutions where the customer is clearly still active.

Window 3: Long-running or escalated tickets — wait 48 hours, minimum

This is where fixed-delay programs do the most damage. A ticket that spanned five days, two engineers, and four follow-ups carries emotional residue. If you ask for a rating 24 hours after solve, the customer is still processing the ordeal. They'll rate the experience, not the resolution — and the experience was hard.

Wait 48 hours, sometimes 72, on tickets that hit any of these flags:

• More than five public replies.
• Reassigned across two or more agents.
• Priority bumped to High or Urgent at any point.
• Spanned more than two business days.

The delay gives the fix time to prove itself in production. Customers who would have rated 3/5 in the heat of the moment often rate 5/5 once they've used the fix for two days without incident.

Window 4: Tickets solved after hours — defer to next business morning

If your agent solves a ticket at 7:47 p.m. on a Thursday, do not send the CSAT email at 7:47 p.m. on Friday. You've now sent it as the customer is mentally checking out for the weekend, and it'll sit unread in a 200-email Monday inbox.

The rule: any ticket solved after 5 p.m. in the customer's timezone gets its survey held until 9 a.m. the next business morning, and skips weekends entirely. Friday-evening solves go out Monday morning. This single rule alone tends to recover a meaningful chunk of response rate that fixed-delay programs leak.

The four-window matrix

A fifth implicit rule: never send a CSAT survey if the customer reopened the ticket within 24 hours. That's a different signal — track it as a reopen rate, not a satisfaction score.

How to actually configure this without a custom build

Most teams hear "four rules" and assume it means a developer project. It doesn't. It means your automation engine needs to support conditional delays based on channel, message count, priority history, and time-of-day. Here's the implementation order:

1. Audit your current CSAT send-time distribution. Pull the last 90 days of solved tickets, bucket them by the four profiles above, and check response rate per bucket. You'll almost certainly find one bucket pulling the others down.
2. Build the four trigger rules in your helpdesk's automation system. Each rule matches one profile and queues the CSAT email at the right offset.
3. Suppress the default "send CSAT on solve" automation so the four conditional rules are the only path.
4. Measure for 30 days. Response rate per bucket, mean score per bucket, and total responses collected. Compare to your previous fixed-delay baseline.
5. Tune. The 2-hour, 48-hour, and 9 a.m. thresholds are starting points. Your customer base will have its own rhythm.

How Helptal fits in

Helptal's trigger and automation engine is built around exactly this kind of conditional routing — match on channel, message count, priority history, and time-of-solve, then queue actions like CSAT delivery on the right offset. The chat widget handles in-conversation CSAT capture for chat-resolved tickets, so you're not bouncing those customers to email at all. And the CSAT report breaks down response rate and score by channel and ticket profile, which is what you need to actually run the audit in step one above.

Frequently asked questions

When should I send a CSAT survey after closing a ticket?

It depends on the ticket profile. Chat-resolved tickets should get the survey within two hours, ideally in-widget. Short email tickets do best with a next-business-morning send between 8 and 10 a.m. Long or escalated tickets need 48-72 hours so the fix can prove itself. Tickets solved after 5 p.m. or on weekends should wait until 9 a.m. the next business day.

What's a good CSAT response rate for B2B SaaS support teams?

Response rates vary widely with send timing, audience, and survey length, but most B2B SaaS support teams running fixed 24-hour delays see single-digit to low-double-digit response rates. Teams that move to conditional send times based on channel and ticket length typically see meaningful improvement, with the largest gains coming from in-widget chat CSAT and avoiding overnight sends.

Should I send a CSAT survey on every ticket?

No. Skip tickets that were reopened within 24 hours (the resolution didn't hold — track that as a reopen rate instead), tickets where the customer never replied to the agent's first message, and any ticket your team marked as spam or auto-resolved. Surveying these creates noise that drags down both response rate and score reliability.

How long should a CSAT survey be?

For post-resolution support CSAT, one question — thumbs up or thumbs down — with an optional comment field. Multi-question surveys belong in quarterly NPS programs, not transactional CSAT. The whole point of post-resolution CSAT is capturing a fast emotional read; longer surveys defeat that purpose and cut response rate by roughly half in most measurements.

Does the CSAT survey send time affect the score itself, not just response rate?

Yes, and this is the underrated risk of fixed delays. Sending too early on long tickets captures emotional residue rather than resolution quality, pulling scores down. Sending too late on chat tickets loses the customers who would have rated highly and over-weights the ones still annoyed enough to respond. Send timing changes both who responds and what they say.

This week, pull your last 90 days of CSAT data, bucket it by the four ticket profiles above, and look at response rate per bucket. The bucket with the worst response rate is the one your fixed delay is failing. Pick that one and build a conditional rule for it before touching the others — one rule at a time, measured for 30 days. If you're evaluating tooling that supports this kind of conditional CSAT routing without a custom build, Helptal's free plan includes the trigger engine and CSAT reporting you'd need to run the experiment.