Support on Team Foundation Service
Update: Um, egg on face. When I first posted this, it ended up having the email thread with the customer attached. I updated it to remove it as quickly as possible but I sincerely apologize.
I got an email from a customer a couple of days ago asking about issues he was having with Team Foundation Service. After looping in our internal support team, he asked if that was a route he could use directly. I took the time to write up some thoughts on support and thought it would be interesting to share them in a post (having been embellished slightly) .
Here are the thoughts…
Unfortunately, you won’t be able to use that alias – it’s internal. Let me explain how things work and then talk about where we are going.
Today, there are 3 groups of people at play in supporting Team Foundation Service:
1) Customer support (CSS) – These are the people whose job it is to help customers with issues they are having. CSS is geared to manage significant numbers of customer issues, manage priorities, response times, etc. Their primary goal is to make sure each customer gets the help and information they need. Without going into too much detail CSS provides a couple of levels of service. They provide free service for certain classes of issues and escalate to paid service when appropriate.
2) Service delivery (SD) – The service delivery team is a part of the product team and is primarily responsible for production live site issues. Their primary responsibility is to keep the service running efficiently, reliably, etc. They have the greatest access to the production system for live issue diagnosis and are the official keeper of the answer to the question “Is anything wrong with the service right now?” Although, sometimes this function is handled in an aggregate way where the service might be fine but some set of customers are having serious issue with it – this can be a result of how you evaluate service health, we aspire to measure service health in a way where we measure the experience of each individual account/user rather than some aggregate things like request queue length, event log errors, latency, etc.
3) Development team – We practice “DevOps”. That means that the teams building, testing and designing the features of our service are responsible for making sure their features are working well in production (in addition to building new capabilities, of course).
All 3 groups meet on a regular basis to share issues, learning, etc. There are communication paths between all of them that enable issues to be transferred quickly and easily The alias you saw me mention was the one that gets the attention of the SD team.
So, generally, we’d like for CSS to be the primary point of entry for customer issues. They can help isolate whether it is a customer specific issue, known issue or a service wide issue. If CSS is unable to address the issue, they can escalate either to the SD or Dev team (depending on the nature of the issue) and the SD team can escalate to the Dev team. As a team we work hard to make sure customer issues are addressed promptly and satisfactorily.
There are different ways to get to CSS. One way (particularly for the service) is to use the forums. Our CSS team monitors them. I was just checking and most issues get a response within a few hours. Another option is to call CSS. You will get routed to the right support organization from the global Microsoft CSS # and that way you can get an almost instant response – though that route takes you more quickly into a paying escalation. For enterprise customers we offer even higher touch ways of getting support that includes a “primary contact” that facilitates resolution of all issues the customer faces. There are probably other ways to initiate contact in place today but I don’t know them all.
Of course there are other ways to communicate with us as well and we list them on our “Community” page on http://tfs.visualstudio.com.
Just the other week I was having a conversation with my team about our need to have a better support path from our web site. We need a “contact us” capability that enables you to send an electronic message that will get attention somewhere between phone call and forum post and provides privacy for you to provide confidential information that you don’t want to share with the world. In addition, we need to do better at reporting health of the service – both in the aggregate and for individual accounts. We have a service health page today but I believe we could do better with this than we do. My guess is that, for your scenario, something like this would be the most effective.
Of course, from time to time, customers email me (or post on my blog) about issues they are having. For whatever reason you choose to believe, I take these requests seriously and either answer myself or, more commonly, route to the right person. Others on my team do similarly. Buck, for instance, watches Twitter pretty closely and any tweet with #tfservice or to @tfservice will generally get picked up.
Unfortunately, this is sometimes the most effective way to get support – first because there’s just about no other path that will get you to the expert in an area more quickly; and second because when someone gets email from me, they tend to assume it’s high priority and jump on it immediately. Unfortunately, this approach does not scale – for many reasons. I can’t be by my email all the time. Sometimes I’m on vacation, customer visits, all day meetings, just fall behind on email or any number of other things. So, while the 80th percentile might be the best 80th percentile you could get anywhere, the 99th percentile really sucks. Also, it can create team dynamics issues where devs who should be building the next feature are spending time answering a question that the CSS team already knows the answer to. I try to be smart when I route things and route things to CSS when I think it’s the better answer but I guarantee I don’t do as well as I should because I usually have about 30 seconds to skim the issue and decide where to send it.
I’ve asked a couple of PMs on my team to put their heads together to find a better way for customers to raise support issues than we provide today. Hopefully we’ll have something we can share in a few sprints.
Brian
Light
Dark
0 comments