seat58F
outsourcing relationships: international, inter-economic, interpersonal
September 7, 2010 ~ 03:40:48 AM * -07:00ST
IVR ergonomics
Post # 159 by
rc on March 31st, 2009 ~ 11:25:56 AM
Posted as csat |
No Comments »
start with the assumption that inbound callers are frustrated by the IVR and try to limit that exposure to negative cu-sat. abandonment rates give a general idea of call routing effectiveness; usually this metric does not include early termination while the caller is interacting with the IVR. get your voice people to gather and report these disconnect numbers.
the quality people can also monitor IVR sessions. callers tend to talk to the IVR even though its a keypad UI. monitoring the call at this point yields interesting insights into the perception of the service provider and/or the supported products.
as always, be aware of privacy concerns when recording these sessions.
transaction monitoring
Post # 154 by
rc on March 30th, 2009 ~ 03:24:58 PM
Posted as transactions |
No Comments »
agents who fail transaction monitoring are normally re-trained, but the monitoring frequency should be increased for several cycles to ensure that the new awareness has really registered.
they can potentially fail in several areas: content accuracy, delivery execution, packaging, or tools usage. delivering the wrong content isn’t helpful, but neither is developing the right content and delivering it ineffectively.
workers with attitude
Post # 129 by
rc on March 27th, 2009 ~ 05:35:42 AM
Posted as hr |
No Comments »
outsourcers do have a stake in workgroup morale;
a SLO would be really nice, but like the elusive ” cu-sat “, it would be a statistical swamp. better to examine the service provider’s HR policies and practices.
obviously, what are the salary and benefit benchmarks?
not so obviously, what investments promote delivery effectiveness; what are the retention strategies?
pre-employment screening (background checks) are common practice, but agency agreements don’t enable ongoing evaluation of agent attitude. the outsourcer really wants to be aware of this trend to limit information continuity risk. in this way, retention metrics may actually be counter-productive.
how disgruntled are they?
Post # 124 by
rc on March 26th, 2009 ~ 11:47:34 AM
Posted as continuity, hr, metrics |
No Comments »
a pissed off workforce adds momentum to outsourcing discussions. awareness that employee attitude can influence information continuity issues moves executive team”discussions” into “negotiations” and some of the exposure is ultimately reduced.
two simple process areas bubble to the top of information continuity risk management: access control maintenance and separation of duties.
access control is not complete unless there is ongoing maintenance. the composition of outsourced workgroups is constantly changing; access to specific applications needs to be revoked if the agent’s role changes. KPIs? how about list review completion (%) by individual supervisors?
separation of duties is important in the application services space - developers should never have access to production systems.
a third, rarely seen, approach is to limit the access windows to certain assets. we think we are in an always-on world, but there are still many functions that only need to be executed at certain times.
infrastructure health check
Post # 120 by
rc on March 24th, 2009 ~ 10:14:31 PM
Posted as executive team |
No Comments »
what are the strongest indicators of a healthy service delivery infrastructure?
the business justification; its here somewhere
Post # 116 by
rc on March 23rd, 2009 ~ 01:14:38 PM
Posted as config |
No Comments »
ITIL insists that each infrastructure element have an identified “owner”, and perhaps its a good thing that procurement can go to someone when its time to discuss hardware support contract options. but we are really missing the formality of an application owner who understands not only the CI’s necessary to convey and crunch the transactions but also can dig out the original business justification for the app.
CIOs get hung up on app transformation with an expectation that many boxes will ultimately be turned off. Having the original business justification gives a different perspective on the app and its multiple components. Often, features that supported the original vision of the app have become obsolete as strategy, business partners, and technology changes. Dusting off the original business justfication can provide some easy cost savings suggestions and reminders.
just ask for it
Post # 112 by
rc on March 20th, 2009 ~ 11:08:37 AM
Posted as contracts, metrics, r&d |
No Comments »
“continuous improvement” clauses continue to get people crazy. there is never agreement on what kind of progress is expected or how to measure it.
I’m amazed that clients don’t require that some level of R&D spend be directly assigned to their delivery team. R&D can happen in the local environment to do some workgroup and/or process optimization or it can happen back at HQ as long as the delivery manager has some insight into the pipeline and a plan to integrate specific deliverables as they become available.
continuous improvement won’t happen without some focused effort; given appropriate visibility, clients can easily extrapolate specific efforts into client-perspective cost or performance improvements. all they have to do is insist on being part of that conversation.
gauge lab redux
Post # 77 by
rc on March 19th, 2009 ~ 12:09:26 PM
Posted as change, metrics |
No Comments »
we had gauge labs that housed all of the instruments used to verify inbound parts and to check tolerances during manufacturing. it was somewhat uncomfortable going to ask for an instrument because it meant interrupting a tech fine-tuning an instrument or replacing a component based on a calibration or maintenance schedule. calibration strickers recorded status.
The simple objective was to ensure valid results from measuring equipment. To do this calibration was performed and tracked. The instruments were protected against improper adjustment (the lab was restricted access) and protected against damage (transit cases and carts were used to move them to the mfg floor).
today, service levels drive much of the conversation with the client. the client is focused on *interpretation* of the numbers and, for whatever reason, we loose awareness of the tool configuration details that essentially represent changes in “calibration”. over time, the significance of the collected data can easily change if the service provider changes how the data is collected.
most frequently, data is skewed by changes in workgroups as new people come in with perhaps different language skills; common terms can be interpreted in many ways. the source of data can also change over time. the most pernicious examples occur when service mgmt tool throttles are adjusted to “drop” transactions that do not meet certain criteria. These actions should transit a transparent Change Mgmt process, but normally, they don’t.
red days
Post # 101 by
rc on March 18th, 2009 ~ 08:23:58 AM
Posted as change, config |
No Comments »
red days are designated “hands off the infrastructure”; no changes allowed. delivery teams need to have a feel for application activity throughout the month and quarter. It would help if the service managers had a solid understanding of all infrastructure elements (and suppliers) required to complete transactions.
even emergency changes need to be handled with extra care during these periods. impact assessment, implementation and test planning should be more formal than normal.
make HR work
Post # 72 by
rc on March 17th, 2009 ~ 06:17:56 AM
Posted as hr |
No Comments »
The average support agent stays on a desk for about 18 months. By that time, they usually know the client very well and they deliver effective solutions. They are tapped out for future growth on the desk, so you are planning to further develop that resource, or, maybe not. One way or another, you have to continue loading the development pipeline with new talent, and the most effective way of doing this is to involve (wait for it….) HR.
1) define competence levels: ensure HR understands the entry criteria for a new agent. Language skills, available work schedule, education are starting points.
2) provide training to meet minimum delivery skill levels: develop expertise in supported services and technologies.
3) evaluate training results: don’t put agents on the desk who can’t meet the minimum. The client will not be impressed, the agent will not be motivated to stay on the job.
4) align employees to quality objectives: supervisors need to read tickets and monitor queues.
5) maintain skills and training records: refresh training in a group setting gets agents to share solution strategies.
