How I Handle Trello Support(blog.fogcreek.com)
blog.fogcreek.com
How I Handle Trello Support
http://blog.fogcreek.com/four-million-to-one/
6 comments
If Brian or others at Fog Creek read this, I'd suggest considering adding a way to provide more feedback when a user clicks on the 'I did/not find this article helpful' buttons; in another software package I use, when you click on the 'helpful' button it pops up a dialog asking 'Thank you for your feedback. We'd love to know what you liked about this page (text box here)'. When you click on the 'not helpful' button, the dialog says 'What were you trying to do in the software, and what would make this page more helpful? For example. "I was trying to fit data to a curve, but I think this variable is spelled wrong." (text box here). In both cases, they also have a text box 'May we contact you for more information? (Email)'. This way the support/doc team gets immediate actionable feedback, and instead of just an email the ticket can go right into your system, tagged with any useful information you want to gather (page in question and its rev #, OS, browser, user account info, etc). Keep up the great work Brian et al!
*BTW if you noticed someone who just voted down the 'Getting Started' page, that was me - I was just testing out if it asked for more information :)
This is really inspiring.
There are certainly some more complex professional products that probably warrant a higher support burden, but I've always felt that a lot of support costs are essentially consequences of software design not being quite right.
I think this example shows that with proper attention to design, detail, and user feedback, you can reduce the burden of support for most software. The one person filling the role, because there will always be SOME questions, and you'll always miss SOME improvements, can serve as a conduit to the team to improve the software.
Of course, if you already have a high support burden, transitioning could be challenging, but not impossible.
There are certainly some more complex professional products that probably warrant a higher support burden, but I've always felt that a lot of support costs are essentially consequences of software design not being quite right.
I think this example shows that with proper attention to design, detail, and user feedback, you can reduce the burden of support for most software. The one person filling the role, because there will always be SOME questions, and you'll always miss SOME improvements, can serve as a conduit to the team to improve the software.
Of course, if you already have a high support burden, transitioning could be challenging, but not impossible.
I develop a massively complex healthcare system for running medical practices / small hospitals. We have two support staff members. I think you have it right when you say "a lot of support costs are essentially consequences of software design not being quite right".
There's a number of things that I think help:
* Clear UI
- don't have rows of icons with no text
- try to compartmentalise areas of the application so users can build a 'mental map' of the application (for example we have 'patient home page', 'appointment home page', 'consultation suite', 'accounts home page'. So whole areas of the application work almost like documents.
* Explain everything in clear English
* Make sure the most commonly used actions always 'visible'
* Consider how the user will interact with your product. Healthcare especially is one where you must get this right, an extra click can drive the users crazy. It can be small things that really make a difference, I added a tag-cloud to the top of the medical-record for example, which really helps clinicians when the next patient walks through the door.
* Where possible make good decisions for the user, whether it's pre-selecting options, or removing clutter.
* Don't surprise users - They should never worry about what will happen if they click X
* Don't remove features unless you have properly explained why you're doing it
* Don't change a feature unless you're clearly making it better, or have again got buy-in.
There's probably loads more, but that's just off the top of my head. Then there's the standard stuff like: Never go offline, be fast, etc.
I think also most people would be surprised at how effective 'shiny stuff' is. Making it look pretty goes a long way.
There's a number of things that I think help:
* Clear UI
- don't have rows of icons with no text
- try to compartmentalise areas of the application so users can build a 'mental map' of the application (for example we have 'patient home page', 'appointment home page', 'consultation suite', 'accounts home page'. So whole areas of the application work almost like documents.
* Explain everything in clear English
* Make sure the most commonly used actions always 'visible'
* Consider how the user will interact with your product. Healthcare especially is one where you must get this right, an extra click can drive the users crazy. It can be small things that really make a difference, I added a tag-cloud to the top of the medical-record for example, which really helps clinicians when the next patient walks through the door.
* Where possible make good decisions for the user, whether it's pre-selecting options, or removing clutter.
* Don't surprise users - They should never worry about what will happen if they click X
* Don't remove features unless you have properly explained why you're doing it
* Don't change a feature unless you're clearly making it better, or have again got buy-in.
There's probably loads more, but that's just off the top of my head. Then there's the standard stuff like: Never go offline, be fast, etc.
I think also most people would be surprised at how effective 'shiny stuff' is. Making it look pretty goes a long way.
I've been reflecting on this further since reading the initial piece. I wanted to add, just reading this filled me with a sense of calm serenity. This is exactly the opposite of 'firefighter syndrome' where everyone is always heroically fixing things that shouldn't be broken in the first place, and staying late nights that shouldn't be needed. It feels good to be the hero, but you need to stop and work on fire prevention to get to a point where fires almost never happen. If you just play hero and ignore the root problems, you'll end up with a squad of great firefighters that you don't need, and a product that's still on fire regularly.
Unfortunately, it often looks (to others) like the firefighters making these great sacrifices are the best, most dedicated employees (and they may be), but all too often the person who leaves at 5 every day is the one keeping the fires under control in the first place. The most beautiful part of the post was "I am usually done with the email queue by lunch" and browsing social is "kind of the icing on the cake at the end of a busy day.". THOSE are the signs of a good process.
Unfortunately, it often looks (to others) like the firefighters making these great sacrifices are the best, most dedicated employees (and they may be), but all too often the person who leaves at 5 every day is the one keeping the fires under control in the first place. The most beautiful part of the post was "I am usually done with the email queue by lunch" and browsing social is "kind of the icing on the cake at the end of a busy day.". THOSE are the signs of a good process.
I definitely agree. I think it's really important to have your entire engineering team cycle through support at an interval that makes sense for your company.
ISO 8601 ftw, chaps!
I find the screenshot showing two columns - 4/22/2014 and 4/21/2014 - culturally interesting (I'm from Australia, but see this date format frequently).
You kind of take it for granted that everyone (else) in IT, especially those who produce something used by foreigners, ie. the makers of any web app, will have already embraced 8601. Or, at the very least, offer this as a locale / display option for their users, even if they themselves use an unsortable, ambiguous, region-specific format inside their own systems.
One of the very few things that continues to frustrate me with Trello is that every date shown to me is locked in the format "Mmm dd, yyyy at hh:mm", with no facility to modify that.
I find the screenshot showing two columns - 4/22/2014 and 4/21/2014 - culturally interesting (I'm from Australia, but see this date format frequently).
You kind of take it for granted that everyone (else) in IT, especially those who produce something used by foreigners, ie. the makers of any web app, will have already embraced 8601. Or, at the very least, offer this as a locale / display option for their users, even if they themselves use an unsortable, ambiguous, region-specific format inside their own systems.
One of the very few things that continues to frustrate me with Trello is that every date shown to me is locked in the format "Mmm dd, yyyy at hh:mm", with no facility to modify that.
I agree.
I love Trello and use it all day every day, and one of very few minor annoyances is the date/time formatting.
I love Trello and use it all day every day, and one of very few minor annoyances is the date/time formatting.
I totally agree with the idea that calm serenity is the symptom of a software process done right.
What I would like to plead for is hosted Fogcreek and other products in the EU only. Data protection laws here make getting government work awkward if you use hosted services outside the EU. It's painful. please host here !!!
ps anyone else in same position?
What I would like to plead for is hosted Fogcreek and other products in the EU only. Data protection laws here make getting government work awkward if you use hosted services outside the EU. It's painful. please host here !!!
ps anyone else in same position?
Hosting in the EU would not change much as far as the NSA's reach is concerned — as long as it is a U.S. company, your data is accessible to government agencies.
It's a very real concern, but I don't think hosting in the E.U. solves anything.
It's a very real concern, but I don't think hosting in the E.U. solves anything.
Maybe I was not clear - this is not about stopping the NSA reading my support emails (I pretty much assume anything I do that is digital is caught, even if not read)
My concern is winning business with UK public sector - the Data Protection Act and ICO are clear on processing data only inside legal regiemes that share the same data privacy protections - in other words EU companies must process inside EU borders.
Or rather we don't have to but it's a pain in the arse to explain why not and I have enough to do so please please please either stick processors inside the EU or can I find a bunch if similar parties who fancy shouldering the cost of doing same.
My concern is winning business with UK public sector - the Data Protection Act and ICO are clear on processing data only inside legal regiemes that share the same data privacy protections - in other words EU companies must process inside EU borders.
Or rather we don't have to but it's a pain in the arse to explain why not and I have enough to do so please please please either stick processors inside the EU or can I find a bunch if similar parties who fancy shouldering the cost of doing same.
The linear scale on your first plot undersells your accomplishment. The two red pixels, if calibrated by the 4,000,000 users at left, correspond to 25,000 support staff. It sounds like there's only you.
A logarithmic scale, like this: https://flic.kr/p/nyf11i shows off your feat more-completely.
Thank you for making Trello. It's made my life more organized and efficient.
A logarithmic scale, like this: https://flic.kr/p/nyf11i shows off your feat more-completely.
Thank you for making Trello. It's made my life more organized and efficient.
Having set up something similar yesterday for webhook.com here's what I ended up going with.
1. Using zendesk for incoming emails and a knowledge base. 2. Installing tissueapp plugin for it to allow you to convert a zendesk email into a github issue. Even better, wherever you respond from (email, zendesk, or github), the other instances get updated and alert the user. 3. Pipe out hipchat notices (zendesk has an option for this) into our chat room whenever issues/tickets are updated.
Ended up working really well and doesn't get our engineering team out of the tools they already use.
1. Using zendesk for incoming emails and a knowledge base. 2. Installing tissueapp plugin for it to allow you to convert a zendesk email into a github issue. Even better, wherever you respond from (email, zendesk, or github), the other instances get updated and alert the user. 3. Pipe out hipchat notices (zendesk has an option for this) into our chat room whenever issues/tickets are updated.
Ended up working really well and doesn't get our engineering team out of the tools they already use.