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.

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?