The Elephant in the Queue - Reducing Backlog with Efficiency
Backlogs aren’t just a nuisance; they’re a threat to customer satisfaction. This session will confront the issue head-on, revealing how SupportLogic’s efficiency tools can drastically reduce your backlog. You’ll learn why tackling this “elephant in the queue” is critical to maintaining a high-performance support operation, and how a more efficient process can free your team to focus on what matters most.
You Might Also Like
>> My name is Francois. I'm the owner of FTWorks. And I am joined here by --
>> So I'm Chris Ramero. I'm director of services and
Support with Nice or Nice CX1. >> And i'm rob hart. We've got a solution
Architect that's been about two and a half years and I'll show you
What the cool stuff we have here. >> So the way this is going to work is i
Will start by saying a few theoretical things about backlog management.
And then we'll start hearing chris's story and in the middle rob is
Going to do a demo. >> You got it. >> Can we have the first slide, please?
A second slide. And again. All right. So let's start with the
Obvious. What is case backlog? So case backlog is just --
Open cases. All of them. And as we can see, there's plenty of
Things in the backlog that are perfectly fine and should be there, like
Brand new cases, for example. Cases we're working on, cases where we
Waiting on somebody else, waiting on the customer, waiting on rnd, waiting on
product --
Product -- the product team, right? So backlog is fine, except when it's not.
Next slide. So when there's too much back log, when there's
Back log that's too old, then we start to have problems.
And all of the speakers we heard today said a lot of interesting things about
This, like it has bad effects on customers.
It's going to take a longer time to resolve cases.
Customers don't like that, so they will escalate. And if they escalate, they
Probably won't be too happy. So those are customer effects.
And then there are effects on us, vendors. And i would like to just highlight
the First one on the list here, which is this mental load idea.
My company does a lot of work with training support engineers on
Communication skills with their customers. And i always take a poll.
How many cases do you have in your queue? And i've noticed over time that if
the Answer is ten or fewer, people are fine. If the answer is 20, 25, 30 or more,
then People are very distressed. They feel it's almost impossible for them to do
their Job, etc. So this mental load i think is pretty important and maybe not
Embraced enough by us managers. Second idea is the firefighting overhead.
We heard from one speaker earlier today that it gave back an hour of time to
Their managers. Do you hear that one? So certainly,
Firefighting is very costly. And of course churn is very costly.
So where does backlog come from? i call it the three p's.
Process people product. So let's start about people.
People is everything that has to do with the individual who actually owns the
Case. And it could be a training issue often.
So they don't have enough technical skills. They do not have troubleshooting
Skills. These two things are different.
I can know a lot about the product but not be very good at troubleshooting and
They can not have very good queue management skills.
Which is also something that could be taught.
And then there's more psychological stuff.
Like i don't know how to say no to customers.
If you've ever been in that situation, you know that by not saying no, then my
One question becomes 12 questions and 13 questions and 14 questions and
Pretty soon i can never close my case. So that's a problem.
And other psychological problem is i'm too proud or i'm too scared to ask for
Help. There is help available but i'm going to
Remain stuck in my case because i can't quite get out of my little world.
So those are people issues. The process issues to me are organizational
Issues so it's one level up. So they are things like i'm not staffed properly.
I don't just mean i don't have enough people but maybe i don't schedule them
Properly. So there's a staffing issue.
Second problem would be anything that has to do with
Collaboration processes. So earlier we talked about the individual
Case owner being afraid of asking or too proud to ask but maybe there is nobody
To ask. That's a problem.
And then finally i see certainly some of my clients not really having a
Backload management problem. They think that somehow it's going to work.
And hope is not a strategy as we know.
On the product side, what i mean by product is the product of the service that
You support. We all have had experiences where we supported
A product that was very buggy. That's going to create backlog right there.
But it could be other things. It could be the product is
Missold. So the use case of the customer has
Doesn't quite work with the product. And sometimes the product is just hard to
use. So it generates a lot of questions into support.
So that's the diagnostic part of the backlog.
And now here is my idea at least of an ecosystem for backlog management.
So i think if you do all of these things, your backlog will be nice and healthy
I organize this people process product of course.
So on the people side, training, coaching, maybe hiring a different kind of
person. Right? Especially if your product is changing or your customer base is changing
In the process category, there's two columns.
The first column is everything that has to do with the way we actually resolve
issues.
The second column is really about backlog management.
Two slightly different things. So around the product, i'm sorry,
Around the problem resolution. Right?
First idea is are we assigning cases to the right person.
Tally was here a little while back talking to us about automatic assignments.
That's the first issue. Right? If i assign a case to the wrong person,
Then it's going to sit there for a long time. Not good.
Second is knowledge management. Of course, what i call case clinics,
Some people call them scrums. So ways that we can share knowledge throughout
the day.
Right? Together. And then obviously a good swarming process
So that we can collaborate in real time when needs be.
All this is about issue resolution.
The second column is about backlog management issues.
First idea, have resolution targets. There should be an idea within your team
Of how long it should take to resolve a case.
And if i go over that, then i probably need to go get help.
Right? Without stopping.
Do you do individual queue reviews, so manager and support agent together?
Right? Do you do aging case reviews, which is looking at old cases,
And of course, escalation detection. I'm going to use one of chrisis
Term here, which is take the heat out of the back log.
It's okay to have stuff in the back log. That's not very urgent.
But if you have urgent stuff, that's a problem.
On the product side, we're not going to talk about that too much today,
But i wanted to have that in your mind.
Do you have internal service level objectives with whatever organization you
Depend on? Many of us don't. That's a problem.
And then do you have a voice of the customer program so that you can, on a
Strategic level, feedback to your product organization, things that need to be
changed.
All right. So that's all theory.
Let's go to practice. So chris, tell us about where you started from.
Well, i work for a nice company. And we had a problem.
And it had to do with back log. We literally had hundreds of unassigned cases
Sitting in the back log with no engineer assigned.
Poor visibility of case updates, customers calling in and asking if
Their case has been assigned. This kind of waiting game.
Am i with an engineer or am i still in the queue, if you will?
And that's just led to a very poor customer experience.
Like they would get their case and it would finally get to an engineer after
Multiple days. And the engineer would say thanks for
Talking with me today. Are you still having a problem?
What a horrible experience. And then it just led to problems.
And that led to kind of this squeaky wheel mentality.
You know, it's kind of who you know.
Support managers spending most of their time on escalations, preparing,
Reviewing cases. The loudest customer, the loudest
Tam, the loudest sales engineer reaching out into the organization trying to
get Traction on their cases and just struggling to get traction where it was needed
Because everybody just had cases and too many cases to handle.
And then dissatisfaction. We started seeing case and support
Satisfaction showing up in our customer's nps surveys and our c-sats were lower
than
We wanted below targets. And this led to frustration and friction with our
Support organization. All of a sudden they felt like they were the bad guy.
And everybody out in the organization was trying to attack them or tell them
how
To do their job better. If they only could solve these cases faster
Than all of our problems would go away. And that really wasn't the case.
That wasn't the problem. >> Okay. So it was pretty bad.
>> It was rough. >> So you analyzed what was going on.
What did you find? >> We did. We looked at the data.
>> Go ahead and give my next slide. And we said that customer growth was really
Part of our problem. We were understaffed. We had grown customers and
We hadn't grown our support staff. And so we were trying to do more with less,
Effectively. We didn't have a fewer case to
Customer ratio. And that was a problem. And we didn't have this kind of
Line of sight into new budget for -- we were a cost center and that was a
problem. We had expanded into different markets, into brazil and kala, into the uk and
Amia, into australia and apac. And with that expansion came new challenges.
New types of customers with different types of expectations.
Struggling to come to terms with our support organization and really how to be
Successful. It's hard when you want your customers to be trained on how to work
with You. And that's a rough experience. Anytime you do that.
And then we also started selling up markets, selling to bigger and larger
Customers. And these bigger and larger customers had bigger and larger
Expectations taking up more and more time. Wanting to hold on to tickets longer
And we just weren't positioned for that very well.
And struggled to meet those. Talking about the product issue.
We also had knowledge and documentation gaps. We had a lot of --
>> You were the only ones really. >> Great products.
>> Nobody else here has had that. >> And gaps in the knowledge and the
Documentation. All of a sudden product managers say,
Why are customers unhappy? And they're like, well, they don't know how to use
the Product yet. Or they're having a hard time troubleshooting this issue.
And just trying to expose difficulties in that experience.
And of course, software bugs. I mean, it's really the scope of our industry.
Is that software will come and with those software comes bugs.
But just challenging when we're under water in the organization.
And just not able to meet those demands. And then some of these other issues
just Kind of crushing over the top of us, if you will.
>> I'm depressed. All right. So you tried a bunch of stuff.
>> We did. >> And what i love about chris is very
Honest. So he's going to tell us what didn't
Work. There's a long list. >> Yes. So we started out with kind of
A tiered approach. We had level one, level two, level three
Engineers and we thought this is going to help us.
But it was challenging because not every engineer knew everything about
All of these products. And the tier one engineers didn't get better
At handling tier two and tier three cases. It just turned into funnels.
And we wasted a lot of time passing cases around.
We had a quality team doing case reviews.
But that was challenging because the engineers were busy.
They were rushed. They were taking shortcuts.
And so it's hard to really have a disciplined qa team doing great work,
Having great insights when the engineers are just dying on the line.
We adopted knowledge centered support.
Casees, which i love. I'm a casees fan.
And yet when engineers don't have time to write articles and you have a
Very manual casees methodology, you're not going to get a traction of
Deflecting cases or surfacing solutions because everybody's just
Living and dying in their cases. We tried unified search.
I love the xline stuff. I'm very excited about that.
But we started trying to do search.
But with knowledge gaps and challenges and displaying
Kb articles to customers, it wasn't very effective in deflecting
Cases. It wasn't well adopted by engineers.
Because they thought they already knew the answers.
So why did they need to read the knowledge base?
And so we just struggled. We had a leadership change.
Whenever there's trouble, sometimes people at the top turn over.
That wasn't effective in our change either.
They brought a new idea. Didn't quite get there.
We tried case closing parties. We tried unlimited over time.
And ultimately pizza and mountain dew.
We tried to just try anything that would work.
And we just didn't move the needle.
Okay. So let's ask rob to show us a few fun stuff.
And then we'll come back to you and hear about the outcome and
The reason we started.
>> Right. So we're going to leave you waiting for the answer to
Chris's solution. In the meantime, I'm going to show you
Our backlog and how it works and how we've tackled it from
Support logics perspective on how we can use ai, nl, national
NLP and all those things to be able to find and help target
What problems to have. Chris mentioned earlier about --
You can have a backlog. If you have a backlog, you don't
Prioritize the hot topics to urgent issues, then it's really bad.
Because it's like a black hole, I've got a huge backlog of 836
Cases. Which ones need attention?
Which ones don't need attention? Which ones do the customer
Maybe expect it to take a while? Because the customer expects it to
Take a while. That's fine.
It can be in the backlog, maybe it's an engineering issue that
Will take a while and develop to fix it.
The customer is expecting answers ASAP.
Here's a couple ways that we've seen customer build these out
Where they can make the backlog effective.
I think a couple of the ones that i thought would be helpful.
This one can be filtered heavily.
When you create these backlog lists, you can filter very
Many ways. You can do by product one,
Maybe you want to call this.
On top of that, you can filter by anything you have that's
Metadata. These are fields that are in your
CRM right now. They're in cell source,
They're in zendesk and we'll ingest these into support logic.
You can use those as filtering. The example i used before is
Product number 2 or 1. Now i can filter by that one.
Maybe i'm in charge of product one.
I want to see the ones that are in the backlog.
I want to sort it. I can sort of buy lots of things
That are built in here by maybe the oldest case, maybe the
Sentiment count. Maybe if i'm the product manager
And i own the product, i probably want to see the ones that
Probably have the worst sentiment score.
Which one doesn't like the product the most.
Now i can see that this ticket right here, these are zeros
Or sentiment score. These are the ones that if i had to
Pick which ones to tackle first, i would tackle the ones that
Had the lowest sentiment score, the worst sentiment.
That helps a lot. When you look in this list, this is a
Long list. You can spend a lot of time.
Another way example how you use this page is as a support manager
If i've got maybe ten minutes to read now in x-call, what's the
Best when you use ten minutes? i could read 900 cases or 800
Cases or try to read all of them, try to figure out which one
Of the needs by tension and not get it wrong and waste ten minutes.
Or i could look at this list, look at my custom list, rank by
Sentiment count or last inbound, this one here is the last
Message was inbound from the customer 17 hours ago.
Is that something i should be involved in?
As a support manager i should probably open this up, click on it,
Ping my engineer and say hey, this is 17 hours, but they're
Asking for help, can you please help with that.
I can only hit the case summary and get a summary of it and
Really know what's going on with that.
So my time management as a manager, most people mention it
Say support managers like an hour a day in various areas.
This is a big one right here, is be able to bring the best stuff
To the top so that i can spend time effectively and give
Resources to the tickets and cases that need resources.
Another area that i want to touch on that's related to this
Is a little bit of alerting too because you can alert when
Cases hit certain thresholds.
An example i heard yesterday was one of our customers set it up
Where the agent, if the agent owns a ticket, he's assigned to it
And the agent hasn't responded so the last one was inbound 48
Hours ago, right, so the agent gets a response via email,
Slack or teams, right, and then right after that the manager,
Maybe 72 hours, the manager gets alerted.
So if the agent does his job and responds to the customer at a
Certain time, right, it's more like SLA really, but the manager
Gets involved if it's 72 hours now.
So agent's incentive is to make sure he's always responding
Within 72 hours and this is going to be all automated, right,
And you can add on top of this too, like if that's too much
Because you get lots of cases, you can quickly just add
Negativity, right, so if it's negative and this criteria,
Then i want to hear about it, right, so you can really fine
Tune these alerts to not make it noise, but make it actionable
So you can make that work for you there.
Anything else that you should show here, chris, that maybe
Impact to you and how you did that?
I really love the escalation board, the like lead escalate,
That's where we spend a lot of our time.
Yeah, it's like the money page.
It's like the easiest place to find ROI because we're
Predicting escalations. Everyone knows they're expensive, right?
So everyone knows that, and i give the example quite a bit
Where vp, i onboarded a customer, that's what i do a lot of
Onboarding, and the vp asks me, hey i got this email this morning
From an upset customer. Hey rob, did you happen to like
Predict that beforehand? And i was like, look, what's the case
Number? Look at the case number?
Yep, we did. We predicted it a week prior, and the
Support manager could have taken action on that and squashed
The escalation and the vp would have never heard about it.
Right, that's huge, right? vp is time expensive.
You get vp involved and several engineers, that's expensive.
So that alone is like the easy roi for sport logic, and this
Page is probably the favorite page for most customers.
Absolutely. All right, so let's go back to your
Story, chris. Before we listened to rob, you told us
About all the things you tried that did not work.
Yeah, we had problems. I'm assuming things did work.
We did. So we deployed sport logic about a year ago, and this
Is what worked. We reorged the department, or instead of
Around sla, or around --
Tears. Tears, we moved to an organization,
A product organization, a product pillar org.
And this helped, again, specialize agents so that they knew
The knowledge more closely, right? They don't have to know
Everything, they need to be experts in a product pillar.
We designated support engineers for key accounts called
Designated support engineers with dse's.
We recognized in the industry that these larger customers with
Bigger expectations were willing to pay for somebody that they
Could deal with on a repeated basis.
They didn't like this pooled support stuff.
So they actually paid more money.
We reweed, we pooled our support tiers.
They paid more money to get a designated support engineer,
And all of a sudden we started getting some headcount into
The org because the customers were paying for their own
Engineers. That sounds like a profit center.
It does. And then we worked with rnd.
We had this knowledge gap.
We started working and taking some of the swarming opportunities
That were missed. We started training around them.
Let's hold some monthly sessions around specific gaps.
How can we help our engineers be more effective troubleshooting
These things? How can we avoid the swarms back to the rnd team?
And just collaborating more effectively with our engineers
And really helping them feel supported.
We worked a case hygiene process again.
We brought in yet another leader who had this case hygiene
Methodology of let's get back to basics.
Let's get our engineers to write it down in the notes.
You know, let's get a good problem statement.
Let's write down the resolution.
And let's get -- let's call the customer and have a problem.
Let's not just send off another case update.
Let's get on the phone and solve it.
This product pillar helped us organize subject matter experts.
Our tier twos became these product pillar experts who then
Started coordinating some of our SME activities.
They started doing some of our internal swarms and coordinate
With rnd, again helping to drive more knowledge back to the
Organization and allowing that initial engineer to get the
Knowledge to close the case so that they had it next time.
And then lastly, we adopted some measures within rnd about
The product quality standards.
We noticed that the percentage of cases that are in the held
Was maybe too high in the org and they needed to be held
Accountable to how much quality was happening and how many
Bugs were getting released back into the product.
So we worked closely with them to have a better overall
Experience for support helping them be more accountable.
Lastly, technology again.
This is where support logic really played well with us.
We deployed intelligent case assessment.
We started using support logic tools to assign, prioritize
Those cases and signals.
We started working with our managers in escalation
Predictions and preparing, giving them key insights into
Their engineers so that my agent view.
And then we started deploying the alerts that rob mentioned.
Helping them get visibility because we didn't expect them to
Work in support logic all day but sending them priority
Alerts when customers were going to escalate potentially or with
Really negative cases.
And so those all things kind of helped us get a wrangle on
Those customers.
>> Okay.
So let's brag now.
Results.
>> Results.
Okay.
So intelligent case assignment.
We saw 50% reduction in case assignment time.
It went from an average of three days down to one and a half
Days.
That's one and a half days of customer time where the case was
Now getting worked.
Again, a huge benefit to the customer.
We saw a 17% reduction in time spent with the engineer.
So this is the clock starts once we have the case until the case
Leaves the engineer.
So we went from an average of about six days to five days.
So a whole day reduced with the engineer.
We saw a 6% lift in case c sat.
And we started seeing support listed in those nps promoters.
Again, a signal that we're doing something right.
And giving value to the customers that they are repeating back to
Us in those surveys.
We saw a 30% reduction in all escalations.
And a 50% reduction in escalations that were for unresponsive
Cases.
So again, helping those engineers be more on top of all of their
Cases.
Taking action on those that are most urgent so they can be more
Effective and deliver more value to the customers.
>> That's fair.
>> That's very impressive.
>> Sorry.
Talking a little fast.
>> So you did great.
What are you going to do next?
>> We're really excited about our partnership with support
Logic.
So we're working with the product team and we're
Standardizing all of our alerts.
We found that some managers had really good alerts.
Some managers were getting 200 e-mails a day.
Which frankly, i don't know how they work.
So we figured we need to do some standardizing about best practices.
What alerts are we going to surface?
How do we do them in the right way so that the engineer gets the
Alert and the manager gets the alert and maybe the regional
Manager gets an alert so that we all get access to the same data.
We're integrating support logic into our gain site instance for
Our customer success teams.
Helping rework our health score so that customers with a
Negative support logic score could then be reflected back in
The same site so that we could be more effective working with those
Accounts and helping those tams and account managers be more
Successful.
We saw some stuff about case summaries.
So we're working with the product team at support logic to test
Out.
Case summarize and jai in our support teams.
So we've got that pilot going on right now.
And then with the assist and resolve sx that x find
Acquisition, we're really excited about that technology.
We think it's going to have a very meaningful impact to our
Business.
So we're targeting some proof of concepts to get rolled out later
This year and hopefully get those launched next year.
Lots of very exciting stuff for nice and support logic.
>> So we expect you back next year with even better numbers,
Right?
>> Better numbers.
>> Case deflection rates.
>> Yeah.
Okay.
Great.
So let's try to leave you with a couple of thoughts about
Backlog management if that's something you're interested in.
Step one, diagnose where your problem is coming from.
That's what you did.
If you don't know where the root cause is, then you will not
Fix it.
If you have problems with people, then you need to address them
With the people.
If you have problems with the product, you need to address
With the product, et cetera.
Idea number two is to really do something about backlog
Management.
Sometimes my clients, it seems to me, just hope that it's going
To work.
Hope does not work, right?
We need to have a real backlog management process.
And then, of course, the two of you really showed us that
Technology can make a huge difference.
>> Huge.
Yeah, it's a big deal.
>> We've been focusing on the backlog more recently because
The predictions that are so good, that gives the focus on customer
And they know that, hey, predictions are great.
But then the backlog tool is all those predictions combined
With all the sentiment.
It's a great way to tackle it.
It's actually focused last year to let customers know that
Hey, this backlog page is kind of a bad word sometimes.
But it helps you focus on what you can work on.
We've had one customer that built all these custom lists of
Backlogs.
And they perfected it so well, they want to copy to every user in
Sportlogic so the whole company is on the same page.
So if you guys want that, let us know, talk to your CSM about
Customizing some of that and maybe copying it to the other
Users.
Because it works really well at centralize everyone so they can
Standardize, like Chris said, standardize what they're looking
At.
So if you all measure the same metrics, you can all have the same
Results.
>> Wonderful.
Thank you so much.
If you have any questions, please grab anyone of us and
We'd be happy to answer them.
Thank you very much.
[Applause]
(applause)
(applause)