Following up on #64, here would be the practical implementation I had in mind:
Imagine the following scenario:
You receive yet another GitHub issue (email) with a support request in disguise - but having read them so often before, it is clear to you by now. Instead of responding - or worse - letting it sit in your inbox, constantly nagging in the back of your head, you hit reply (directly from your email client) with a short "@HaasBot +support". You can mute that email conversation, because what happens next is known to you:
The HaaS Service Bot received your message, it informs the author that the ticket has been marked a support-request (rather than an actual bug) and that it has been imported as a draft into the HaaS-Support-Ticket platform for their convenience, giving the link to be able to follow up on it. The message also states, that the expected response time for ticket will 7-10 workdays (which it calculated from a per-project-configured minimum default and how long it historically actually takes). The author is asked move the conversation over there. Further more it will state that they can upgrade their support-subscription to a higher plan, would they want a quicker answer. The bot marks the ticket with the "support" label and closes it.
When the author of the ticket now clicks that link, they will find their previous report on the HaaS support platform (imported tickets, but public by default, unless configured differently by the project) saved as a draft, asking them to confirm the import went fine. It also shows what queue-position number that ticket will have. The queue is a simple priority system each project can configure, which defines a strict order in which support tickets are to be answered by the support team. By default this system prioritises higher-pay, then by time of last (non support team member) reaction, but it makes sure that also a configured amount (by default at least 20%) of non-paid-tickets will be processed. The author is informed about this and with the press of a button can "upgrade" the ticket, if they are willing to pay for it.
For that - but also to follow updates - the author has to sign in into the platform - or sign up if they haven't before. After doing so, when coming back to the support ticket page, they are informed that they do currently not have any support contract with the team and are given the option to upgrade. If they choose to, they are first asked whether they are doing this in a professional context, personal or as part of another FLOSS project - many projects offer discount or higher priority to other noncommercial FLOSS project. Would they choose that option, they'd have to go through the same project-authentication-process to proof their participation in the other projects as the project they are currently looking at had to, too: tgis includes the giving access to their GitHub (later Bitbucket and others) account and stating the organisation or repo as well as further information like project website and optional CoC and Support Guidelines.
Should they choose the private or commercial option, they are left to pick out of a few preconfigured supports packages that team offers. Per default, it comes with a pay-as-you-go-plan, which doesn't require any monthly subscription, but instead allows you to pay on a per-item bases. Of course the prices are much higher than for the other packages, but it offers an easy and quick way in and buy support for your ticket by bumping its queue-position. The other packages also offer higher rewards and guarantees - the next higher includes a bunch of ticket upgrades per month and any further for a lower price, as well as having the option too book "consulting hours" with team members, but it also comes with a monthly subscription that has to be paid no matter what. The third - enterprise - plan even offers guaranteed response times of a few weekdays (configured by the team), but comes with a significantly higher monthly fee and can only be booked in 6months intervals.
Unless they choose the pay-as-you-go-plan the author has to provide payment details through stripe now. They are allowed to increase their monthly subscription price - but can't lower it below the minimum required. They will receive a fully tax-expensible invoice from the platform for the entire it. All people that ask for support of a project will on their first encouter with it have to go through that process and also confirm they read this teams and the global terms of conditions and Code of Conduct. The platforms states in their CoC that it will not allow rude or inappropriate behaviour and if alerted so by a project, will ban that support-requester from that project or even the entire platform without refund.
Prior to this authentication, the support-ticket was held in draft-mode and the team hasn't been alerted about the request yet. Only once the person went through these steps, they can update the ticket (maybe adding info the teams support guidelines stated - like version numbers) and submit it. The ticket is now moved into the "support inbox", a ticket inbox the whole team shares of unassigned support requests, ordered by the configured queue. The project supporters can also ask to receive emails about new issues. By default each supporter will only receive one email per workday (they can configure, which time of they they'd like to receive it) giving the latest updates on their tickets (if there have been any), new assignment (normally tickets are self-assigment-only, but sometimes people have to transfer things), mentions in other tickets and finally the current (top 10) queue. Especially if the first two are low volume, they can quickly check the queued ticket and pick up any - preferably in the current order (if they can).
On every ticket each support team member can decide to be notified more (every message per email) or less (up to mute, even with mentions). By default only the digest is emailed. The system provides a unique emails address per ticket only the support-team and the reporter can send to for quick responses. Tickets also automatically close in a configured time frame (30days per default) after the last interaction or can be closed or assigned by the support team member manually. The support team member is also assisted in responding by providing some personal as well as project-wide response-templates.
The platform does not enforce any particular support management model - whether the project decides to use a pick-freely or a one-person-delegates approach is totally up to them. The platform however requires access to some legal entity (person, foundation or company) representing the project. This entity is responsible for proper taxation as well as fulfillment of the contract as the prior stated packages are a direct contract between that entity and the support author. The platform only acts as an enabler, management framework and payment processor for which it takes a transaction fee of 5%. In a later stage, the platform will also allow each project to use their own stripe credentials and connect their own invoicing solution (including bills directly issued by them).