How Dedicated Pods Deliver a Great Customer Experience
After years of emphasizing the technology, these days firms really seem to be focusing on the “people factor.” Why do you think that is?
Well, that’s really the only way we can differentiate ourselves. Everybody has access to the same tools for processing, review, analytics, and so on. And you can’t demonstrate your expertise by giving them a demo or explaining how your technologies are better, because we all know what the different applications can and cannot do. So how do you show the client that you can offer them value? By looking to your most valuable asset: the people. And it’s not just about the individuals on your team – it’s also how you deploy the team, and how well they focus on the experience of the customer.
So what’s your approach? How do you deliver a great customer experience?
We want a response time of less than five minutes when our customers reach out, so we use what we call pods. Since your ability to ensure responsiveness ultimately comes down to location, I’m sure every organization struggles with this – for example, if the majority of your people are on the East coast but you’re servicing a West coast client, it becomes very challenging. So we build pods of three or four people, with someone on the East coast, someone in Central time and someone on the West coast or in Mountain time. This way, we’re perfectly set up to deliver services no matter where the client is located. Essentially, you just follow the sun and build dedicated teams based on your clients’ needs so that there’s never a gap in service.
The interesting thing is that larger organizations probably can’t do it the way we do. Typically they’re more departmentalized. There’s a processing organization and a production organization, and so forth. The people who manage the review platform are labeled as the hosting department, and their only role is to manage hosted environments. And then you have the project manager who’s kind of playing the air traffic controller. But Trustpoint didn’t believe in that way of delivering the service because we felt like there were too many handoffs.
It sounds a lot like something that has worked really well for Amazon over the years. They call it the “two pizza team.” Teams that are small enough that they can’t eat more than 2 pizzas.
Right. Best case, that keeps the team agile and fast, and ensures that communication is effective. The risk is that with a really small group, sometimes the processes get lost. And by that I mean that when people say “agile,” they really mean “we’re just moving fast. We’re not documenting anything.” So in the long run, they wind up reinventing the wheel for every project.
Obviously, repeatability and defensibility are key. How does your pod approach support those goals?
Honestly, our whole philosophy is to work backwards from a smiling customer. It’s as simple as that. If we have a pod of three people who are dedicated to a large law firm, and in the past five years we’ve handled maybe 50 matters for them, those three individuals are really an extension of the law firm’s litigation support group. They’re deeply aware of the firm’s needs and goals, and they understand and document our processes at every step. The pod is small enough to remain agile, but because they’re dedicated to that client, they rarely need to reinvent the wheel. It’s not a typical supplier / customer relationship at all – it becomes a true partnership.
You mentioned that too many hand-offs can cause problems. Can you elaborate on that?
I remember a situation that occurred a few years back, which stands out as a great example. We’d been working with this large firm, on an investigation that had been going on for the better part of a year, but we hadn’t received new data for several months. We had a pod assigned to the firm, and we’d been providing services since the inception of the matter, so everyone was thoroughly familiar with the requirements. And at one point, one of the pod members realized that the client was requesting something that was going to cause catastrophic results down the road. So he notified the client in true partnership fashion, and it became one of those Eureka moments. Like, wow – you just saved us tons of money and time by catching a problem that we probably wouldn’t have identified until production. But if we’d been handling things in a typical, departmentalized way, the request would have come in to the Project Manager, who would have handed it off to the processing team or what have you, possibly without even being aware of the potential impact. Without the level of dedicated awareness that we had in that pod, we might not have caught it at all.
That was the first time we really looked at our agile delivery model in terms of how valuable true partnerships with your clients can be. From that point forward, we said, we have to do this for all clients across the board. This is the system for us, because we are nimble. We’re entrepreneurial, as an organization, and it just makes sense for us and our customer base.
Work backwards from a smiling customer. It really does make a lot of sense.
It absolutely does. And I think customers who have experienced both methods would tell you they definitely prefer the interactions they have with us.