As practiced and applied as Global Product Support Manager

1. © 2013 International Business Machines Corporation 1Internal Use Only
Achieving High Performance Quotient in Customer
Support Teams
Irfan Khalid
B2B Product Support Manager – Asia Pacific

2. © 2013 International Business Machines Corporation 2Internal Use Only
Approach
PMR – FTF – First thing first
PMR – progress tracking
PMR – Getting that survey for a S1
PMR – Extra eyes
PMR – the team approach and team expectation
PMR – lets speak about it
PMR – closure – what next ?
PMR – hot ticket tracking
PMR – escalation management
PMR – gaining confidence
NSI – positive action planning
NSI – explore concerns

3. © 2013 International Business Machines Corporation 3Internal Use Only
Sessions / meetings to be conducted – topics ( using design thinking approach )
PMR best practices
PMR expectation handling
PMR closure – what’s next
PMR – the team approach – guidelines / expectations to be set
PMR – gaining confidence ( Approach to identify issue and options available )
Practices to be implemented
PMR – lets speak about it ( PMR team discussion sessions – every fortnight )
PMR – closure evaluation ( before every PMR closure )
PMR – escalation management
PMR – hot ticket tracking ( Lead and manager activation and engagement )
NSI – Positive action planning ( during +18 days of PMR lifecycle )
PMR – extra eyes ( Mentoring / Shadowing and tech guidance )
Evaluations to be done
PMR – S1 survey assurance ( Design thinking approach )
NSI – explore concerns ( Design thinking approach )
PMR – evaluate templates used
L2 – soft skill evaluation
L2 – adequate performance based recognitions on a regular basis.
L2 – Survey questioner evaluation by team ( Discuss and provide feedback to new survey team )
L2 – Keep survey data transparent to engineer and allow access to survey DB
L2 – Survey follow up with likeable clients
L2 Management – relative backlog index
L2 Management – Bad Survey exemption

4. © 2013 International Business Machines Corporation 4Internal Use Only
PMR – First thing first
1.Understand the Problem and the severity of the Issue from your view Point
2.Call the client for all the PMR contacts who prefer phone contact. For the ones who do not
prefer the phone contact, rephrase the issue as per your understanding and get a confirmation
on the same. Ask for clear Business Impact and Deadline.
3.Make first contact with the customer as soon the PMR is assigned. If customer working on our
time zone and OK with phone call just pick up the phone and talk to them. This gives good
impression that their issue is getting attention. Also use this opportunity to get to know the env
TEST/DEV/PROD and criticality of the issue
4.Make sure to ask questions if you are unsure about the problem description, diagnostic plan,
next steps or expectations. This is your opportunity to quickly ramp up on the issue so that you
can effectively and efficiently engage with the customer.
5.Redefine the problem statement clearly and confirm the same with the client. ( verbally or by
mail )
6.Raise / Change the severity if you feel it qualifies as a S2 than an S3.
7.Skills on the product : before you call the client and start discussing with client ensure you
have gone through the required topic documentation. This is to ensure the client does not feel
we do not know anything on that topic.
8.Set expectation on follow up timelines and reason it out
9.If the data provided was insufficient, explain why it was insufficient. If you need more data
explain what you need, why you need it and what you expect to learn from it. Also make sure
the client is clear on how to collect the data to avoid the potential for misunderstanding or
incomplete data collections
10.Keep pmrs up to date and clearly document your work. (If it’s not documented it didn’t
happen!)
11.Make contact on contact required PMRs and secondaries. Do not just close them

5. © 2013 International Business Machines Corporation 5Internal Use Only
PMR – First thing first
•Collect maximum information needed to troubleshoot in the beginning itself. Use Must Gathers.
Amend them as needed at times. Use that option to find new Must Gather topics as well as that
will help going forward and will help to resolve issues much faster.
•If customer is expecting an answer immediately for their question but not sure on the answer
THEN will just reply that you are working on it will get back to them soon. It would be good to
provide timeline here so we set the expectation correctly. Always provide a timeline
•Never tell customers that we are working on other priority issues.
•Thank customer on every conversation. Get to know if they are happy and their issues are
resolved.

6. © 2013 International Business Machines Corporation 6Internal Use Only
PMR – progress tracking
•Prompt and regular update to the clients : Customer Its important for the client to know the Support Engineer is
doing everything he/she can do to resolve their issue. So let client know what you are doing on the PMR.
• For ex: Testing in house, facing an error at a different step. Working on fixing it. Will let you know
once am able to reproduce the issue.
•Live Meetings : Utilize this to the maximum as it saves a lot of time. This does help build a very good rapport
with the client.
•Name a Client Focal for More than 2 PMRs from the same client. The client Focals to have a biweekly meeting
with the client and the Engineers working on it.
•A focal to Monitor the PMR Quality - PMR description, Business Impact, Deadlines, severity, AT/AP, Follow ups
done and provide feedback to the Engineer on what can make the PMR progress faster.
•Move to the new IBM PMR assignment tool and sunset current calendar tool
•Agile / Scrum process of Two Sprints to be used to track progress
• Sprint A. ( Sev 2 focus )
• Two Sprints in the week each of 2 days ( Mon – Wed / Wed – Fri )
• Starts on Monday of the week – Standup 1 – Monday’s 11:30 AM
• Covers all active S2
• Second Sprint Wednesday – Standup 2 – Wednesday 11:30 AM
• Sprint B ( Sev 3 /4 focus )
• One sprint a week - Standup on Tuesday – 2:30 PM

7. © 2013 International Business Machines Corporation 7Internal Use Only
PMR – the team approach and expectations
• Treat each other with respect / Extend common courtesy
• If you need to work from home send a note to the team for awareness
• Arrange for monitor/offshift coverage when you are unable to cover your assigned shift
• Use vacation planner, training, vacations etc on the ibmldap calendar.
• Send out a reminder note to the team before being out and arrange for pmr coverage for any hot issues
• Speak up if you need a skip in rotation
• If your work schedule/availability is impacted because of personal issues, make sure there is some level of team awareness so that others do not make
incorrect assumptions (Only share what you are comfortable with, no need to go into full details)
• Avoid making assumptions. If you are unclear or concerned about something talk to the person directly and then if necessary involve a lead or
manager.
• We are not expected to know everything that is why we are on teams. We are here to help each other.
• Collaborate / escalate as needed but make sure to perform initial triage (What / Where / When / Extent)
• What = Problem Description (What are we trying to solve?)
• Where = Location of the problem, which applications are impacted. (Where is the problem occurring?)
• When = Frequency of the issue (When does the problem occur? Is it consistent or intermittent? What changes recently occurred? Is this a new
or existing environment/configuration?)
• Extent = Business Impact (What is the extent of the issue?)
• When asking for help make sure to provide the pmr # so that people can record psar time for the assist.
• Most problems reported are not new issues, Swarm for inputs
• Regular KM session rather than on need basis

8. © 2013 International Business Machines Corporation 8Internal Use Only
PMR – positive action planning ( post 18 days of PMR cycle )
Objectives
•Provide an opportunity to verify if the PMR is handled according to customer expectation, manage the
discrepancy from both parties and confirm customer is very satisfied with our support service before any
possible survey.
•Encourage customer to participate in survey for all PMRs to reduce the impact of individual low NSI score
when customer is not satisfy.
•Client Handling checklist to be used during evaluation
•Manager reached out to the client before closure or during point of evaluation to
understand what can be done
•Steps to outlined if client is not reachable on phone

9. © 2013 International Business Machines Corporation 9Internal Use Only
PMR – Closure evaluation
Objectives
•Evaluate NSI risk before PMR closure.
•Reachout to the client to understand and evaluate how the situation can be harnessed
•Use closure template ( needs to be reviewed and revised )
•Have a call with the client where
• Brief summary of the PMR + approach to resolve is given
• Ask if there is other aspect that we can help them with
• Enquire about the current implementation and how IBM Support can add value
• Close on a positive note
•Closure case study approach
The following checklist should be used to help with the decision of accepting an NSI request or not / it can be also used to identify
PMR that can be closed in no-survey queue :
•The problem is very infrequent such that it would rarely be seen by customers e.g. it was only seen once by System Test, or it is
only recreate-able 1 out of 100 runs.
•There is a work around to the problem that is clearly documented in the User Guides shipped with the product.
•The actions necessary to recreate the problem are very obscure and it is very unlikely to occur within a customer scenario.
•The problem is environment specific e.g. it can only be seen on a particular piece of hardware or the customer environment
which is a multi tenant hit to other enterprise s/w
•The problem exists in all previous versions of Java / third party s/w - which already out in the field and has not been reported by a
customer.
•If product is a amalgamation of various third party components then the customer impact area should be considered.
•The problem is not a regression from the previous release and is considered to be low impact and unlikely that a customer will
encounter it. ( known issue but unlikely to occur )
•The fix to the problem is considered to be far too risky to disturb the codebase at this late stage in the project schedule and there
is an action plan in place to fix it in the next release. If a customer were to encounter the problem in the field then we would at
least have a fix 'ready to go'. In some circumstances where the fix may be required by an IBM Product group then it may be made
available by way of a post release ifix.

10. © 2013 International Business Machines Corporation 9Internal Use Only
PMR – Closure evaluation
Objectives
•Evaluate NSI risk before PMR closure.
•Reachout to the client to understand and evaluate how the situation can be harnessed
•Use closure template ( needs to be reviewed and revised )
•Have a call with the client where
• Brief summary of the PMR + approach to resolve is given
• Ask if there is other aspect that we can help them with
• Enquire about the current implementation and how IBM Support can add value
• Close on a positive note
•Closure case study approach
The following checklist should be used to help with the decision of accepting an NSI request or not / it can be also used to identify
PMR that can be closed in no-survey queue :
•The problem is very infrequent such that it would rarely be seen by customers e.g. it was only seen once by System Test, or it is
only recreate-able 1 out of 100 runs.
•There is a work around to the problem that is clearly documented in the User Guides shipped with the product.
•The actions necessary to recreate the problem are very obscure and it is very unlikely to occur within a customer scenario.
•The problem is environment specific e.g. it can only be seen on a particular piece of hardware or the customer environment
which is a multi tenant hit to other enterprise s/w
•The problem exists in all previous versions of Java / third party s/w - which already out in the field and has not been reported by a
customer.
•If product is a amalgamation of various third party components then the customer impact area should be considered.
•The problem is not a regression from the previous release and is considered to be low impact and unlikely that a customer will
encounter it. ( known issue but unlikely to occur )
•The fix to the problem is considered to be far too risky to disturb the codebase at this late stage in the project schedule and there
is an action plan in place to fix it in the next release. If a customer were to encounter the problem in the field then we would at
least have a fix 'ready to go'. In some circumstances where the fix may be required by an IBM Product group then it may be made
available by way of a post release ifix.