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.

Best cup of tea ever by alittlething, on Flickr

For some added Britishness…

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?

This entry was posted in rambling nonsense, Work, World domination on by .

7 thoughts on “A freemium model for scheduling

  1. Nick Knowlson

    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.

  2. Eric Kow

    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.

  3. robert

    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.

  4. Pingback: A bugfix for my queuing busines model | David R. MacIver

  5. fell

    What happens if everyone pays a minuscule amount except for a small number of unpaying customers? Is it possible they would get better service?

    1. david Post author

      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

  6. Pingback: Best of drmaciver.com | David R. MacIver

Comments are closed.