Skip to content
This repository has been archived by the owner on Apr 20, 2022. It is now read-only.

help/support as a service -haas #66

Open
gnunicorn opened this issue Dec 22, 2015 · 4 comments
Open

help/support as a service -haas #66

gnunicorn opened this issue Dec 22, 2015 · 4 comments

Comments

@gnunicorn
Copy link

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).

@ghost
Copy link

ghost commented Dec 23, 2015

Bad idea. People are lazy

@freakboy3742
Copy link
Member

This is an interesting idea - it nicely joins the "Just make it easy to pay for something" concept with the "importance is directly related to cost" idea.

Some random thoughts:

Triage

Triage will rapidly become the bottleneck. In order for this system to work, people need to know very quickly whether their issue is actually a question, and so on. If you end up spending all your time triaging tickets, you're not going to get much actual work done.

Workflow

At a DjangoCon US a couple of years ago, one of the keynote speakers (unfortunately, I can't recall who it was) made a pitch about improving the customer experience on open source projects. One of the comments he made is that if a user's first interaction with your project is being told "Your message was posted in the wrong place", you've just failed as a project, because the user is left feeling like an idiot. The suggested remedy was to reconsider how you handle communications - to have a single point of entry for all communications - tickets, queries, security reports, support questions - and use the triage process to filter conversations into different buckets.

This also addresses the age-old question about tickets tied to multiple questions, questions tied to multiple tickets, user questions posted to the developer mailing list, security issues posted publicly, issues that span multiple subprojects, and so on.

In that vein, this could be the vehicle to tie this together - make the system the "single point of contact" for all project communication, and use the tagging/flagging/triage system to incorporate the "paid" aspects of the plan.

Selling Support

"Selling support contracts" in itself isn't a new idea. This approach definitely smooths the sales path, which is a good thing, but some of the other problems still exist. Namely:

Distraction from core goals

If some (or all) of your revenue comes from solving problems for customer (i.e., consulting). it's easy to get distracted and end up spending all your time solving problems for money, and no time developing/improving the underlying product.

Undermining your proposition

The ideal software project has perfect documentation, and is trivial to use. If you achieve this goal, you have just undermined the market for support, because your software needs no support. This is, of course, the extreme case - no software is every perfect - but it's easy to think of a situation where you might spend 2 days writing a really good tutorial or troubleshooting fact sheet for a complex set of common situations - and thereby destroy the income stream for fixing that problem.

Scale

If you have an established, high profile project, it's easy to contemplate generating enough revenue through support. However, if you're a smaller project, your development and maintenance overhead is not necessarily any less, but the idea of selling enough support to pay a full time salary (which, for me is the end goal) is a problem.

Creating an economy

I don't know if you've contemplated this, but one possibility here is to treat the "tasks" that have to be performed (like triage) as an expense in the system - and whoever does them gets paid. There's an obvious need here to qualify applicants - triage is so important to this process that you can't afford get it wrong - but assuming that issue could be resolved by peer review or a qualification process, this could be a source. It's essentially the bug bounty approach, but for everything that is needed to keep a system moving. Of course, it's subject to the same problems as the bug bounty approach as well - the larger the task (e.g., answering a question) the harder it is to determine who gets paid, and what proportion of available funds.

@nolanlawson
Copy link

Great discussion! I think the idea of being able to type @haasBot +support or equivalent is nice, because it gives me (as a FLOSS maintainer) a way to say "your request has been acknowledged, but I don't have time to look into it right now. We'll get to you later." That's one of the biggest psychological burdens for me: feeling like I'm letting people down when I don't respond immediately.

The rest of this plan seems nice, although I admit it sorta feels like we're trying to solve problems created by Github's bare-bones Issues UI. Basically there's very little way to triage or sort issues, and this plan would just create an alternate UI to dump the "ticket" issues. I'm not sure the new UI would be any better than the old UI, or if it would just give me one more inbox to check.

Another issue is that I find distinguishing "tech support request" issues from actual bugs is often not easy. People often post long, verbose issues (sometimes generously peppered with 100-line snippets of code or logs), so even the act of just reading them drains valuable time from the project.

Also, the difference between a support request and a bug is (as you pointed out), not clear-cut. Sometimes an issue seems like a bug, then you discuss it a bit more and realize it's just a misunderstanding. Or vice-versa. Or it is a bug, but maybe it's such an edge case that it doesn't feel worth fixing. Or it's not quite a bug, and there's a workaround, but the user isn't satisfied with the workaround. All of these things make triage difficult, and also make it difficult to determine payment for a support request. (If the user pays, and the resolution is "wontfix," were they robbed?)

Anyway, these are just some thoughts. I've seen bug bounty programs and other efforts to fund this stuff, and I encourage you to try to find a better way, but I think it will be very very hard. :)

@gnunicorn
Copy link
Author

Thanks for all the great input @freakboy3742, @nolanlawson !

As a side note, much of what I am thinking of is inspired by my work and thoughts on discourse (which in turn took a lot of the teams learnings from Stack Overflow) and the specific implementation work on Germanys 2nd biggest general Question-Answer-Forum, wer-weiss-was.de over the past two years. Just to give some context about me.

There are three main aspects you brought up and I'd like to discuss further:

  • Platform vs. Github Tickets
  • The support you are selling
    • Undermining your own business
  • The bug economy / triaging

Platform vs. Github Tickets

As mentioned I come from the background of OpenSource Forums – namely Discourse, which does all its bug tracking through the forum itself. I always found it quite clunky, but having no public github issues meant everything is treated as a support-request on the forum first and only later might be confirmed an actual bug in their software. That worked just great, also because it often meant the core team didn't even have to deal with the issue, but the community was (even for their paid customers). I'd encourage any slightly bigger OS project do something similar (though I'd recommend Flarum nowadays), but the administration burden for volunteer-only organization is quite high – believe me, I am running it for the OpenTechSchool.

When I am thinking of HaaS, similarly to what @freakboy3742 said, I am thinking of it as the primary external communication channel of the project (with all the tools like flagging, spamming, blocking you need to have on any open platform to stay sane). While I make the case here of importing Github Issues (primarily because you can't restrict the creation of Issues on Github to team members only), this probably should have bots for twitter and Stack Overflow, too. Everything first reported would end up in HaaS and the wider team of the project (not only its core engineers) would/could take a look at the request. IF (and that is a big IF) it then turns out to be an actual bug, the platform would allow to create a bug report in the github issue tracker with just a click. As this has already been through lengthy support communication, the bug should be very well defined by this point and allow people to jump on it/discuss the technical way of solving it on github.

In this scenario github issues would be working more like the things they are intended: as an internal project management tools (I'd still recommend using waffle.io on top of it!), while HaaS would be the first entry customer service center. But other than big corp, this would be populated with engineers and actual product developers as wel as long-term-users. As such it wouldn't be "just another inbox", as it would lower the burden on the github issues inbox (which has a terrible notification scheme) and distribute the general support and the clarification to the broader people involved in the team. Many problems would be solved long before there was any github issue to start with. I am also pondering on how to manage feature requests with this – but I call that a second step.

The Support you are selling

@freakboy3742 : If some (or all) of your revenue comes from solving problems for customer (i.e., consulting). it's easy to get distracted and end up spending all your time solving problems for money...

and

@nolanlawson: All of these things make triage difficult, and also make it difficult to determine payment for a support request. (If the user pays, and the resolution is "wontfix," were they robbed?)

I think there as been a little of confusion on the support being sold. I don't know why, but whenever I talk to engineers about support they seem to believe it is about "guaranteed problem solving" (even worse than promising your manager something is talking to the customer ;) ). But that is not how support contracts are usually structured, and where I feel the bigger discussion about financing Open Source (also outside this tracker) is misguided: we focuses too much on the "problem solving achievables" – BugBounties, Crowdfunding for Features, etc.

Support contracts almost never promise a solution to the problem reported. The only thing they guarantee are response times. Whether you as the project do want to fix (or "wontfix") a bug, as well as when and how you do that, is all up to you and never part of support contracts (though there are some critical-bug-contracts, too, but that ain't what we are focusing on here – they are highly paid!). Of course if that is an important customer you might want to please them to keep them (whether you do that is you choice) – however paying for monthly support doesn't guarantee free bug fixes. Neither does bumping a ticket, as I described them earlier.

What the customer is buying is attention or the guarantee of attention. Companies spend big bucks for the possibility of their employees being able to get someone from the database consultants to take a look at their problem within 48h – even if it just to tell them to switch a certain configuration variable to a different state and they even if they only call it once in 12 months. This later thing is exactly what the teams would be selling through HaaS: insurances to companies that they get answers when they panic.

Thus, if you are spending all your time on support (NOT solving problems for money!), it means you might want to a) hire someone to do that for you – you should have the money, as you seem quite popular, b) improve your docs to lower the amount of work or c) change your pricing structure (and/or drop some customers) if you aren't able to do a or b with it.

Note: While I feel strongly about adding an additional per-project-consultancy-marketplace-system on top (I'll bring this up in another github issue), I only consider that an add-on and would want to focus on the general support part for now.

Undermining your own business

Customer-Satisfaction is something very few (do any?) Open Source projects keep track of, however through a support system (and payment model) like HaaS you wouldn't only get a grip on that, you could even optimize for it. The beauty of this is, that while you optimize the configuration documentation to help more people (and have fewer general support requests about it), you aren't ever able to remove the insurance the company needs – as those are hypothetical and unknown. Though you might be able preventing future disasters from happening, this is only reducing your work (as it won't be reported) but doesn't remove the the potential need for assistance later.

Another thought on optimizing away your business is, that – I believe – through that improved documentation (or whatever you are doing), you are also lower the entry/advancing threshold, thus allowing the customer base to grow: who said that documentation is a zero-sum game? Haven't so many software companies proven the opposite when they made more documentation available as this allowed them to grow their customers base?

Triage and the bug economy

I briefly touched how triaging already works quite well for discourse. This of course stems from the fact that their entire team is remotely and through that covers all time zones, but also their specific audience of forum-owners is a highly supportive and chatty bunch. However, I believe around every slightly more popular project, there are plenty of people, who can help but aren't necessarily in the list of contributors currently informed about every bug report. Some projects solve this by pushing this communication to StackOverflow and though that platform has a great overall gamification system, I think it has a fundamental flaw as the points and recognition are solely for boosting once overall ego. What if, instead, when you helped people on a specific project, you would gain recognition from that project and the people around that – and even better: through your support, the project is able to attract money to continue its development? "Thank you for the support. Your work just made $50 for the Project!"

This goes into the problematic part of unpaid labor again, which we should be really careful about. But I like the idea of allowing a community to grow into a support group around your project and I want to give projects the tools to realize and recognize this before it burns people out. Like a proper support-tracker, this would have dashboards telling you, who closed most tickets and alike, making the project team aware of its supporters and their contributions outside of pure code. And become able to recognize them (by either sending some of that money their way or sending them swag and stuff to thank them – this is optional for the project, but will be assisted by the system). I think if you gave people the option of "volunteering 5h/week in support" for the project XYZ, there might be many more people willing to commit to that than their projects are aware of. And committing and helping a project through your work is a great way to feel part of it, too, but it isn't really easy to pull off at the moment.

Economy and Marketplace

With the model of primarily subscription-based income, pay-per-ticket becomes a problematic metric though. Not only because there might only be 5 (paid for) tickets one months, while there are 20 for the same revenue the month after, but also because not all tickets are equally challenging and just closing it quickly is just a wrong incentive – with and without money. At the current point we don't have any idea how to properly govern the spending of the money, as we have very few examples. But I think for many projects, through growing interest being able to pay some key developers and a lead-support-person (taking all tickets no one else is able to take care of) would help them a lot and is in general an accepted measure. I personally also like the idea of being able to distribute any further revenue among other supporting people equally/easily, but the platforms shouldn't enforce how projects spend their money (I will come back to that in a different ticket).

But yes, as soon as a lot of money is in play, the BDFL-style of governing will be highly questioned and other measure will be needed. This, though vital to get right, is something out of the scope of this discussion here, I'd say.


Prompting for costs as a cultural shift

One aspect I want to bring up and further discuss is the cultural shift I am hoping to push with this: By being prompted about the payments early on in the support request process, I am hoping that people are becoming more aware that they are creating costs (for someone, somewhere). Even if they are willing to help for free, as @nolanlawson said, especially lengthy reports (though normally encouraged) might simply mean a lot of cognitive load and work for someone (where I also feel, the job of one gate-keeper, who assigns tickets might be money better spend than having all core developer receive an email). These costs are something totally overlooked or ignored by many and I feel by just prompting this, we might be able to make that clearer. A cost, that way to often leads to burn out and eventually abandoning of the project.

Preventing Maintenance-fatigue

Which also brings up another – to me – important part of that discussion. We have this saying "OpenSource is like sex – fun once, but you might have to support it for a life time", painting the problem of maintenance-fatigue way to rosy: the feeling of having to support this project you might wrote on a weekend and stopped using a year ago causing burn out and project death. How many projects do we have on github, which look for active maintainers to take over (I have at least 8 or so), and how many more that aren't openly saying it? But of course no one wants to take them over, even if they are in dire need of having them or love the project deeply, the likely costs do simply not make up for the potential benefit. What if, instead of just taking over the github repo, you would also hand over the support-channel  – totally officially, transferring all contracts to a new person, too. A maintainer wouldn't only inherit the code base and the brand (which they usually do right now) but also the revenues to actually continue working on it.

I think this would make it much more attractive for others to friendly take over projects and maintain them for the benefit of all involved.

What do you think?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants