Klaviyo · Case study
Quiet Hours
A send-window control surface that gave Klaviyo customers a defensible answer to the most common deliverability and brand-trust complaint in the platform.
- Role
- Product Designer
- Company
- Klaviyo
- Team
- 1 PM, 4 engineers, 1 PMM
Scope
- Discovery
- Systems design
- Specs
- Shipping
Labels
- Shipped
- Representative reconstruction
Summary
Executive summary
Problem
Senders were getting brand-damage complaints from recipients who received messages in the middle of the night. Customer support absorbed the impact; the platform had no built-in answer.
Approach
Designed a per-flow Quiet Hours control that handles timezones, holidays, and overflow windows without forcing the sender to think in UTC.
Outcome
Shipped in two surfaces — campaigns and flows — with a clear upgrade path to advanced scheduling. Reduced quiet-hours-related support tickets meaningfully in the first month.
Problem
Diagnosis
The complaint pattern was consistent across segments: small senders did not know that their default schedule was sending in the recipient's local night; larger senders knew, but their existing workarounds were fragile.
Support tickets
Quiet-hours-adjacent issues were one of the top three weekly themes for the deliverability team across two quarters.
Account manager interviews
Six of eight AMs cited the lack of a built-in quiet hours control as a friction point in renewal conversations.
Product analytics
Sends between 11pm–6am recipient time correlated with a measurable bump in unsubscribes within 24 hours.
Constraints
What was fixed
Recipient-local timezones, not sender-local
The send time has to be evaluated against the recipient's timezone, not the sender's. This is non-negotiable because senders email globally.
No new top-level navigation
The control had to live inside existing campaign and flow editors, not as a separate Quiet Hours page. Routing changes were off the table for this release.
Backwards compatible defaults
Existing flows must keep their current behavior unchanged when the feature ships. No silent change to send timing for accounts who do not opt in.
Send-engine integration window
The control had to ship within the same release window as a planned send-engine change, or wait another quarter for a second integration slot.
Principles
Design principles
01
Defaults that protect the recipient
When the user does not configure anything, the system should err toward not sending at midnight. The opt-in is for overrides, not for the protective behavior.
02
One concept per control
The window picker controls the window. The timezone resolver runs in the background. We never ask the sender to choose both at once.
03
Reversible by default
Every Quiet Hours choice can be undone in the same place it was set. The control does not hide behind a confirm dialog or persist after deletion.
Exploration
What we tried
We sketched three directions before locking the final pattern: a global account-level setting, a per-flow setting embedded in the schedule step, and a per-campaign override that lives on the send dialog. Each was evaluated against the constraints above.
Direction A — account-wide setting. Simple, but blunt. Could not handle senders with very different audiences across regions. Direction B — per-flow setting on the schedule step. Granular, but added a new sub-step to the flow builder. Direction C — per-campaign override at send time. Familiar, but did not solve the recurring-flow case at all.
Send time
Scheduled
Mon May 26 · 9:00 AM Eastern
Quiet Hours
Pause sends during off-hours
Overflow
Window
Timezone
Read-only · resolved at send
Next eligible send
Tue May 27 · 8:00 AM (local)
Based on current window & overflow setting
- Quiet Hours toggle (off by default)
- Window picker (start and end time)
- Recipient timezone resolver — read-only
- Overflow behavior — hold or send next window
- Preview of next eligible send time
Send time
Mon May 26 · 9:00 AM Eastern
Timezone
Recipient's local time
No send-window control
Decision
How we chose
| Option | Granularity | Engineering cost | Net effect on recipient |
|---|---|---|---|
| Direction A — account-wide | Low | Smallest | Inconsistent across regions |
| Direction B — per-flow + per-campaign | High | Largest | Strongly positive |
| Direction C — per-campaign override | Medium | Small | Partial — recurring flows untouched |
Recommendation
We chose Direction B. It was the highest-cost option, but the only one that covered both recurring flows and one-off campaigns, which together represented over 90% of impacted send volume.
Outcome
What shipped
Quiet Hours shipped in both surfaces in a single release. The team gave deliverability a clean answer for the support tickets they had been absorbing for over a year.
- Quiet-hours support tickets
- -38%
- Adoption (flows)
- 21%
- Unsubscribe rate at 11pm–6am
- -12%
First 30 days after launch.
Eligible flows opted in within 60 days.
Among accounts with Quiet Hours enabled.
The launch was deliberately quiet — no in-product banner, no marketing push. The product worked best when adoption was self-driven, and the support team confirmed the ticket drop within the first sprint after release.
Reflection
Looking back
The hardest part of this project was not the control itself — it was the timezone resolver behind it. If I were doing this again, I would have invested in the resolver UX one release earlier so the eventual control had a stronger foundation to sit on. The control reads as simple because the resolver works; that work should have been visible inside the design phase, not buried as platform infrastructure.
Available
Want to talk about a problem in this shape?
Best fit for platform UX, growth systems, internal tools, and AI-accelerated product execution. I respond to most inbound within a day.