As performance engineers, we’re all focused on improving the
responsiveness (throughput/response time) and scalability of the application in
hand and hold a bucket full of tuning tricks to use at the right time. Do we
really know what the users of the application feel about using the new system
or does it meet the business requirements–well, we know about workload modeling
for an application, would that be sufficient to achieve the business goal.
These are some of the questions that we can definitely answer when we spend
quality time with the user or be in user’s shoes.
As a performance consultant at one of our healthcare payor
clients’ legacy modernization project, I wanted to understand the Customer
Service Representative’s (CSR) perspective of the new application that has been
rolled out. As in any typical legacy modernization project, members in the
system are migrated in phases and the CSR’s get to use the old as well as the
new* system at the same time. In the recent past, there has been anxiety on the
IT side of the organization about the additional membership migrations planned
in addition to the existing perception about the poor performance of the new
system. To understand the problem first hand, I managed to secure some
chair-side time at the call center and that was revealing
·
CSR’s do not use just the legacy and the modern
application, but a host of 10 different applications and yes, there’s lot of
opportunity for automation and usability engineering.
·
I also noticed approximately, 70% of the call handling
time was spent on an application (letter server) that was not on the radar for
the performance team.
3 hours spent at the call center also told me that the
application that’s getting migrated was not as bad as it sounded
But wait. While I was looking for SPE (Software Performance
Engineering) opportunities, I was also listening to the content of the calls
and taking active notes. Mining through the notes at the end of the day
provided me cues to more fundamental problems- one of the CSR’s was able to
manage about 10 calls in 40 minutes and the 11th call lasted for about
30 minutes due to the very nature of the call and the caller. Pareto’s rule
directs us to focus on the 11th call but a cursory look at the first
10 calls also signals an opportunity, all the 10 calls were inquiry calls about
various services.
Here’s a rough listing of the calls and its content:
Enrollment
|
Billing
|
Claims
|
Post Sales Service
|
|
Inquiry calls
|
Can you confirm that my application has been accepted and
I have coverage
|
Can you provide me the status of a claim
|
Can you send me a proof of coverage for the year 2012 to
my new address
|
|
Non-inquiry calls
|
I am calling to make a payment for my dental plan as I am
not able to pay online and the website says that the membership ID is invalid
|
I received a mail stating that my claim for my visit to
the chiropractor has been denied.
I have been receiving mails from your company about claims
denial, I am not even a member in any of your plans
|
||
Probable causes (Detailed
analysis required)
|
No active communication with customers regarding coverage
start date
|
Incomplete website with no provisioning to pay for dental
plans
Unclear or inconsistent communication
|
No active communication on the claim status.
Unclear and Incomplete communication about claim
processing
|
As we would all agree about improving the call handling time
of the 11th call via automation, application responsiveness,
usability engineering and other techniques, we also see an opportunity to
eliminate the first 10 calls and fix the underlying service problems- a true value
to the business- a case where non-functional requirements driving functional
requirement?
