The Bradford Factor: Formula, Calculation & When to Use It
Two employees each take ten days of sick leave this year. One takes them as a single two-week illness. The other takes ten separate Mondays. On a raw day count, the two years look identical. Anyone who's run a team knows they don't feel identical. The second pattern means scrambling for cover ten separate times, usually starting with a text message at 7am.
The Bradford factor exists to capture that difference. It's a simple formula from 1980s research associated with the Bradford University School of Management, built on one observation: the operational cost of absence lives in the interruption, not the duration.
The formula
B = S² × D
S is the number of separate absence spells in the period, and D is the total days absent. A "spell" is one continuous absence, however long.
Squaring the spell count is the whole trick. Run our two employees through it:
- One spell of 10 days: 1 × 1 × 10 = 10
- Five spells of 2 days: 5 × 5 × 10 = 250
- Ten spells of 1 day: 10 × 10 × 10 = 1,000
Same ten days off, scores a hundred times apart. The gap is deliberate: squaring makes frequency, the thing that actually disrupts a team, dominate the score.
What counts as a spell?
Convention matters here, so pick one and stay consistent. A spell is an unbroken run of absence, and a weekend inside a sick period doesn't split it in two. Most implementations count only unplanned absence (sickness, emergencies), not booked holiday, parental leave, or anything approved in advance. Scoring someone for taking their approved vacation defeats the purpose: planned absence is the healthy kind, and you had notice to cover it.
Reading the number
You'll find the same threshold bands quoted all over the HR literature. Treat them as folklore rather than science; they come from practice, not peer review.
- Under ~50: background noise. Everyone gets ill sometimes.
- 50–200: a pattern may be forming. Worth being aware of, nothing more.
- 200–500: the range where many organizations would have an informal, human conversation.
- 500+: a serious pattern that needs understanding. Understanding, not punishing.
The honest way to use these bands is relative, not absolute. Watch for a score that's climbing, or one person sitting far outside their team's normal range. A single reading tells you very little on its own.
Where the Bradford factor goes wrong
This metric has a deservedly mixed reputation, and its failure modes are predictable. You can design around them, but only if you take them seriously.
It can't tell a pattern from a person. A high score can mean someone is gaming the sick policy. It can also mean a chronic illness, a disability, a caring responsibility for a sick child, or pregnancy-related absence. The formula produces the identical number in every case. In most European jurisdictions, applying mechanical consequences to absence connected to a disability or pregnancy is a fast route to a discrimination claim, and rightly so. The score must never be an automated trigger for disciplinary action. It's a lens, not a verdict.
It manufactures presenteeism. Once people learn that one more short absence squares their score, they come to work sick. Now you have the original illness, plus everyone they infected, and you've taught the team that your absence policy punishes honesty. Organizations that use Bradford as a stick reliably end up with worse absence data: first because sick people are at their desks, later because those same people burn out.
It ignores why. Ten one-day absences might be a disengaged employee. They might also be a team whose on-call rotation is quietly wrecking everyone's sleep. The Bradford factor will flag the person when the problem was the rota.
How to use it well
Used with judgment, the Bradford factor earns its keep. It surfaces patterns a total-days report hides, early enough to do something kind about them.
Treat it as a conversation-starter. The only correct response to a high score is a private, open question: "I noticed you've had a run of short absences. Is everything OK? Anything we can do?" The answer might be a health situation that needs accommodating, a manager problem, or, occasionally, a policy being gamed. You can't tell which from the number.
Read it alongside context, never instead of it. Absence patterns move with workload, on-call load and morale. A spike in short absences across a whole team is a team-health signal, not five separate performance issues.
Keep the sick policy generous while you measure. This sounds backwards, but it's load-bearing. Absence data is only honest when people aren't rationing their sick days. If staying home with the flu costs someone a scarce balance, they'll come in, and your data becomes a record of who could afford to be ill.
Where SquadBear fits
SquadBear computes the score for you under Insights → Leave reports. Pick a date range and you get each person's spell count, total days and resulting Bradford score, with a CSV export for whoever owns the spreadsheet. It sits next to the two other reports HR and finance actually ask for: the absence summary and the leave-liability snapshot.
That's deliberately where it stops. There are no Bradford alerts and no workflow that fires at a threshold. The product shows the number and leaves the judgment to a human, because that judgment is the whole difference between using this metric and abusing it. For the same reason, sick leave in SquadBear is unlimited by default: with no balance to ration, the pattern you're reading reflects reality.
If your AI assistant is connected, the report is one question away:
"Show me this year's Bradford factors for the team and flag anyone over 200, then pull their absence summary so I have context before I say anything."
Try it on your own data
Start free and you'll have a Bradford report on real data within the first month, or ask the demo to compute it on the sample team right now.
Related reading: burnout tracking without the Big Brother on reading team health without surveilling the people in it, and what is eNPS?, the other number worth watching next to this one.