What the Four-Day Week Experiments Show

Four-Day Week in Plain Terms

A four-day week usually means the same weekly hours compressed into fewer days, or a reduced weekly hour target with pay rules set by the trial design. Some programs run 32–36 hours instead of 40, while others keep pay and reduce days by shifting schedules. In the UK, the 2022–2023 wave of trials reported that many participating firms met or exceeded productivity targets, though the exact metric definitions varied by employer. In the US and Europe, interest rose alongside labor shortages and burnout concerns, and many teams also faced customer demand that does not shrink on Fridays.

Most trials use short pilots, often 6–12 months. That time window matters because learning curves and staffing adjustments take weeks. Skip the idea that “one policy fits all.” It rarely survives scheduling reality.

Common examples include rotating coverage for customer support, staggering training days, and moving internal meetings to the remaining days. Some teams also change how work gets requested, which changes the data flow between managers, systems, and frontline staff. A trial can look like a schedule change, but it often becomes a workflow redesign, which complicates cause-and-effect.

Where Results Go Wrong

People often treat trial outcomes as a single number, then generalize across industries. That fails because productivity depends on demand patterns, job type, and how work is handed off. A software team may measure cycle time, while a warehouse measures throughput, and a clinic measures appointment completion. Each metric responds to different bottlenecks, so “productivity” can mean different things.

Skip the assumption that fewer days automatically reduce workload. It can shift workload into the remaining days, which shows up as overtime, sick leave, or higher error rates. In one common workflow pattern, requests arrive across the week, then get batched for the four working days, which can overload planning and review steps. That overload can also raise rework, which looks like “quality stayed the same” until you track defect rates.

Another pain point involves staffing and coverage. If a trial reduces days without changing headcount, managers may cover gaps with temporary staff or extra hours, and the cost moves off the payroll line. If the trial counts only direct labor, the real cost can hide in overtime, agency spend, or delayed customer response. Skip the conclusion that “no one worked Fridays” if the system still needed coverage.

Data flow matters. A four-day schedule changes when approvals happen, when tickets get triaged, and when reports get generated. Those timing shifts can affect downstream teams, like billing, compliance, or procurement. When the handoff cadence changes, the organization may see short-term friction, then stabilize later. If the pilot ends before stabilization, the results can look worse than the eventual steady state.

How to Run a Trial

Pick the right work model

Choose between compressed hours and reduced hours based on the job’s demand curve. Compressed models keep weekly hours similar, so you test scheduling effects more than workload reduction. Reduced-hour models test whether output holds when total time drops, but they require tighter planning and fewer low-priority tasks. In practice, teams often start with compressed hours because it reduces the risk of service gaps.

Set a baseline for 4–8 weeks first. Then compare the same calendar weeks after the change. Skip the idea that “we’ll compare later.” You need consistent measurement windows.

Define productivity with receipts

Write down the productivity metric before the pilot starts, then lock the definition. For customer support, track first-response time, resolution time, and backlog size. For operations, track throughput per shift and defect or rework rates. For knowledge work, track cycle time and completed deliverables, but also track review turnaround because reviews often become the bottleneck.

Use at least 2 metrics, not one. One metric can improve while another quietly worsens, like faster delivery with higher error rates.

Set pay and overtime rules

Decide how pay changes and how overtime gets handled. Many trials keep pay constant for the reduced days, but some reduce hours with pay adjustments, and the comparison becomes less direct. Also define whether overtime counts toward the “four-day” target, because overtime can erase the intended workload reduction.

Track overtime hours weekly. If overtime rises by 10–20%, the trial may not test the policy you think it tests.

Rebuild the workflow cadence

Move meetings, approvals, and handoffs into the remaining days. Teams often reduce meeting count, but the more reliable change is shifting decision points earlier so work does not wait until the next working day. For example, if a design review happens only on Mondays, then request intake must align, or the backlog grows.

Map the handoff chain from request to completion. Then identify the steps that block others. That mapping, frankly, most people skip.

Plan coverage and customer expectations

For roles with external demand, plan coverage for the non-working day. Rotating schedules, on-call rotations, and limited “service windows” can prevent customer delays from turning into churn. If you cannot cover certain tasks, define what changes: fewer appointments, slower response, or different service tiers.

Document the customer-facing policy in writing. Then measure response times and complaint volume during the pilot.

Run a measurement cadence

Use weekly dashboards and a mid-pilot check, not only an end-of-trial report. Many teams discover late that quality issues appear after 6–10 weeks, when the backlog catches up. A mid-pilot review lets you adjust intake rules, staffing, or review capacity.

Collect both quantitative and operational signals. Sick leave days, turnover intent, and backlog age often predict longer-term outcomes.

Decide who the trial is not for

A four-day schedule may not fit roles with strict time-based obligations that cannot shift, like certain compliance deadlines, safety-critical coverage, or regulated reporting windows. It also may not fit teams where work depends on other teams that keep a five-day cadence, unless you coordinate the handoffs. If your organization has a single shared service desk that must run daily, you may need partial coverage rather than a full policy.

Do not run a trial if dependencies cannot change. The bottleneck will move, and you’ll blame the schedule.

Use a realistic pilot scope

Start with one department or one workflow, not the entire company. A smaller scope reduces confounding factors and makes it easier to trace causes when metrics shift. Keep the pilot long enough to observe stabilization, often 3–6 months, because early weeks include setup friction.

Limit the pilot to 1–2 measurable processes. Otherwise, you will not know what changed.

Case Examples

Support team with rotating coverage

A mid-sized customer support group tested a four-day week by rotating coverage so the non-working day differed by person. They kept weekly hours similar and set a strict rule: no new tickets entered the queue after a cutoff time on the last working day. During the pilot, first-response time stayed stable, but resolution time increased slightly for complex cases because triage reviews clustered on fewer days. The team reduced meeting load and moved escalation decisions earlier, which brought resolution time closer to baseline by week 10.

They tracked backlog age in days, not just ticket counts. That detail revealed a hidden shift: fewer tickets arrived, but older tickets lingered when review capacity lagged.

Operations team compressing shift schedules

A logistics operations group compressed shifts into four days while keeping staffing levels constant. Throughput per shift stayed near baseline, yet defect rates rose in the first month due to rushed end-of-day handoffs. The fix involved changing the end-of-shift checklist and adding a short “handoff window” on the last working day. After that, defect rates returned toward baseline, while overtime fell modestly.

They learned that the policy changed timing, not just time. The handoff process, not the calendar, drove the early quality issues.

Checklist for Deciding

Use this checklist before you sign up for a pilot. It keeps the trial from becoming a calendar experiment with no operational controls.

Common Mistakes in Trials

Measuring only output volume

Why it happens: teams track what looks easy, like tickets closed or units shipped. Impact: quality problems and rework can rise while volume stays stable. How to avoid it: pair volume with defect or rework metrics and review turnaround time, then watch for lag effects after week 6.

Ignoring overtime and hidden coverage

Why it happens: overtime gets reported in separate systems, and managers may not connect it to the schedule change. Impact: the organization pays the cost in hours, agency labor, or delayed work elsewhere. How to avoid it: track overtime hours weekly and record any agency or contractor coverage tied to the non-working day.

Letting dependencies stay five-day

Why it happens: one team changes its schedule while upstream or downstream teams keep their cadence. Impact: work waits in queues, and the bottleneck moves, which can look like “the policy failed.” How to avoid it: map dependencies and coordinate at least the handoff steps that determine cycle time.

Choosing a pilot window that ends too early

Why it happens: leadership wants quick answers and short pilots feel safer. Impact: early friction can dominate results, then stabilize later, so the trial conclusion becomes biased. How to avoid it: plan a pilot long enough to observe stabilization, often 3–6 months, and run a mid-pilot adjustment checkpoint.

FAQ

Do four-day week trials always reduce stress?

Not automatically. Some trials report improved wellbeing signals, but stress can shift rather than disappear. If daily workload intensity rises, people may feel more time pressure on the four working days. If coverage gaps create customer frustration, stress can move into support roles. A careful trial tracks sick leave, overtime, and backlog age, not only survey scores. If you only collect one wellbeing measure, you miss the operational causes that drive it.

What productivity metrics show up most often?

Trials often use metrics tied to the work type: cycle time for knowledge work, throughput and defect rates for operations, and response and resolution times for support. Some teams also track backlog size and backlog age because fewer working days can delay triage and reviews. A common failure mode is using only one metric like “tickets closed,” which can hide quality drift. Choose metrics that connect to bottlenecks in your workflow, then keep definitions stable across the baseline and pilot.

How do pay rules affect interpretation?

Pay rules change the meaning of the experiment. If pay stays constant while hours drop, the trial tests whether output holds under reduced time with no direct pay pressure. If pay changes, the trial tests a different incentive structure. Overtime rules also matter: if overtime rises, the organization may still be paying for extra time. For decision support, record pay policy, overtime policy, and any coverage changes so you can interpret outcomes without mixing different interventions.

Who should avoid a full four-day schedule?

Roles with non-shiftable obligations can struggle, especially where legal or safety requirements demand daily coverage. Teams that depend on other teams that remain five-day can also face queue buildup unless handoffs align. If your work requires daily customer-facing service windows, you may need rotating coverage or partial schedule changes rather than a blanket policy. A good screening step maps dependencies and identifies which steps determine cycle time. If those steps cannot move, the trial will likely fail for reasons unrelated to the calendar.

How long should a pilot run?

Short pilots can miss stabilization. Many organizations need weeks to adjust intake, approvals, and handoffs, and quality issues can appear after backlog dynamics change. A practical range often lands around 3–6 months, with a mid-pilot checkpoint to correct obvious problems. If you run only 4–6 weeks, you may capture setup noise rather than steady-state performance. Plan measurement windows that match your work cycle, like monthly reporting or quarterly compliance steps.

Author's Insight

Four-day week experiments often succeed when they treat the schedule as a forcing function for workflow changes. The strongest signals come from operational metrics that reveal bottlenecks, like backlog age and review turnaround, not only from end-of-pilot surveys. The biggest risk is confusing a calendar change with a system change. If you do not map handoffs and dependencies, the policy moves pressure into queues, which then shows up as quality drift or overtime.

Key Takeaways

• Define productivity with metrics tied to your workflow, then track quality and backlog age alongside volume.
• Decide pay and overtime rules up front, and measure overtime weekly so costs do not hide.
• Map dependencies and handoffs; coordinate the steps that determine cycle time.
• Run a pilot long enough to stabilize, then adjust mid-pilot when bottlenecks appear.
• Screen out roles with non-shiftable obligations, or use rotating coverage instead of a blanket policy.