Rethinking Tech Support
Now that it’s been a few weeks since we launched EllisLab Support, we wanted to offer a peek behind the curtain and share why we made such a dramatic change in the way we provide tech support.
The Old Way of Doing Things
Up until a few weeks ago, we provided technical support for all our commercial software in the public support forums. We put this system in place very early on, and it worked quite well when our customer-base was small and the volume of requests was manageable. EllisLab staff monitored the forums, and we were able to get good responses out rather quickly. Other ExpressionEngine users tossed in to help, and everybody was happy.
But as the number of designers and developers using ExpressionEngine increased, we found that the forum-based support system didn’t scale well. Why? Because forums have no mechanism to ensure that each support request gets tracked and resolved in a timely manner, or that requests get assigned and transferred over to the support person on call over multiple shifts, or that requests get sorted according to urgency or any other criteria. A forum isn’t a help desk, so many of the features of even the most basic help desk were missing, requiring us to cobble together workarounds. There was also no privacy, forcing customers who didn’t want to share sensitive information publicly to play coy with the details. All that mental overhead ran our Customer Advocates ragged, and worse of all, it didn’t make for a great experience for our customers.
It had also become evident that the economic model of the old system didn’t work either. As several third-party developers noted during the developer’s round-table this year at EECI, unlimited tech support that comes included with one-time software purchases just doesn’t scale. Many folks were surprised to learn that some well-regarded add-on makers were breaking even or actually taking a loss to provide support for their software. Of course, that makes perfect sense. The cost to provide an ongoing service isn’t well-supported by one-time purchases, and the disconnect only grows more severe as the number of one-time purchases increases.
Simply put, the system became a huge obstacle, and the economics of the support model had us stuck. We’d already tweaked things and improved as much as we possibly could with that creaky old system in place, so we knew we had to do something bold. We took a step back, thanked it for all the good times, and sent it off into the sunset.
A Blank Slate
With the opportunity to start fresh, we asked ourselves what kind of support system we’d want to put in place today, built from the ground up. Our chief aim was to create the best support experience possible, so we started with a few goals to help us define what that would look like.
Support people, not software.
It may be common to attach tech support to each particular website or software installation, but that doesn’t make sense to us. Whether you run a single hobby site or dozens of clients’ sites, you’re the one coming to us asking for help. That’s why with each of our support plans, you get an unlimited number of support tickets covering whichever site you’re working on.
You can submit a support ticket with questions about any properly licensed site you’re working on, even if that site’s license isn’t on your account. Each license is directly attached to a website. Each support plan is attached to a person. There’s no longer a correlation between software licenses and tech support at EllisLab.
Make it simple to get help quickly.
We studied the data behind our old support system, and we noticed something interesting. By far, the majority of our customers only need occasional help from our support team, but when they do need help, they want it to be prompt. For that reason, even our basic support plan includes an urgent ticket that gets a guaranteed response within 2 business hours, and there’s no obligation to keep a support plan around if you don’t need it. We couldn’t have dreamed of delivering this level of service under the old system.
Keep the conversations personal and private.
Customers often don’t like to share all the details of their tech support issues in a public forum, and who can blame them? Furthermore, it’s very difficult to have meaningful, one-on-one conversations in a public space where everyone can observe, chime in, and critique. It really had a negative effect that was hard to quantify. A private environment means both the Customer Advocate and the person we’re helping can share sensitive information, keep their responses frank and to the point, and keep the conversation on track for a much faster resolution.
Keep site login credentials secure.
We knew we’d often need to receive a troubled site’s login information in the course of providing tech support, and anything less than a completely secure method of sharing it simply wasn’t going to fly with us. We designed a system so that login credentials shared with us are transmitted over a secure connection, encrypted before they’re stored, and permanently removed from our system in 30 days or when you choose to purge it, whichever is sooner.
After a ticket’s first response, keep it at the forefront to rapidly respond and resolve it.
This one’s probably the most important goal because it was only possible if we rebuilt the support system from the ground up. As mentioned earlier, a tech support forum isn’t a help desk, so a team trying to provide tech support in an official capacity is forced to use a workflow that’s far less than ideal.
The new support system automates as much of the behind-the-scenes stuff as possible to let our Customer Advocates focus on delivering incredible support. For example, the new system handles the math behind determining when it’s time for the support team to take a new Silver, Gold, Platinum, or urgent ticket — since each of those types of tickets comes with a different guaranteed first-response time — and it automatically alerts the team when that time comes. Until that alert, each support agent focuses completely on the tickets that are assigned to them. That means each support agent is only handling a few in-progress support cases at a time, giving each person on the other end of that ticket much faster, more personal service. Instead of support resolutions taking days (or even weeks!) like we had in the forums, we’re now seeing most tickets resolved within a day of that first response. That’s an astonishing difference, and support customers are absolutely loving the new experience. It’s really allowing our Customer Advocates to do what they do best.
The Response So Far
We’ve already received lots of awesome feedback about the EllisLab Support experience, so let me share just a handful of it:
Yes, you cracked it! Awesome, thanks so much. This is totally
worth $49 a month!
Thanks sooo much for all the help you and your co-workers had given me. You guys are sooooooooooooooooo awesome!
By the way, you all have been a pleasure to work with. The way you work with your customers is great. As I work with you, I’m taking mental notes of the way your team approaches providing support to emulate some of what you all do within our teams support process.
The real magic here isn’t the new system, of course. We’ve got some of the smartest, most caring support agents I’ve ever seen working with our customers every day, and that’s really what makes the difference. The new support system just gives them a chance to be awesome. The old one didn’t.
We love delighting you and really creating an amazing experience, and now we’re set up to do that in ways we couldn’t have dreamed before.
Have you given us a chance to help you yet? Don’t forget, all license holders get 3 months EllisLab Support to try, no strings attached. To start your complementary 3 month support plan, just add Silver Support to your cart in the store and complete the order as usual.
Comments & Feedback
I’ve said it before and I’ll say it again: the new price points may be great for their target audience, but you’re still missing a large small-business portion of your audience. The latter would best be served by a per-ticket pricing, not a per-month price. Offer a support package with 10 support requests, no time limit, and no urgent requests, for $10-$20 or so, and I think a lot of the issues people have raised with the new support plans will vanish.
Michael C. (ProImage)
That implies you value their 1 on 1 technical support at $1-$2 per incident (which if you’re pre-buying packs doesn’t account for the time value of money). Does that sound reasonable? It’s not possible to have professional PHP developers answer technical questions for $1 per incident.
IanL
Thanks for the update Kevin. Now that we know what works better for the support team, let’s talk a bit about what works for us web developers and designers. Obviously, making your workflow as efficient as possible is important to you. All of us out here making our workflow as efficient as possible is as important to us as your is to you.
So lets start off with how I (and many others) used to use the forums. If I have a problem, or want to know how to do something, I go and search the forum. 90% of the time I would find the information or solution that I needed without having to ask a support person for help. In fact, you guys never even knew I had a problem or was looking for a solution, because I never had to post anything. With the 15 or so licensed installations I’ve built or maintained, I’ve only been responsible for the purchase of a handful, and only posed a small number of actual requests that needed support followup. And I think I’ve probably answered as many support questions as I’ve asked over the years. That’s to say, my need of actual support has been limited due to the information available in the forums. As the forums wither, my need for actual support or turning to other sources (like StackExchange) will only increase, and my satisfaction as an EE customer will diminish, as I like being able to learn and find answers in a forum-like atmosphere (yes, I’m old-school, but so are many others).
And in reading the forums, so much of what I heard was an “I had this problem or need, and this thread solved it for me.” And for every one of those “me too’s”, I’m sure there were many more like me who just found what they needed and went on with their work, solution in hand, unbeknownst to EE support.
WIth the new system, even though many people may have the same issue (whether its how to discover and use an EE feature, work around a bug, deal with a third party interactions, hosting problems, find pertinent documentation, etc.), the support staff will have to deal with each individually, and repetitively—which is neither efficient for support staff, or developers/designers who now have to purchase support and work through the time inefficiencies of the new system. What once might have taken me a matter of minutes (looking up existing info on the forums, and discovering a solution) now comes with an indeterminate time lag, and a price. And there is no electron trail to help the next person who has the exact same, or similar problem. So instead of finding a solution quickly on my own, I get to file a support request, and tell my boss/client that I’ll get back to work whenever EE support gets back to me (only during their office hours, which definitely don’t sync with my often-used night/weekend work schedule).
So one of the biggest problems I can see is how to preserve any sort of “institutional knowledge” that includes support staff involvement in any sort of relevant and public format to help designers/developers like myself. Whether this could take the form of extensive FAQs or some other sort of public and free help system—EE afterall is the sort of of go-to software that us designers/developers might want to use to build a system to solve such a problem—is up to you guys. I’m not as concerned about how you solve this problem, just that it get solved and something replaces what has been lost (institutional knowledge) with the exit of support from the forums. But assuredly, one of the most missed aspects of official support in the forums, and a diminishing capacity of the current forums to stay relevant, will be a way to attract new clients, and provide them with an excellent forum through which they learn, troubleshoot and solve problems, and make important business connections.
A public community is built and maintained by the involvement of both developers/designers and EE staff. The ability to interact with staff in a public fashion has been radically curtailed. We need a system of communication that works for both EllisLab and its clientele. We are starting to hear what you need. When will you start listening to, and answering the sorts of needs that our workflow entails?
wildrock
@wildrock - Thanks for the thoughtful feedback. The institutional knowledge question is a good one. Do you think more thorough documentation, better software, and other public support channels (Community Support forum and Stack Exchange, for example) might help fill in any gaps left with the end of official forum-based tech support?
Kevin Smith
I was writing a comment at the same moment wildrock was writing his.
He was very diplomatic, mine was less so:
If i may play the devil’s advocate, this is also a model for perpetuate support plans.
Any question one might have, might already have been asked a hundred times, but you’ld never know.
From what i can see, non of the support-plan answers will flow into a (public accessible) knowledge base,
wiki or official support forum, each of which have been either removed, shut-down or closed.
Of course, some solutions and answers are still available in the now read-only, archived support forum,
but a lot of these will probably become obsolete after the first round of next ExpressionEngine releases.
From a business perspective this is all completely understandable, but for a community,
confronted with such an unannounced drastic move, at once, this can be a slap, if not punch, in the face.
However, thru a rather strange synchronicity there is now a community-based StackExchange effort,
(which still needs to pass the final Beta-stage before acceptance), where some sort of public knowledge-base
will become available, with peer-to-peer support by the very same community that EllisLab IMO somewhat left behind.
GDmac - expocom
@kevin a knowledge base might be a start, with common questions and answers, and (important) examples!
GDmac - expocom
I think it’s imperative that the forums remain open. It seriously has me thinking about switching platforms.
I understand the need for you to change your model with the new paid support plans but I think that the results of these tickets should always be made public. From my point of view this new private method seems to go in the complete opposite direction to the concept of shared knowledge and seems to become more about being a money spinner, not saying it is but that’s how it appears. Why else answer the same question 50 times? i think you will find people will always have unique questions and be willing to pay for that answer, but they are also going to be really put off by having to pay for something they know hundreds of other users would have already had to deal with. I think you need to find a model that fits better with the EE philosophy of open source yet commercial. Perhaps even allowing users to opt in/out to make their tickets public, and give them incentives to do so.
Mattias01
I think a support package, with no urgent tickets or one urgent ticket, and no time limit would be good. Just a here’s a 5 or 10 pack of service. I admit to doing this with my chiropractor. The price @Michael C. (ProImage) suggest is way to low. I’d spend $500 on a 10-pack of support tickets ($49 a ticket) rather than $49/mo. I’d possibly spend more, but even though we support nonprofits almost exclusively, that would be a great support bargain for us.
The big issue is timing. We go months without needing assistance, than may need 5 tickets in a month. It’s laziness, but I’d rather not have to think about starting and stopping the clock, and while cost wise it works out pretty darn close to the monthly option. There’s something about the monthly fee that kind of sucks. Probably the timing. Our clients pay in cycles, and forking over $500 for a 10-pack of support or even a year of support is reasonable, it just seems easier to time it as a 1 time payment.
That said, I do agree with @wildrock around creating institutional knowledge. Private support systems don’t, unless each question then gets a written solution. I’m a proud contributor to ‘public domain’ and firmly believe in creating accessible knowledge about systems (as many as possible). A single solution could help 1 or 100 people. Making it available means others can use it and maybe reduce urgency, providing it to just one, means others will continue to ask the same question, again and again, and again.
I do acknowledge that that does happen to some extent anyway, but laziness as a cause is very different than the information just wasn’t available.
* P.S. Thanks for the foreign language encoded in the control panel solution, provided today. That rocked! I think Pascal solved.
allgood2
For any product, the demand for support rises in proportion to its instability (or unreliability), and its general unfamiliarity in the marketplace.
At the the other end of that scale, a stable and familiar product needs less support, and that mostly for new users.
The above applies relatively - the absolute levels of support are a function of the product’s nature (technology, degree-of-hazard etc) and its sales volume.
Since EE clearly is somewhat complex but not overly so, and non-hazardous (except to our sleep patterns,) I have to conclude that the problem is some combination of sales volume and where EE falls on the scale outlined.
I don’t buy the suggestion that the lack of scalability of the former support model is mostly due to sales growth, because a mature, stable and familiar product would obviously be quite easy to support via “institutional” knowledge.
I any case, there is no need to suggest this. I concede, and so would most of the EE community, that EE is still somewhat immature, otherwise why would all those third party add-ons be so popular, and why so many bugs? A certain level of ongoing instability and unfamiliarity are therefore only to be expected at this stage of the technology.
However, instability is Elislab’s problem, not something to be visited upon the user base.
And unfamiliarity might be Ellislab’s problem (due to inadequate documentation) or not (due to new and desirable features.)
A clue lies in the statement that the forum is not a suitable support vehicle. I can buy that if we define “support” as bug-fixing, but now we have identified the lack of a suitable bug-tracking technology as the problem, not an inherent flaw in the nature of forums. Ellislab’s lack of a suitable bug-tracker is also not to be visited upon the users, especially considering the work that Ellislab customers did and still put into detecting, isolating and often code-level diagnosis of bugs.
So I think the old model probably did not scale because the sales volume of a relatively immature EE is either exploding, and Ellislab is not adequately capitalized to weather the storm, or horrors, sales growth has stopped or is falling.
This is a dangerous situation, even if due to growth - explosive growth has knackered many a company long before Ellislab came on the scene. Problems due to growth will not necessarily be mitigated by charging for support, because a customer who pays for support will not be happy to pay for support entailed by instability, if that is mostly the problem.
On the other hand, customers are happy to pay for support entailed by unfamiliarity, but that kind of support is usually called “training,” and training has a long and illustrious record as a profit center.
Let’s be optimistic and stipulate that Ellislab is growing explosively. Then which is it Ellislab, exploding growth of support entailed by instability or exploding growth entailed by the need for training?
My bet? Probably a lot of both, which means the ones who paid for training will stay happy, and the ones who paid for instability will become unhappy.
The proportions of that mix are critical to Ellislab’s survival.
JohnD
Thanks for shedding a light on the support changes. I can understand that you need to build a sustainable way to provide decent support.
But I agree with wildrock that there needs to be a way to get to information which helps us building EE sites, besides the user guide. I’ve often used the forum and the wiki as a place to get answers before nagging support, and I’m sure a lot of people did the same. I don’t think I would have ever started with EE if I hadn’t been able to learn from the knowledge in the forum. And it’s not just about bugs and problems, it’s also about exploring ideas about how to get things done (or not) with Expression Engine, even if it’s through using a bit of php, css, or js trickery.
In short:
- Indeed, we need a knowledge base that helps us get ahead with EE and goes beyond the docs. I’ve been looking at squarespace about this. First you’ll get an array of decent how-to’s, troubleshooting, examples and if that doesn’t help, you can open a support ticket.
- Why is there no clear link with devot-ee anymore? It’s an essential part of the added value of Expression Engine?
- How can Ellislab keep in touch with the community if it’s not through the forums anymore? And how can users share valuable information with each other and Ellislab that is not necessarily support related ? For instance, the remarks in the user guide were quite useful, why strip them out? And why remove the wiki?
noregt
We recently started using the EllisLabs support for some client ExpressionEngine websites. Honestly, it’s nice.
We’d been hesitant to use the original support channel before because it was forum based and the issues with privacy were pretty important to our team as client info. is sensitive. We used it, but begrudgingly. So, when Ellislabs launched this new support option, from our perspective - we were saying to ourselves, finally.
While we love open source software, and free exchange of ideas, knowledge, etc. We prefer some sorta license and payment that supports the software company and not only for the core software. When this is your business I firmly believe in things like licensing, business level support and the other services. They’re what make providing business-to-business services at a higher level possible and secure. When the software company is making a profit, then we don’t have to worry about whether or not they’ll be around next year, or in 5 years and as such neither do our clients.
When my clients decide to hire us on as their service provider their trusting in our judgement, and in our case that includes thinking about their website’s long term security, and support - provided by qualified professionals. They hire my company to benefit their overall business objectives and today those objectives will always include the companies official website.
I think wondering about cost verses value and return is a legitimate question. If you are curious about EllisLabs support give it a try, I think right now for people with current licenses you can get 3 months free support and see what it’s like for yourself.
We’ve found the service to be more than effective and over time I think the current monthly fee will more than pay for itself. The support specialists are always courteous, knowledgeable, and friendly. They go above and beyond. I’ve paid for support with other providers and based on years of experience with other businesses, EllisLabs really does a good job in this game. If your using ExpressionEngine for business then you probably already know what I mean. I think this is a great balanced approach, especially when considering the free forums are still there too.
...Anyway, my 2cents.
Take care,
Reuben
FlyDuo
“That implies you value their 1 on 1 technical support at $1-$2 per incident (which if you’re pre-buying packs doesn’t account for the time value of money). Does that sound reasonable? It’s not possible to have professional PHP developers answer technical questions for $1 per incident” - IanL
“The price @Michael C. (ProImage) suggest is way to low. I’d spend $500 on a 10-pack of support tickets ($49 a ticket) rather than $49/mo.” - allgood2
I guess I should have been clearer… I wasn’t trying to present suggested pricing as much as I was trying to convey the type of package I personally think would be useful - i.e. one where we pay per-ticket vs per-month (and don’t get the urgent ticket benefit). You’re both completely right in that the prices I tossed out are too low.
However, whatever the price for such a package ends up being, it has to be less than the $49/month package to make any sense. If it’s less than or equal to the $49/month package, you might as well play the subscribe-get support-end subscription method EllisLab are pushing. Seems to me the sweet spot for a per-ticket package would probably be around half of the $49/month package, and include however many support tickets as is fair/sustainable/whatever at that price point - two or three, perhaps?
Michael C. (ProImage)
Correction: that should be “If it’s higher than or equal to the $49/month package…” in the 2nd paragraph above. :p
Michael C. (ProImage)
Awesome! Support is finally here!! Whoo Hoo!!... wait a minute… 2 days for first response? Are you serious?? I might as well jump on a forum. Very disappointing :(
ozmo
Actually, I was thinking about my original comment on a ticket package, and was wondering, at least for the Silver Support package, why couldn’t there just be an annual purchase option? I like the new support system, though I still believe that efforts should be made to create a public knowledge base. But I’d definitely prefer to pay $500-$600 once rather than $49 per month.
I just hate managing subscription payments, but also, our work tends to be annual or quarterly contracts, so some months are just far better for us to pay everything we can, so we don’t have to worry about the timing of a bill coming in later. I’d vote for that option. I’d love to just pay the annual rate and be done with it, until you send a reminder to renew again.
allgood2
@allgood2 - Thanks for the feedback, that’s certainly good to know!
Kevin Smith
I guess that makes sense, you only want positive comments on your blog articles. Good luck with your bad ideas!
SneakyDave
Firstly, kudos for being willing and flexible for change. I’ll throw in my $0.02 worth (adjust for inflation if necessary)...
I’d suggest that 90% of EE users are smart. Web designers & developers typically assume complexity, and many revel in it. Sure, there is a variable threshold of pain depending on the audience. Business users might have low tolerance. That’s why they would outsource the building of a website to a 3rd party. Developers have a high tolerance. As long as they can find the answers somewhere, they’ll make it work. And they love to share their findings. That’s what “Community” is all about.
In the past you had a great developer solution for support. But I must admit in the initial take-up of EE, I went to Amazon and bought whatever books I could find on the subject, along with scouring the web for tutorial videos, etc. But within a few days, I was producing output. Now if I run into anything tricky, I’d look for a forum for support.
Would my customers do that? Probably not, unless its some guy in the IT department who’s job is to develop their website. They’ll be like me - they want forums and support somewhere. But if the boss comes down hard on them demanding why the website isn’t done yet, they’d love any tool they could buy to help them get the job done.
Signing up for monthly support is not really going to cut it for those that don’t want to be chained to the hip with Ellislabs for development. A “per incident” support plan is best here. However if you are selling the supported backup of EE to some CFO in a big company - sure they might want that. But at the end of the day, they are going to ask their IT department, “Well what do you guys want?” and that’s going to drive expenditure.
I think that you might find that by removing the community nature of support, it will popup all by itself on the Internet built by the community anyway. I guess that’s not a bad thing. But it won’t help you directly with a business model to derive income from support. I think rather than fighting what will probably happen anyway, you might want to consider a per incident support plan. Maybe sell it in “packages” (e.g. 5 incidents = $300, or something like that). I’m sure you guys will work out the numbers on that. But I can tell you that I’d never spend $49 a month for support that I’d use infrequently and I suggest that I’m not alone in that regard.
Myles Wakeham
I have to say I’m disappointed by the new monthly fee-only based support plan. However, having worked for a software company who sold one-time perpetual licenses (and then went out of business), I definitely understand the need for a recurring revenue stream.
I work mostly with nonprofits and I simply can’t afford the cheapest, $49/month plan. ExpressionEngine has effectively priced itself out of my tool box. I agree with the other posters who’ve suggested providing a per-incident plan. With the current pricing scheme I’ll have to move away from ExpressionEngine to another CMS which is too bad.
In order to stay with ExpressionEngine (w/o support), I would need a high-quality, well-maintained power-searchable knowledge base so that I could solve problems that come up by myself. And way better, comprehensive tutorials. Such as multiple, entire sites build with EE and how they were built.
ExpressionEngine has been a great tool for me and I will miss it. Perhaps you’ll find a way to provide less expensive support for customers like me.
Best wishes,
-NorthK
northk
You must be logged in to comment on this blog post