The Four-Day Week, Two Years On: What the Data Shows

On a Thursday afternoon, a team working a four-day week is not automatically finished. It may be ahead because meetings were shortened and decisions were clearer, or it may be behind because work was compressed into longer days and unanswered messages accumulated. The visible schedule tells only part of the story. The real question is whether the organisation changed the work or merely squeezed it.

Two years of wider discussion have made the four-day week easier to evaluate, but not simple to judge. Trials, employer reports, and employee accounts point in different directions because the arrangements differ. Some reduce hours with no reduction in pay. Some close on one day. Some rotate coverage. Others keep the same hours across fewer days. A label is not a method.

The useful data therefore concerns the operating model: what happened to output, quality, customer access, retention, absence, workload, and managerial effort? A credible review looks at the trade-offs together and asks whose experience is being measured.

Separate the calendar from the experiment

Before starting a trial, define the change precisely. Is the organisation reducing working hours, closing for a common day, introducing staggered coverage, or giving employees more control over their schedules? Each design answers a different business problem. A common day may simplify coordination. Staggered days may protect service. Reduced hours may test whether some work can be removed.

Define the outcome in operational terms. A sales team might track qualified opportunities and response quality. A support team might track resolved cases, reopens, waiting time, and customer feedback. A product team might track completed milestones and defect patterns. The measures should reflect the work, not just the number of tasks completed.

Take a baseline before the change. Note recurring deadlines, seasonal pressure, customer coverage, overtime, absence, and the meetings that consume the most time. Without a baseline, an improvement can be mistaken for normal variation, while a cost can be dismissed as an isolated complaint. A trial should create a fair comparison, even if it cannot create laboratory conditions.

Look for productivity that comes from better work

Shorter schedules can expose waste that was previously hidden by available time. A team may consolidate meetings, clarify who decides, improve handoffs, automate routine administration, or stop producing reports that no one uses. Those changes can improve work whether or not the calendar ultimately stays at four days.

But compression is not the same as productivity. If every day becomes longer, breaks disappear, or people complete essential work in private time, the apparent gain is being borrowed from recovery. Ask employees where work moved, not only whether targets were met. Check messages and task activity outside scheduled hours, but interpret them carefully; visible activity is not a complete measure of contribution.

Quality needs equal attention. A rushed review, a skipped customer conversation, or a postponed maintenance task may not show up in the first reporting cycle. Include rework, errors, complaints, missed learning, and manager intervention. The best design makes good work easier, rather than rewarding people for hiding the strain required to keep up.

A shorter week is a useful question, not a complete answer: what work should continue, what work should change, and what work should stop?

Test fairness and coverage, not just enthusiasm

Employee experience matters, but a popular arrangement can still create an uneven burden. People with caring responsibilities may value an extra day, while frontline staff may find that coverage rules make the benefit harder to access. Part-time employees, new starters, and teams across time zones may experience the schedule differently. Review who receives the benefit, who absorbs the inconvenience, and who has authority to adjust the plan.

Customer access is another practical test. If the business closes on a shared day, publish the change and provide a clear route for urgent matters. If days rotate, maintain a reliable handoff. A schedule that improves internal energy but makes customers wait without explanation may shift the cost outside the team rather than remove it.

Managers should watch for informal exceptions. If senior staff answer messages on the closed day, or if ambitious employees work ahead in silence, the formal policy and lived policy have separated. Ask directly what people believe is expected. Make escalation rules explicit and give managers permission to protect the boundary.

Use a review cycle before making it permanent

Set a trial period long enough to include ordinary work and at least one predictable pressure point. Agree in advance what would count as success, what would require a design change, and what would stop the experiment. Review data regularly rather than waiting for a dramatic end-of-trial verdict.

Do not reduce the decision to one average. Look at teams, roles, and customer segments separately. A four-day arrangement may work well for focused project work and poorly for a service that needs daily continuity. The answer could be different start times, rotating coverage, seasonal schedules, or a shorter week only during quieter periods.

Finally, record the process changes that made the trial work. If the gain depended on better prioritisation or fewer approvals, those improvements should remain even if the schedule changes. The most durable lesson may not be that every organisation should adopt four days. It may be that time is a budget, and leaders should be able to explain where that budget creates value.

The evidence so far supports curiosity rather than certainty. A four-day week can be a strong operating experiment when the work is measured honestly and the burden is visible. It becomes a slogan when the calendar changes but the expectations do not.

Key takeaways

• Define the schedule and business outcome separately.
• Measure quality, workload, coverage, and hidden work.
• Keep the process improvements whatever the final calendar.