there are a few ways to think about helpdesk capacity management, the most common approach is to do some magic to forecast the inbound flow of calls and then to apply some constant transaction efficiency assumptions to determine appropriate shift schedules. the outsourcing organization buys straight headcount or monthly hours, and the service provider makes people available to satisfy that requirement. the impact of planning errors are borne by the agents and ultimately by the end users.
the outsourcing organization can do a better job of controlling its costs if it buys transactions in tiers, and then drills into the origin of each call with the intention of preventing future calls. the service provider could then charge a base rate for volumes under the daily threshhold, and a higher rate (with best effort service levels) for everything above that level.
ultimately, a mechanism that self-regulates the demand coming from the outsourcing organization gives the managed service provider an opportunity to factor in some development time for the agents. the relationship should allow them to deliver a quality service and to advance their individual careers.
availability requirements usually change depending on the weekly, monthly or annual cycle. we notice this because most everyone does maintenance on saturday night, stuff needs to be greased and the filters need to be cleaned. its also a good time to do a few upgrades. don’t include this time in the service level calculation!
it might be possible to offer a piece of the standard service during the maintenance window, perhaps supporting the client’s original vision of overall availability, while encouraging the client to remember that maintenance is a good thing.
training for the service desk is an example of maintenance that has to happen and it favors the client. we can reduce production capacity temporarily for the benefit of the client, service provider, and the agent. the idea is to make the risk of missed service levels low.
the math discourages people from calculating availability all the way out to the end user. it seems impractical to insist that all the components in the chain support an end result of 95+%.
being careful about change scheduling and understanding the cycle of business critical transactions are ways to raise the probability of raising the effective availability of the service.
constant dialog drives supplier performance.
document supplier engagement procedures: selection guidelines, relationship management guidelines, protocols for communication, reviews, and re-negotiation.
define the OLA and reporting protocol.
define supplier support interfaces: Level 1/2/3 support with committed service levels to the supplier. methods of submitting change/enhancement requests. escalation methods.
periodic formal review based on the terms of the OLA. corrective action can come in the form of an agreed action plan or renegotiated roles and responsibilities. include a review of the supplier support interfaces.
a new release, as a collection of enhancements or bug fixes, is expected to improve overall functionality and service effectiveness. change managers and release planners should be able to anticipate any negative effects, but the communication about those issues to end users or the helpdesk usually does not happen.
at minimum, problem managers need a heads-up to give them a chance to write some sort of release note to give the helpdesk a hint as to the expected impact.
Level 3 agents who actually share Level 1 duties have a realistic view of the morale of Level 1 and the effectiveness of the knowledge db. Organizations that rely on the creativity of Level 1 engineers have a big problem with respect to recruitment and retention, constant problem solving is frustrating if the organization has an ineffective feedback loop into the services development process.
The support organization should have a strategy for content development and maintenance of the KDB. Level 3 can provide a realistic assessment of KDB effectiveness and is in a position to close gaps.
csat is positively correlated to active end user support by Level 3. If these guys view themselves as mentors to Level 1, feeling some sense of ownership to Level 1 overall performance, solutions are higher quality and re-work rates drop in a major way.
on the other hand, if Level 3 is viewed as an out by Level 1, agents and supervisors are missing the point.
(http://www.historyofpia.com/tails.htm)
the real KPIs are business transactions/hour, not available disc space.
end user exceptions per hour, not network utilization.
top 5 Level 3 support activities
- taking Level 1 support requests to stay current
- evaluating tickets to mentor Level 1 agents
- evaluating tickets to tune the KDB
- evaluating category trends for service improvement requests
- building proactive end user communications content
many agents are actively working toward their degrees and have a self-defined window of opportunity to work in a contact center. the number one objective is to pull in some coin leveraging existing skills. the service provider merely provides the medium to support the agent’s advance through the educational program; the attrition is expected and largely unavoidable.
the service provider can use this relationship to forecast future possibilities for these agents. perhaps as a Level 3 engineer or as a supervisor. expressed interest in evaluating these options should result in improved current performance and also fill a pipeline for future needs.