Inside PSS - Part I
I've been with the Developer Support group in PSS for about 18 months now. These have probably been the best 18 months in professional life so far.
From my interactions with developers calling in to PSS I have realized that an increased awareness of the PSS’s process and workflow will help both the dev and Microsoft to have a great support experience every single time. For quite some time now I wanted to write about this but never did. Finally the inspiration came from Robert Scoble‘s great book on blogging – Naked Conversation.(There’s no better place to look for inspiration on blogging)
This article is going to be in parts. I am not sure how many parts will be needed to cover what I want to. I am going to talk about the ‘First Touch’ in the first part. This is basically things that would happen from the time of a call( for a new issue) to the time when someone from PSS will assert ownership of the issue and establish one-one contact with the caller.
Since I have been in Dev Support the information in this series of article may not exactly hold for other groups like platforms support or Bizapps support in PSS. But the outline is pretty much the same and minor variations may exist.
A call in to one of the Developer Support lines in the PSS would start with one of the CSRs – Customer Service Representatives. The CSR’s job is to
1) Get the contact and account details – Name, email id, tel.no and the support account
2) Get the problem description from the caller
3) Use the above 2 information to create a ‘case’ – this is a 15 digit id of the from
SRX<yymmdd><a running serial number for the day that starts with 600000>
The above case id or the SR number is the unique identifier of the case. Any subsequent communication would be based on this id.
4) Understand the problem description and route the case to the appropriate team
The first 3 things are fairly straightforward. The 4th step can be quite tricky. The CSRs are generalists. They have a fair ‘Level 100’ knowledge on a multitude of technologies like C++, VC++, VB, COM, Win32 APIs, .NET SDK/FW etc. Different support teams ‘own’ each of this technology space. Some teams are ‘language teams’ while some others are ‘technology teams’. For ex, a compiler issue/bug/how to would land up with the specific language team while an issue with a technology like Active Directory would end up in the AD team irrespective of the language used. As with any such classification there are grey areas and issues that might fit in more than one team depending on other factors.
The CSRs have to combine their generalist knowledge and the problem description given by the caller to determine which team would be the best place to handle the current issue. A typical ‘misroute’ – a situation where a case ends up in the wrong support team – will happen in one of the following scenarios
1) The CSR is not clear on the jargon/problem description. I have seen this is particularly so when acronyms are used.
2) The problem – most likely an error message – will point towards some technology while the actual reason may be something else. In this scenario the case will start with a team A and after some investigation it will end up in the team that supports the actual issue.
Once the CSR identifies the team that would take the issue he/she will call the corresponding team’s phone Queue. Normally the queues are manned such that there is a Support Engineer(SE) always available to take an incoming call. If one such engineer is available the CSR will talk to the SE and confirm if the case belongs to the SEs team. If yes, the CSR will bring back the caller in to the call and then drop off. The SE will take things from there.
However there are times when all SEs manning a particular queue are already in calls. In such cases the CSR will wait for some time to see if the call is being picked up. After a specific amount of time the CSR will drop off and the caller will be directly waiting for the call. This waiting call will show up on an app that runs in a shared desktop and almost all team members are aware of the waiting call. When someone eventually takes it he/she will not have any information about the case. This will result in the caller repeating almost everything he told to the CSR. Worse still, if the SE finds out that the case should start with a different group he will assume the role of a CSR and call in to that group. Sometimes callers prefer a call back to be setup at a specific time. In such cases the case is ‘dispatched’ to the target group and an SE from that group will do the callback accordingly.
Any case will always have an owner. The actual person who uses the case creation tool to enter details and get the case ID generated is the default owner of the case. Normally this is the CSR. The owner has the onus of solving the case or routing it to the proper person that will solve the case. Typically a case would not be owned by a CSR for more than 10 mins as an SE should have assumed the case ownership by then. When this doesn’t happen the CSR will check on the status and check up with the team that’s supposed to take the case through email. Typical exceptions to this are cases created towards the close of business or cases created during unusually high call volume days.
Once an SE owns the case an ‘opening email’ is sent to the caller. This typically contains the SE’s contact information, a brief description of the problem as the SE understands it and what is an agreeable resolution to the problem. Sometime some SEs might include some preliminary steps/troubleshooting that can help isolate the issue. The onus now is on the SE and he will drive the case till a mutually agreed upon closure is reached.
(continued in part II)