Klaviyo · Case study
Quiet Hours for Flows
An account-wide send-window control that helped Klaviyo customers protect recipient trust without asking every flow owner to manage timezones.
Primary: the quiet-hours window protects recipients by default. Advanced: timezone resolution and state-level enforcement are optional personalization — collapsed until a sender needs them.
- Role
- Product Designer
- Company
- Klaviyo
- Team
- 1 product designer, 1 content designer, 1 lead designer (advisor), 1 product manager, engineers
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 an account-level Quiet Hours control inside Sender preferences — a single account-wide setting for flows that resolves timezone either by phone area code (US/Canada) or by the recipient's eastern-most country time zone.
Outcome
Shipped on the Flows surface inside Sender preferences. Reduced quiet-hours-related support tickets meaningfully in the first month, and gave deliverability and AMs a defensible answer for the most common complaint pattern.
Guided Flow
Configure the account-wide send window
A representative prototype of the core interaction: set the quiet-hours policy, make timezone resolution legible, and show what happens when a flow would send overnight.
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 timezone, not sender timezone
Send time has to be evaluated against the recipient's timezone, not the sender's. True recipient-local resolution was not available — we only had phone area code or country-level signals to work with, so the control had to make that limit visible without hiding it behind precision the system did not have.
Account-level surface, not per-flow
The control had to live in Sender preferences as an account-wide setting for flows. Per-flow configuration was rejected — account managers were asking for a fleet-wide policy, not a switch on every flow.
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
Concept exploration
We sketched three directions before locking the final pattern: an account-level setting inside Sender preferences, a per-flow control embedded in the flow builder, and a per-campaign override at send time. Each tile is the same frame size and includes two out-of-scope ideas that could extend how companies manage quiet hours beyond the shipped scope.
Direction 01
Direction A — account-level setting in Sender preferences. Advanced settings collapse by default; expand to review state-level rules. This direction moved forward and was iterated into the dev-ready spec below. Direction 02
Direction B — per-flow setting on the schedule step. Granular, but added a per-flow decision that AMs and senders did not want to make individually. Direction 03
Direction C — per-campaign override at send time. Familiar, but did not solve the recurring-flow case at all — and flows were the surface the data pointed at first.
Specification
Development-ready concept
Direction A moved forward into specification — not as a static sketch, but as the full Sender preferences card engineering estimated against. The figure below is the version we handed to development: area-code mode with state-level enforcement expanded, inline regulator reference, and international pickers scoped to non-US countries.
- Mode chooser — area code vs eastern time zone
- State-level enforcement — opts US recipients into the regulator table
- Regulator reference — surfaces US state laws inline, not behind a link
- International fallback — visible reasoning, not hidden behind precision we lack
- Scope retitled — pickers govern non-US countries, not US recipients
- Save discipline — disabled until dirty
Decision
What moved forward
| Option | Granularity | Engineering cost | Net effect on recipient |
|---|---|---|---|
| Direction A — account-level (Sender preferences) | Low (single setting) | Smallest to start — iteration added state table + advanced collapse | Strongly positive — covers all flows |
| Direction B — per-flow | High (per-flow decision) | Largest | Variable — depends on each flow's config |
| Direction C — per-campaign override | Medium | Small | Partial — flows untouched, wrong surface |
Direction A, then iteration
Direction A moved forward — not as a one-shot pick, but as the account-level foundation we kept refining. Engineering cost stayed the smallest entry point, and customer-facing teams already wanted a fleet-wide policy AMs could point at. The iteration work — collapsing advanced settings, surfacing state-level quiet hours inline, and retitling international pickers — happened on top of that direction before we handed the concept to development.
Outcome
What shipped
Quiet Hours for Flows shipped inside Sender preferences in a single release. The team gave deliverability and AMs a clean answer for the support tickets they had been absorbing for over a year.
The launch was deliberately quiet — no in-product banner, no marketing push. Support confirmed a meaningful drop in quiet-hours-adjacent tickets within the first sprint after release. Early adoption skewed toward established senders, which was the right pattern: the customers most familiar with their own deliverability metrics opted in first, and AMs gained a single setting to point at in renewal conversations instead of negotiating workarounds per account. Exact figures are held back here because this case study is a reconstruction — the system worked, the support trend was real, but I do not want to publish numbers I cannot pull from the original instrumentation.
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.
Recorded walkthrough
Available
Want to talk about a problem in this shape?
Best fit for platform UX, growth systems, internal tools, and teams that need a senior IC who can shape the problem and ship the details. I respond to most inbound within a day.