As I told the reporter, this seems like a long shot to me but something I would file for future reference. When I talked to him, I tried very hard to come up with a current solution by focusing on the "toolkit" mentality and trying to piece together different components to "simulate" the system. After racking my brain a bit, I concluded it's not possible to automate his ideas, as any workaround I could think of would require worker intervention at some point and also be very complicated.

As I pointed out to him....
In my opinion the framework is there with the number custom fields, mail routing to separate "free" from "paid", and personal workspaces to show the overdue clients. Unfortunately I think we're missing some key building blocks that would better interface the three components so they could talk to each other. There a lot of natural gaps that we can't fill depending on how you envision the workflow, two examples we can't account for.

1) There's no way to "reduce" some kind of counter for each ticket that comes in.

2) Our address fields don't communicate with the ticket fields custom fields. So even if we had an 'address' ticket counter (presumably an incremental number field), you can't adjust that based on mail routing rules. Or determine when the address field is zero, have a mail rule (post) evaluate that it is (< 0) and move any future tickets to the "free" group.

This will probably never happen as core functionality, but the toolkit should be able to take care of it.

For number custom fields I've considered having an operator for increment + decrement. So you'd be able to make a custom field on Organizations or Addresses with the number of tickets they're allowed to make. A Pre-Parser filter could confirm there was an available allotment left before accepting a ticket for delivery. There could be a Scheduled Task to refill the allotment if it was renewed on a monthly/yearly basis (or Billing could do it manually on payment).