The calculator takes a meeting duration, the number of attendees, and each attendee's salary (annual or hourly). It returns the fully-loaded cost to the business for the time you spend.
For an annual salary, the hourly rate is calculated against the time a person actually works, not the wall-clock hours in a year. The default assumption: a 38-hour week across 46 working weeks per year, after four weeks of annual leave and roughly two weeks of public holidays.
That hourly figure is then multiplied by a 1.30 loading factor, which approximates the on-costs an employer pays on top of salary: superannuation, payroll tax, leave loading, WorkCover, and a share of overheads. Different industries run higher than 1.30 (banks and government often hit 1.45 to 1.50); the calculator uses a conservative median.
For an hourly salary input, the same loading is applied, so the result is the loaded cost regardless of how the input was entered.
Each submission records the meeting duration, the number of attendees, the salary value, and the requester's IP address. No names, no employer, no identifying detail. The stored data drives the aggregate Insights page, nothing else.
/healthz endpoint exposes git SHA, uptime, and the current cost assumptions, useful for monitoring or any external probe
I'm Kip, a data and analytics consultant in financial services. I built this calculator after a particularly long meeting where I tried to work out, in my head, how much we were collectively spending on it. The number was uncomfortable; the calculation belonged in a tool.
The analysis that came out of the data this tool collects is summarised on the analysis page and as a case study at kipjordan.com. Short version: who's in the meeting matters more than how long the meeting runs.
I'm studying a Master of Data Science at RMIT. Reach me on LinkedIn if you want to chat.