The Net Promoter System Podcast
Very few general managers have as much passion for Agile sprint methodology as Mark Robinson. Mark is the president of UPS Capital, the financial services subsidiary of UPS, which focuses on insuring risks in the supply chain—cargo insurance, for example—as well as financing for goods that move in the supply chain.
In our podcast discussion, Mark outlines how the adoption of the Net Promoter System at UPS Capital was turbocharged by Agile ways of working, and he makes a strong case for using closed loop feedback with Agile to improve customer relationships.
As in many companies, the immediacy of Net Promoter feedback gave UPS Capital a critical view of how customers were feeling. “I think the enemy of frequent customer feedback is that customers don’t want to give you frequent feedback. It’s a pain, right? I don’t want to get a 10-page survey every week from the same companies I do business with,” Mark says. “So it has to be done in a way that the customers are going to give it to you. And that is really where the lightbulb really went off on NPS. If you really have a way in one question to get the temperature of how they’re feeling about your business, they’re not going to get annoyed if every time you have a touchpoint, you want to know how it went.”
But the components of the Net Promoter System that really took things to the next level, he says, were Agile project management, organized around customer journeys. “Whatever’s happened with a customer when they have a claim—from the moment they identify a claim and take notice of it, until their claim gets settled—we identified that as a journey. We put an Agile team on that journey. We also used Agile teams to implement some large technology improvements that were organized around the business processes that needed to be addressed.”
Agile teams also played a critical role in supporting huddles. As UPS Capital moved beyond just gathering customer feedback to also collecting frontline employee input about what their work groups and the company as a whole could do better, Agile teams were able to radically speed up the needed fixes that the huddles identified. The company’s previous waterfall project management process meant that a process or systems improvement might take six months. “I can’t implement customer improvements quickly if you have that kind of a pipeline. But if you look at Agile, we’re running things in two-week sprints. So I have an opportunity every two weeks to fix something.” Many of the fixes, he says, are relatively small, but still involve a system or business process fix. “Now these things are just getting knocked out.” And that, he says, is inspiring to the work groups, demonstrating that their huddle feedback results in quick action and improvements for customers.
Rob Markey: So, two best practices, in the early days as you made this transition were, one: distributing the feedback directly into the organization, to the front line as soon as you get it. And then, two: doing those follow-up calls very quickly.
Mark Robinson: Yes.
Rob Markey: What other practices made a difference.
Mark Robinson: Well, I think the system components are implementing Agile project management, and organizing them around customer journeys. We were not doing that before. And that was a significant change for us. It wasn’t a little change. That was a real big one. And then fully implementing the huddles themselves. Moving beyond just asking the customer how it’s going and trying to resolve it. Having the whole work group, the frontline work groups, reviewing their NPS score on a weekly basis, looking at things that they can fix within their work group, maybe a training issue or a knowledge issue, but also having a place—when the work group can’t fix it—having a place for that to go.
The implementation of our Agile teams gave a way for a customer issue to go into a group that could then execute on that in a short period of time. We had been using sort of a waterfall project management process, and the difficulty about that process was it had a very long pipeline on it. So, if you got a customer need out of that and you went over and go, “OK, I need to fix something for my customer. My project pipeline has a six-month front end on it. I need to put this somewhere, but there’s six months of prioritized work there.” Well, I can’t implement customer improvements quickly if you have that long of a pipeline.
Rob Markey: Right.
Mark Robinson: And then you look at Agile? We’re running things in two-week sprints. So, I have an opportunity every two weeks to fix something, without disrupting the whole process.
Rob Markey: Right.
Mark Robinson: Now these things are just getting knocked out. A lot of the fixes are relatively small, but there’s still a system fix or there’s some kind of a business process change that needs to be made, and those get fixed very quickly. That comes back to the work group. “Hey, not only are you able to address the things that you can control within your work group, but your ideas of fixing problems are getting into a system that’s getting it fixed.” And then you’re seeing it. Now, it’s never happening as fast as they would like. But it’s happening. And I think that’s the key: It did take three weeks, or it did take two sprint cycles ... but it got done.
Net Promoter System®, Net Promoter Score®, Net Promoter® and NPS® are registered trademarks of Bain & Company, Inc., Fred Reichheld, and Satmetrix Systems, Inc.
Explore more episodes of The Net Promoter System Podcast.