I'll toss my hat in the ring.

In terms of process and visibility, I think our best-case would be an  
app which processed incoming emails, allowed fixers to be assigned,  
and which we could post information (optionally emailing the  
requester), as well as cross-referencing the relevant Trac tickets,  
when appropriate.

I suspect that the Trac setup smk & myrond are using will get us most  
of the way there. The one thing I can think of that we'd want which I  
believe would require development effort would be triggers for closed  
tickets (so that when a Trac ticket in livablestreets was closed, it'd  
add a post to the customer-service Trac instance, alerting us that the  
original reporter should be given a heads-up.

Longer-term, it'd be nice to have some kind of reporting so we can  
spot what kinds of patterns there are in reported issues.

Chris

On Oct 6, 2008, at 10:18 AM, Nick Grossman wrote:

> Hey All,
>
> So, no responses to this so far.  I'd like to get something going  
> soon, so please chime in if a) you have opinions on how this should  
> work or b) if you'd like to be part of a team that handles these  
> communications.  Once I get a group together, we can hash out  
> details off of these main lists.
>
> Thanks,
> Nick
>
> On Oct 2, 2008, at 3:49 PM, Nick Grossman wrote:
>> Hey everyone,
>>
>> Recently, I've been thinking about how we handle customer support  
>> here, for the various websites we maintain.  We get a pretty steady  
>> stream of customer emails, consisting of either bug reports  
>> (through the Whoops! page form), questions about how to use the  
>> site, or requests for features.  Between openplans.org and  
>> livablestreets.com, we get anywhere between 5 and 25 emails per week.
>>
>> When Bryan was here, he handled these emails; responding to people,  
>> answering their questions, and relaying bugs to the dev team.  Now  
>> that he's gone, the emails have been coming to me, and I've been  
>> trying to do the same.
>>
>> There are a few problems with the current situation, as I see it:
>>
>>  * It's not transparent -- we're doing it via private email right  
>> now, so we as a team can't see what's coming in day-to-day.
>>
>>  * It's hard to keep track of -- aside from not being transparent,  
>> dealing with everything in email can be confusing, especially when  
>> we get multiple reports about the same bug.  It's difficult to re- 
>> connect fixed bugs with original reporters, and we don't do a good  
>> enough job getting back to people when their issues are fixed.
>>
>>  * It's too much for one person to do -- it's a lot of work to stay  
>> on top of, and it's easy to fall behind.
>>
>> That said, doing a really good job on this is hugely important, and  
>> it's an area where we can get a big bang for the buck by being a  
>> bit more organized.
>>
>>  * Customer service is important.  By being really responsive and  
>> helpful, we can really develop passionate users.  Anyone who is  
>> willing to take the time to send us an email is a potential  
>> evangelist if we treat them right.
>>
>>  * Personal service and responsiveness are endearing.  If we can  
>> fix someone's problem, then deploy the fix that day, people will be  
>> amazed.  From their POV, hearing back from someone with the power  
>> to fix their problem is meaningful.
>>
>>  * Speed matters.  People are always super-psyched when they get a  
>> response to a support email right away.  We should aim to answer  
>> every email the day it arrives.
>>
>>  * We can and should learn a LOT from these emails.  It's great to  
>> see where people get hung up, and it's even better to hear what  
>> they want, directly from them.  Every email is a valuable gem of  
>> knowledge that we're lucky to have.
>>
>>  * Dealing with customers directly is good practice. It reminds us  
>> that there are real people out there using our software every day.
>>
>> So, with all that in mind, I'd like to create a program for  
>> handling customer support more systematically and effectively.  I  
>> don't think I have the whole answer yet, but I'd like to at least  
>> start a discussion with the goal of getting a first attempt a  
>> system going right away.  Here's what I have in mind:
>>
>>  * Convene a group of "ambassadors" (for lack of a less cliche  
>> term), who rotate through support responsibility.  This should be  
>> an opt-in group, consisting potentially of anyone (not just  
>> developers).
>>
>>  * Each week, a different member of the group would be on support  
>> duty, and would be responsible for handling requests in a timely,  
>> friendly, and helpful matter.  If you're a developer  and can fix  
>> the problem, great -- fix it right away -- otherwise, pass it on to  
>> someone on the dev team for tech followup.  Forward content-related  
>> requests (less frequent) to the appropriate folks.
>>
>>  * Create a public (at least internally) method for archiving these  
>> emails, probably by creating a mailing list that everyone in the  
>> support group is on.
>>
>>  * NOTE: there's been talk of how we should handle live site errors  
>> and error reports in an automated way, potentially using trac.  I  
>> just want to make it clear that this is a separate discussion, and  
>> is more about customer service and personal connections than about  
>> automated error management (thought that's really important too).
>>
>>  * ANOTHER NOTE: I'm mainly talking about the bug & feature request  
>> emails that we get.  More substantive community management  
>> (specifically for LSN) is another matter.
>>
>> This is an idea for a support framework, so I welcome your  
>> suggestions.  Even better, I welcome people who are interested in  
>> being "ambassadors" to continue the discussion separately and hash  
>> out a plan.
>>
>> Here are a few links on providing good customer support:
>>
>> http://www.joelonsoftware.com/articles/customerservice.html
>> http://www.37signals.com/svn/posts/1174-are-you-finding-the-root- 
>> cause
>>
>>
>> Thanks,
>> Nick
>>
>>
>> --
>> Nick Grossman
>> The Open Planning Project -- http://topp.openplans.org
>> nickyg@...
>> (917) 825-6590
>>
>>
>>
>
> --
> Nick Grossman
> The Open Planning Project -- http://topp.openplans.org
> nickyg@...
> (917) 825-6590
>
>
>

Nick Grossman wrote:
> Hey All,
> 
> So, no responses to this so far.  I'd like to get something going soon, 
> so please chime in if a) you have opinions on how this should work or b) 
> if you'd like to be part of a team that handles these communications. 
>  Once I get a group together, we can hash out details off of these main 
> lists.


- count me in as part of the support contact rotation

- i'd lean in the direction of a lighter ticketing system rather than a 
full-blown CRM like Sugar.  if we really need a full CRM (which i don't think 
we do), maybe we should consider salesforce.com, so we don't have to take on 
any new administrative tools ourselves.  i know salesforce gives you all sorts 
of ways to get at your data, and they apparently have great pricing for 
non-profits.

-r