We were wrong about per-seat pricing
In April we argued per-seat was the only honest model for scheduling software. We now charge per location. Here is the argument that changed our mind, and the numbers.
In April we published a post arguing that per-seat pricing — one rate per active person on your roster — was the only honest way to charge for scheduling software. We have since changed the model. Weekwright bills per location, and headcount is not a billing input at all.
This post replaces that one. The old argument was not stupid, and it is worth being precise about where it broke, because the mistake is a common one: it optimised for a good proxy of value while ignoring what the shape of a bill does to the customer's behaviour.
The old argument, fairly stated
Each active person on the schedule uses the product — they get shifts, request time off, accept swaps. So a per-person rate tracks consumption closely. Per-location pricing, by contrast, charges the same for a flagship store with 40 staff and a satellite kiosk with 4, which is obviously imprecise.
That reasoning is sound as far as it goes. The problem is that it treats a pricing model purely as a measuring instrument, and a pricing model is not only a measuring instrument. It is also a standing incentive, and a number the buyer has to compare against something else.
Where it broke: a bill that moves with your most volatile input
Hospitality and retail — the businesses this product is for — have high turnover and sharp seasonal swings. A restaurant that goes from 18 to 30 staff for the summer is not getting 65% more value from its scheduling software in July. It is doing the same job, on a bigger roster, for three months.
Under per-seat, the software bill tracks the single most volatile line in the business. Under per-location, it tracks the most stable one. For a category where the manager's core complaint is that nothing is predictable, handing them one more unpredictable number is a strange thing to sell.
And the incentive runs the wrong way in a way we underrated. Per-seat means every hire raises a software bill. Not by much, and never enough on its own to change a hiring decision — but it puts a small tax on the exact behaviour that makes a customer more valuable to us. Any model that makes you hesitate before adding the twelfth part-timer is mispriced, however defensible the arithmetic.
The comparison problem we ignored entirely
This is the part the April post missed completely. Buyers do not evaluate a pricing model in isolation. They open three tabs.
The incumbents in this category — Homebase, 7shifts — price per location. When a prospect with 30 employees across 2 sites compares a per-location competitor against our per-seat number, they have to do a multiplication we control none of. A per-seat price that is genuinely cheaper in total can still lose that comparison, because it is being read against a per-location anchor on the other two tabs.
Pricing in the same unit as the category is not conformity. It is the precondition for the comparison being about the product.
What we charge now
The billing quantity is your location count, synced automatically. Adding staff never changes it.
- Starter — free. One location, up to 20 employees. Unlimited weekly schedules, time-off, swaps and templates.
- Core — $39 per location / month ($32 billed annually). The drafting agent: it writes your week, fills gaps, and takes corrections in plain language.
- Pro — $79 per location / month ($65 annually). Everything in Core, plus per-shift explanations, cross-week fairness, the proactive weekly briefing, and coverage and attendance analytics.
- Business — $99 per location / month ($82 annually), plus a $99/month platform fee. SSO, seven-year audit retention, jurisdiction compliance baseline, priority support.
One deliberate detail: the AI agent is on every paid tier, not reserved for the top one. It costs us roughly $4 per organisation per month to serve — that is a measured number, not an estimate — and it is the only real reason to choose us over a cheaper incumbent. Charging most of our paying customers to not see the thing that makes the product different would be a strange way to run a business.
What per-location gets wrong, since we are being honest
The April post's criticism of per-location pricing was not wrong. It was just not decisive.
A small satellite site does cost the same as a busy flagship, and that is genuinely imprecise. We accept the imprecision, in exchange for a bill you can predict a year out and compare in one step. Precision that makes an invoice harder to forecast is not obviously worth having.
There is one cap worth stating plainly rather than burying: Core and Pro allow up to 75 active employees per location. It is a guard against the pathological case — a single site running 200 staff, which is a factory or a call centre and a different conversation — not a hidden billing lever. The overwhelming majority of sites never approach it. If yours does, talk to us; the answer is a plan, not an overage charge.
The exercise from the old post still works
One thing we would keep. When comparing scheduling tools, ignore the sticker price and project your annual spend under three scenarios:
- More sites, same staffing per site. Per-location scales linearly here — including ours. This is the scenario where per-location is the worse deal, and you should check it.
- Same sites, double the headcount. Per-location is flat; per-seat doubles.
- Seasonal swing. Model your August roster, not your February one. This is the scenario vendors never put in the comparison table.
Run it against us honestly. If you are opening sites faster than you are staffing them, a per-employee competitor may genuinely cost you less, and we would rather you work that out now than at renewal.
Why we left this up
We could have deleted the April post. Leaving a correction in its place seemed better: the reasoning in it is the reasoning a lot of people use to justify per-seat pricing, and watching it fail against a real category is more useful than a pricing page that has always been right.