David R. MacIver's Blog
A freemium model for scheduling
As a software developer I like proposing algorithmic solutions to social problems.
As someone with an unhealthy addiction to startups, I like business models (actually I’m not sure that follows...).
As a Brit, I obviously fucking love queuing.
As a leftie, I think socialized healthcare is a fundamental human right and I love the NHS to bits.
So when tell you that this is a blog post about a queuing algorithm based business model inspired by a question of socialized healthcare, you can understand how it might be difficult to convey my excitement about this idea without, frankly, being a bit inappropriate.
It also works well with randomized algorithms, a pet love of mine, so there’s that too.
[caption id=“” align=“aligncenter” width=“500”]
For some
added Britishness...[/caption]
A long time ago (well, two years, which in internet years is
basically a generation), I wrote a rather hodgepodge political
manifesto, detailing a bunch of random stuff I thought was a good
idea. In it I included the following section on healthcare:
For other issues, there is a “banding” system: The resources are divided into multiple bands, and you can pay to move up a band. There is no difference in treatment between the bands, but the fact that you had to pay to be in the higher bands means that there’s fewer people in there so the service is less congested and the wait is shorter. The price points on the band are set dynamically based on capacity and demand.
I’ve realised since that this is a terrible implementation, but it’s a
terrible implementation of what I still think is basically a sound idea.
I was thinking about this in the context of all the recent news (or lack
thereof) around the NHS and it occurred to me that I’ve never posted the
updated version of this concept.
Thinking about it further, I realised what I was describing was basically a freemium business model. As such it might be of more general interest than just my pie in the sky political theorising.
The businesses to which this applies are anything where you have a
notion of a “backlog” - things which need to be done for a customer that
you haven’t gotten around to doing yet because you’re busy processing
other customer jobs. Examples where this might be applicable are
e.g.
- RSS readers (fetching your feeds)
- Video transcoding services
- Anything where a request involves a data intensive operation
- Anything where a finite number of human workers are required to service requests
- Use of physical equipment
- Use of facilities - rooms, etc.
An example that came to mind was The Old Reader’s recent OPML import woes: The
influx of Google reader evacuees was too great for their system to
handle so there was an ever growing import queue. Something like this
might have saved them a lot of woe and turned it into a profit
opportunity.
So what’s the big idea? It’s simple.
You serve everyone. People can pay you as much or as little as they want. However, people who pay you more get served sooner.
First, you decide what proportion of your resources (things/people you’re renting, worker processes, etc) you want to dedicate to paying customers. You won’t physically earmark resources for them - rather each resource will spend some of its time with paying and some of them non-paying. If you’re dedicating x% of your resources to paying customers each resource will spend at least x% of their time with paying customers (unless the demand from paying customers is too low, in which case it might be lower. Then you have a problem with your business...). This might be achieved through explicit round robinning (boo) or randomization (woo).
Now. Every job submission goes into two queues. One of these queues is a FIFO queue - requests are processed in the order they are received. The other is queue dedicated to paying customers. This queue is not FIFO. Instead it’s HPFO. What does that mean? It means highest paying first out (i.e. it’s a priority queue keyed off how much you pay. Please don’t actually use that acronym). The more you pay, the sooner you’re popped off the queue. (UPDATE: There’s a better way to do this bit)
When a resource becomes available, it then selects which queue to pop from according to your resource allocation percentages and takes the leader of that queue - if it’s the free queue then it does the oldest job in that queue (even if that person is a paying customer! You get to go in both queues). If it’s the paid queue it takes the highest paying customer who hasn’t been seen yet.
That’s pretty much it. You’re paying to jump the queue.
As a business this has the slightly weird consequence that you’re given an incentive to not provide adequate provisioning - if you under-provision then you get paid more because people are more keen to queue jump. I don’t know whether this is a bug or a feature.
A note on what “highest paying” means. There are at least two obvious
interpretations of it, and I think both are wrong:
- Highest amount paid over all time
- Highest amount paid per month
I think “over all time” is wrong because it makes it almost impossible
for newcomers to get priority, which I think will piss people off.
Conversely I think “highest amount paid per month” is probably wrong for
the opposite reason - there’s no loyalty reward. Also if people can give
you a couple of quid to get onto the paid queue and stay there then I
think that they will, so I think there’s a long tail (sorry) of business
that requiring monthly recurring payments throws away.
Here’s a score that I think might work:
\[ \sum\limits_{p \in \mathrm{Payments}} \frac{\mathrm{size}(p)}{1 +
\lfloor\frac{\mathrm{age}(p)}{30}\rfloor}\]
Basically we do highest amount paid over all time, but we discount old payments. Last month’s payment is worth half this month’s payment, a payment two months ago is worth a third of it, etc. This nicely rewards loyalty: If you’ve been paying \(x\) per month for the last \(n\) months then you’re the equivalent of someone who paid roughly \((1 + \log(n))x\) this month. It’s not an impossible barrier to overcome, but it gives you a nice lasting advantage. It also means that if you e.g. do a one off £5 payment then your payment is always useful but gets gradually less so over time, which might encourage you to drop another one every now and then.
You can also play with this by adding other queues:
- One-off payments: A “I really need this right now” sum of money you do as a one-off payment to bump you onto a special priority queue.
- A lottery queue: This doesn’t really serve any useful business purpose other than as a delighter. “Hey! I know you thought this was going to take a week, but have it now”. It could either encourage people to pay you money (either as a thanks or a “shit it is nice having this soon, isn’t it?”), or it might discourage them by decreasing their perceived expected wait.
- A “this will just take a minute” queue, ordered by how large a job is (this might not make sense for many things, but could make sense for e.g. transcoding or opml import if you ordered by file size).
- An urgency queue. This makes more sense when you’ve got some trusted upstream judge (e.g. a GP in the medical case) who can say “This is a high priority case”
- A new customer queue, so newer customers get priority. This might be important to prevent new customers from getting bored of waiting and taking their business elsewhere.
- An “amount of traffic” queue where customers are prioritized by giving low volume customers first dibs so the high volume ones don’t consume all the resources
There are probably many others, and obviously you don’t have to tell
your customers what the exact queuing mechanism is for the cases where
they’re not paying (you should be explicit about things like the payment
mechanism and the one-off payments).
I’ve never tried this idea in practice, but I find it pretty compelling as a concept. Have you seen anything like it in the wild?
Comments
Nick Knowlson on 2013-04-02 18:38:30:
Fantastic intro (sure hooked me in!) and an interesting idea. It’s simple and straightforward, and it might even work, haha! Thanks for posting this, I’m going to let it simmer in the back of my head and I’ll let you know if I can apply it anywhere.
Eric Kow on 2013-04-02 22:11:07:
For settlement applications, the UK Border Agency have three tiers of service with increasing fees:
* standard: postal application (could be around 6 months to
decide)
* premium: sit in a Public Enquiry Office for a day, 90% of cases
decided within 24 hours
* super premium service (around £7000): they come to you
Not sure if this is the sort of thing you had in mind when it comes to examples. Part of the incentive to splurge on the premium service is that they hold on to your passport whilst deciding your application.
robert on 2013-04-02 22:43:03:
in the wild? Yes, me. I find when I’m working on fixed-price contracts that somehow the polishing phase on the last 5% gets shuffled to the back of my personal queue at the expense of by-the-hour work that needs to be done. I hypothesize it’s the incentive around the remuneration that’s doing the shuffling in my head.
A bugfix for my queuing busines model | David R. MacIver on 2013-04-03 17:06:02:
[...] been thinking about the queuing model of business I posted the other day and I’ve realised it has a bit of a flaw that I’d missed because it’s not really [...]
fell on 2013-04-04 11:12:30:
What happens if everyone pays a minuscule amount except for a small number of unpaying customers? Is it possible they would get better service?
david on 2013-04-04 11:22:12:
No. Paying customers go on both queues and are seen by whichever one picks them up first, so being on the second queue as well can only be an advantage
Best of drmaciver.com | David R. MacIver on 2013-08-26 09:55:49:
[…] A freemium model for scheduling […]