Skip to content
allanninal.dev/build
Collaborate

Part 3 of 7 · Tip pool splitter series ~5 min read

How the split is computed

The arithmetic is four lines and the rule shapes are where the interest is. Most small businesses use one of four, and two of the four generate almost all of the disputes — not because they are unfair, but because they are hard to check.

Key takeaways

  • Weighted hours and one rate covers most real rules in four lines of arithmetic.
  • Four shapes: equal, hours-only, role-weighted, and points per shift.
  • Two shapes cause arguments: anything with a threshold, and anything discretionary.
  • A rule change takes effect next period and never retroactively.
  • Every published share shows the rate, so any two people can check each other’s.

The arithmetic

for each person:
    weighted[p] = hours[p] * weight[role[p]]

total_weighted = sum(weighted)
rate           = pool / total_weighted

for each person:
    share[p] = round(rate * weighted[p], 2)

remainder = pool - sum(share)          # always a few pence
distribute(remainder)                  # Part 4

That is the whole computation. Publishing rate alongside every share is what makes it checkable: any two people can multiply their own weighted hours by the same published rate and confirm they got the same answer from the same number.

Four rule shapes

Four tip-split rule shapes and the residual categoryA vertical chain of five steps entered by a box labelled The pool, for one period. Step one is Equal shares for everybody who worked, described as simple and rare because it ignores hours entirely. Step two is Hours only with no role weights, common and easy to check, with every weight set to one. Step three is Role weighted across front of house, kitchen and supervisors, the most common and still checkable. Step four is Points per shift rather than hours, which works for fixed shifts and is awkward for split hours. Step five is Everything else, meaning thresholds and discretion. A note says the last box is where disputes come from and it is a rule problem rather than a software one.AWS ACCOUNTThe poolfor one periodEqual shareseverybody who workedSimple, and rareignores hours entirelyshape 1Hours onlyno role weightsCommon, easy to checkweight = 1 for allshape 2Role weightedfront, kitchen, supervisorMost commonand still checkableshape 3Points per shiftnot hours at allWorks for fixed shiftsawkward for split hoursshape 4Everything elsethresholds, discretionThe last box is where disputes come from, and it is a rule problem not a software one.
Fig 1. The four rule shapes and the residual category. All four of the named shapes are one multiplication and one division; the last one is not, and that is why it causes trouble.
  • App integration
  • Machine learning
  • Management
  • Analytics
  • People

Why thresholds cause arguments

A rule like “anybody who worked more than sixteen hours this week gets a full share, otherwise a half share” is easy to state and produces a cliff. Somebody on fifteen and a half hours gets half of what somebody on sixteen and a quarter gets, for half an hour of difference, and that is genuinely hard to accept even when everybody agreed the rule.

The system will apply it faithfully and the publication will make the cliff extremely visible, which is either a feature or the beginning of a conversation about changing the rule. Both are better than the cliff being invisible.

Why discretion cannot be automated

“The supervisor allocates a portion at their discretion” is a legitimate rule in some places and it cannot be computed. The honest handling is to treat the discretionary portion as a separate, smaller pool with its own explicit allocation recorded per person, published alongside the computed split rather than mixed into it.

Mixing them produces a share that cannot be checked, which defeats the purpose of the whole system. Keeping them separate means eleven people can verify the computed portion and see plainly that the other portion was somebody’s judgement.

Rule changes

How a tip split rule change takes effectA horizontal row of five boxes. Rule edited: in the sheet. Effective from: a date that is always in the future. This period: the old rule, unchanged. Next period: the new rule. Both recorded: each on its own period. A note says recomputing a published period under a new rule changes somebody's money after the fact.A RULE CHANGE NEVER APPLIES BACKWARDSRule editedin the sheetEffective froma date, always futureThis periodold rule, unchangedNext periodnew ruleBoth recordedon their own periodsRecomputing a published period under a new rule changes somebody's money after the fact.
Fig 2. How a rule change takes effect. Applying a new rule to a period that has already been published would change money people have already been told about.

Each period stores the rule it was computed under, which is the same discipline as the clause versions in the offer letter generator and the stamped rate in the mileage checker. It costs one field and it means a period from March can still be explained under March’s rule.

Next: the pennies.

All posts