← Field notes
Why I bill per event,
Almost every piece of workforce software I ever used charged the same way: per user, per month. So much per person on the roster, billed every month, forever. And for a lot of businesses that makes total sense. If you've got 40 employees who show up every day, paying per seat per month tracks reality just fine.
Events are not that business. And the per-seat model, dropped onto event work, is quietly hostile to how the work actually happens.
Think about what a festival actually looks like as a staffing curve. For most of the year, the headcount is basically zero. Then, for one weekend, it spikes to 200 people across the grounds, around the clock, and then on Monday it drops back to zero. A wedding might be six guards for one night. A stadium might be a different 80 people every home game, with a roster that churns constantly.
The roster is bursty, temporary, and disposable. The people you onboard for one festival might never work another event for you. So when a tool wants to charge you per user per month, it's asking you to pay an ongoing monthly fee for a workforce that existed for 72 hours and then evaporated.
Per-seat-per-month asks you to keep paying for people who stopped existing on your roster the moment the event ended.
You either pay for seats you're not using eleven months of the year, or you spend your time adding and removing people every single event to avoid the charge, which is its own tax on your attention. Both options are bad. The pricing model is fighting the nature of the work.
So my first instinct was to go the other way, charge by usage. Per agent-hour, say. Three guards for eight hours, you pay for 24 agent-hours, nice and fair. It scales perfectly with the size of the event.
But I talked myself out of it, because metered pricing has its own poison. If every agent-hour costs money, then every time you add a walk-up to the board, or track a setup crew, or put a breaker in the system, a little meter ticks. And the moment a tool makes you hesitate before tracking someone, you've lost, because a board with people deliberately left off it to save money is a board with holes, and a board with holes is worthless. I never want the pricing to make you want less of the thing the product is for.
There's also the bid problem. When you're quoting a client, you need to know your costs up front. A meter that depends on how many hours actually got worked, including all the overtime and churn that makes events chaotic, gives you a variable cost you can't cleanly put on a fixed-price bid. That's a nightmare for an operator trying to price a job.
So I kept the good part of the metered instinct and threw out the meter. Price by the size of the event, as one fixed number you see before the event starts. A small overnight and a multi-week festival are different animals, and the price should know it. So I size the event by its total staffed time, the agent-hours, and use that to land you in a band. But you're billed a flat number for the event, not by the hour.
That does three things at once. It scales with the actual size of the job, so a wedding doesn't subsidize a festival and a festival doesn't pay wedding money. It gives you a fixed number you can drop straight onto your bid. And it never charges you for tracking one more person, so you put everyone on the board, which is the whole point.
The tool should fit the work. Event work is bursty, temporary, and all-hands, so the price is per-event, sized to the event, known before you say yes to the client. That's it. No per-head, no meter, no paying in March for a guard who worked one Saturday in September.
I spent years on the other side of that invoice. This is the pricing I always wished someone would offer me.
One fixed price per event, sized to the event, known before you bid it. See how the pricing works.