Service Level versus Occupancy, And Ironclad Relationship

Let’s talk graphs.  I received my first big promotion when I was working for Northwest Airlines after I drew my first sensitivity analyses graphs- those graphs became the basis for all of the cool analysis graphs that CenterBridge provides.  Each one has cool interpretations.

Service Level versus Occupancy is one of the most confused pieces of analyses that we see.  It represents the ironclad relationship between the amount of time an agent will spend working a contact, compared to the time he will spend waiting for a contact to arrive.

Clearly, if you want the phone answered more quickly, then there needs to be more agents potentially available to pounce on the call.  Hence, as service level increases, then the amount of time- on average- that an agent spends waiting for the next call also increases, and occupancy decreases.  Simple, yes?

And so you get a graph that looks like the one above.

Note one thing:  the relationship between service level and occupancy will be different for each contact center- customer patience and economies of scale play into these graphs a lot, and those vary by contact type.

Now the dangerous part.   For the call center described above, an 80% service level results in a 68% occupancy. That is ironclad; it is an unbreakable law of math.  But what it doesn’t mean is that agents who work an 8 hour day have 32% of their time available to do other things!  It means that there may be a 30 or so seconds between calls, before the next one comes in.  It also doesn’t mean you can get rid of 32% of the workforce.

 

Business Travel with Caroline

Speaking of Caroline, I took her on a business trip to Utah (where her cousins live), How cool was that!

While she was excited to go on a trip, I think I was more so.  My kid brother lives in a beautiful spot in Park City, Utah, and works for a very cool company, with a very impressive job. I am horribly proud of him.

I stretched the trip (which was an excellent meeting) into the weekend and did a couple snowy things with Carrie and my nieces.  I really should do more of that!

“It’s not whether you get knocked down; it’s whether you get back up.” -Vince Lombardi

I’ve started coaching my 8 year old daughter, Carrie’s, basketball team.  It is so fun.  Coaching girls is very different from coaching boys, however my Caroline is a jock.  A tiny jock. She is very coordinated and athletic, and can run forever. Quickly.

Yesterday, we ran a simple basketball drill.  The girls paired off, faced each other and shuffled side to side while passing a ball to each other.  Sure enough, Carrie missed the pass and got hit in the nose.  That hurts.

But what do you do as dad/coach?  If it was my son, I would growl at him and say “Shake it off”.  But my little girl?

I did just that.

But while I was ignoring Carrie, two other girls on our team got bumped in the nose and started crying.  We ended the drill as too dangerous.

“Don’t make good the enemy of perfect”

There is a saying that goes something like: “Don’t make good the enemy of perfect”.  What this means is that if something is not exactly right, it should not necessarily be discounted  because it may be way better than the status quo.

A long time ago, I was presenting an ROI for a project I was working on.  While presenting, we showed an honest to goodness, conservative improvement to the operation of 7 million dollars.  The client told me that since the system (not CenterBridge) took 12 minutes to calculate the optimal answer (which only was a small part of the analyst’s time in the system), they were considering turning the system off.

Dan Mahon says I have business Tourette’s.  My response to this person was “How much is your time worth?”

Would it be perfect that the optimizer returned a response in 5 seconds? Yes. Is it pretty darned good that it saves the company 7 million dollars a year even though the algorithms solved in 12 minutes? Of course it is. Don’t make good the enemy of perfect.

Update: CASy system and John Magliocca

A few posts back I discussed our CASy system, developed at USAir with a gentleman named John Magliocca (great guy).  I have not spoken to John in 15 years.  Since the post, a few weeks ago, I have spoken to five people who knew John.  Two times I met with former USAir folks, and one time when on the phone with a customer service rep. The net-net is that all of them seemed to think the world of him, like I did.

So, if somehow you trip upon this blog, John, realize that you’ve had a decent impact on the folks around you.

Service Level Consistency

The idea being that executives should push for service consistency across intervals was one of the catchwords in our industry a couple years ago.

We began hearing of goals like “We want  90% of all intervals to have service levels greater than 80% within 20 seconds.”  I may sound foolish here, but I don’t get this thinking.

In my humble opinion (Ric humble!?! HaHa), I would think that if you correctly measure service level as being across all of your customers, 80% of all customers being answered in 20 seconds or less should be good enough.

My guess as to why this concept got some traction is that maybe the way daily service was reported may have been wrong.  Instead of volume-weighting service level across the day (service level as a percent of customers), service level may be interval-weighted in some reports (service level average across the hours, say). If you add up the service level of all of your intervals and divide by the number of intervals, then you are weighting your busiest period the same as you least busiest period, and that is likely a mistake.

In other words, service level reporting had a mistake in it, and so we had to create a new service discipline around our reports.  That’s the only thing I can come up with to make sense of this other metric. But I can’t really get my arms around it.  Please explain?

One thing we talk about during sales calls and during webinars is a different concept of service consistency.   But we mean this in a very different way: we mean that we will make sure you have the exact right number of people available each week so that week over week- through all the seasonality- we maintain our service with little stress to the operation.

The idea being that the seasonality of all sorts of metrics: handle times, volumes, sick time, attrition, etc… make the development of week over week plans difficult.  If you do that well, like CenterBridge does, then you will have service consistency.

CASy- A Fun Project with Surprise Returns.

I think that I’ve mentioned before that early in my career I had some very cool jobs.  Throughout my career, I was tasked with finding ways to improve the efficiency and effectiveness of diverse operations within all of the companies I worked for using a discipline called operations research.

Man, I had some great projects (and during this time CenterBridge was first born at USAir).

But, thinking back, my favorite project was building a call routing system at USAir back in 1993.

The director of call center workforce was an extremely smart guy named John Magliocca. I learned so much from him, and as a newer analyst, really looked up to him.  In those days I was a super-nerd (“those days?”… Please stop laughing), and I expect that John had to exhibit a fair amount of patience in dealing with me.

But he had a list of things he would like to improve at their call centers, and I hope I was able to help.

In their network control room, they had a call routing system from AT&T that allowed the network folks in John’s department to manually change the percentage of calls that were routed to each of their seven call centers.  If one center was overworked, the network control manager would change the percentage of calls going to that center and hope they could smooth out the future center performance.

Needless to say, it was a complicated problem being handled by gut feel and experience.

John mentioned that he would love to automate that process and pointed out something pretty fun:  the computer that controlled the call routing interface was sitting on one end of a long table, and on the other end of the table was a computer that housed their TCS workforce management system.  He said that he would like to have a machine that sat in between those two systems and would allow them to communicate in some fashion.  Since the workforce management system knew the projected number of calls, the projected handle times, and the projected number of employees at each location, it should be simple to figure out the percentage of calls each site should get before there were problems. Right?

Well it was. Except that there was no budget for such a project.

We all believed in the benefits of the project, but the budget was the budget and we would officially have to wait until the end of year to start the project. But unofficially, a buddy of mine, James Hengst, and I decided to go ahead and develop the project anyway.

We found an old 286 PC in storage in a closet and decided to write software that would view the workforce management resource plan by center, for the next 15 minute interval, and convert it into the percentage of calls that would allow a balancing of average speed of answer across the seven centers using a guess and test algorithm. The PC would call up the AT&T machine and change those percentages automatically.  It was very slick, and after playing with it for about 4 weeks, it went live.  We called it CASy, for Call Allocation System.

It was not a huge success, because nobody noticed anything, except for the guys in the control room who no longer had to manually smooth things out throughout the day.  Everyone else just kept doing their jobs.

We told our bosses about how cool CASy was, and they all said, in effect, “good job, I guess”.  Because we rushed into the project, we weren’t able to set up any test to determine the ROI of CASy.  But we felt good, because we thought we helped out John and his team.

And then a miracle happened.

A few months after implementation, the old 286’s hard drive failed. And with it, down came our CASy. They immediately had to go back to their manual process of allocating calls, and in the weeks we spent getting a new laptop and re-implementing CASy, an apples to apples, with and without CASy data set was produced.

The amount of abandoned calls at USAir’s reservation center was greatly improved by CASy. By smoothing out performance across the seven centers, the differential abandon rates were minimized and many fewer calls actually abandoned in total.  Given the high volumes, the high value per reservation call, and the low cost of implementing CASy, the payback of our little project turned out to be 3.4 days.

That was a fun project!

The End of the Season

Our football season ended. I am so depressed.

In our playoff game, my boys came back from a 12-0 deficit at halftime to tie the score. We were marching downfield for the win when the clock ran out sending the game to overtime.  We lost there.

But I have to tell you, it was a great game, the boys played SO WELL, and put their heart into the game. I couldn’t be prouder.

Some fun things happened this season.  In years past, our team got along and worked hard and the rest, but this year was the first year where I felt the boys all liked each other and played for each other.  We had four goals:  1) Work hard (they did), 2) Beat our rival (we did!), 3) Protect each other (check), and Championship (sadly we did not).  Goal three was interesting, in that I feel that it truly became a mission of the team to look out for each other.

Here’s another interesting thing about the season.  This seems to be the season that leadership truly took hold among the team.  When you watch game film, you’ll see the boys really pump each other up. At halftime, one of my players gave a speech. How cool is that??

What a great group of young men. Next year they will be leaving for high school, and boy will I miss them!

The last game is here (good guys wearing red): 

Club Length

Duke Witte, the famed workforce management guru from Wyndham Hotels, has this cool concept that he calls “Club Length”. The idea is to always maintain a staffing level equal to the expected requirement plus or minus the amount of overtime or undertime he expects he can achieve.

He doesn’t worry so much about hitting the requirement exactly, but he wants to make sure that he has enough staff, throughout his operation’s peaks and valleys that he can respond with his real time team with overtime and undertime.

I’ve learned a lot from Duke, and he helped us develop the first version of CenterBridge.

What service should we offer customers?

Seems like a pretty straight forward question, right?    It would be, if service were free.  But service is not free.

At each service level goal, there is an implied cost.  And lowering cost is another of those goals.  So our two goals are: lower costs and provide service.  But those aren’t the only two goals! We also don’t want to burn out our agents with too high an occupancy, we want to provide training and professional growth for our employees, we want to sell product (for sales or collections centers), and so on…

A simple trade-off sensitivity curve, cost versus service level is below.

How we answer questions with competing objectives can be tricky, but what is certain is that the analyses required to make such trade-offs explicit is a longer term model of the contact enter network. The analyst needs to be able to determine cost, service, occupancy, training, overtime, and a bunch of other important metrics associated with any planning scenario.  If you know the value of these metrics for a scenario, you can determine the trade-offs associated with competing scenarios.

By using your strategic planning system, you can find the answers to our multi-objective operation.