Sid Bhambhani: We’re good to go. Hey, Peter. This is Sid. I’m super excited to introduce our guest today, Peter Muir, who is the manager of Tech Support at one of the fastest-growing technology companies here in Waterloo called Dejero. Welcome, Peter. Welcome to the show.

Peter Muir: Hey, Sid, great to be chatting with you and thanks very much for having me on this show.

Sid: Great. A little bit about Peter. He has a couple of decades of experience in the customer support field now, starting with a number of technology companies and moving on to the likes of Blackberry in their heyday and now with Dejero. He’s one of those guys who started his support journey in the trenches and now leads a team across the globe. Peter, with your experience, I guess, the first question I’ll ask you is, how did you get started and where did this all start?

Peter: As you mentioned, I’ve had a couple of decades, which is scary when you say it like that, but yes, I started my career back in the late 90’s when the Internet was taking up, doing help desk at an ISP. In transition I’ve seen a lot of boring stuff in the trench work, but started putting things up at Blackberry, advancing pretty quickly through the ranks and support there, picking up some knowledge management skills and doing KCS coaching.

Then, the typical downfall of Blackberry happened, so from there I transitioned into Dejero. I started back in the phone system there but quickly advanced as well. I went back to school. I did some training, really getting my certification in the adult education and how to teach people. Positioned that into a role doing the head trainer, building our knowledge management, knowledge basis and training content. For the last two years, I’ve been leading this support team at Dejero.

Sid: It really is fantastic. Peter, you and I know each other at a personal level. One of the things that I’ve always found fascinating about your journey and about even the way you approach support, customer service operations or support concepts and generally that’s focused on coaching and teaching. The fact that you led KCS programs and incorporated that into your journey in such a big way, speaks a lot to that. Can you tell us a little bit about how do you see that as being an important part of support in general, the knowledge management and the coaching aspect?

Peter: Well, I think it’s really important from just a customer experience perspective in making sure that the knowledge that you’re capturing is reflected inside articles and future learning opportunities for other agents. Nobody likes to repeat work. That being said, teaching your reps and agents to start adapting to the KCS methodology, where they’re going to take the knowledge that they learned and translate that, if you will, into an article that will help future agents is a big, big step.

Specifically, with Dejero, we have a very complicated product mix. Not everybody is going to know all of the answers and that’s totally okay. It has been said by many people that tech support is not knowing all the answers but knowing where they’ll find them. Giving them that library of content to go and find this material, cuts down on the customers wait time and the time to solve the case. So, I think that’s really, really important.

Sid: How big of a team are we talking about at Dejero that you’re managing today?

Peter: I actually run a fairly small team in the grander scheme of things. I’m the only member of the customer service operations team. We don’t have team leads yet. My agent team is at nine. We’ve got nine people and that also includes our repair technician. She does a great job at doing the hardware repairs. It’s a small team.

Sid: Interesting. With a small team like that it becomes even more critical to make sure that you have the knowledge in the right places so that people can pick up from where the other people left off, right?

Peter: Yes, it’s because of the complicated product mix that I was mentioning and the smaller team and the fact that we support 24/7 with nine people, makes it difficult to stay on top of all of the changing products and changes in software releases that one might expect in that type of product mix. It’s important that we’re capturing that sort of knowledge and making sure that it’s accessible to everybody.

Sid: Interesting. What kind of tools and tech stack are you guys using in your day-to-day customer service operations? You mentioned it’s a 24/7 operation which- that’s fascinating. How do you guys keep up? What are the tools you use?

Peter: Largely, we do Jira and Confluence for the escalations, not really for tickets though. When I say what we use for tickets, it makes people laugh is because we use Netsuite and that really ties in to the hardware components through the financial aspect. That’s why we use it. It’s definitely not our first choice, but the idea of having accessibility into where and when the products were built is important to us. We do tie our tickets into that, and so it’s not a support-focused ticketing system.

There’s clearly better ones for that, but for what Dejero needs it for, it actually functions pretty well. We use that, but in terms of the knowledge we’re using Zendesk for their knowledge base, we use Confluence for the internal knowledge base. Those are some of the more traditional support software toolboxes that we kind of get into. We use Jenkins to do a lot of the automation stuff that we’re doing on a day-to-day basis.

Sid: Interesting. We always get into the tools discussion when we’re having these chats with it doesn’t matter who it is. At the end of the day, the tools are a means to an end. As long as you can run your business and run it effectively, no tool is perfect and you’re going to have to put up with some [unintelligible 00:07:25]. I guess the segue over here from tools is the means to that end is what are some of the most important metrics for you as a support organization and what are you tracking today?

Peter: What we’re tracking, we don’t really do individual metrics. We tried this before just with regards to– I’m not really interested in knowing the average handle time of a particular agent or I’m not really concerned with their after work time. Now, it is the smaller team, so that probably has a whole lot to do with that. Obviously, as you scale the larger team that was metrics are important because then you’re getting lost in the force because of the trees.

That being said, I’m more interested in how the customer is serviced by my agents. If it takes an hour to fix that problem, then it takes an hour. If it’s five minutes, then it’s five minutes. At the end of the day, I’m really looking for the customer experience and how the customer was serviced during the interaction. With that said, I’m looking at more of the team-based metrics where I can see the average response rate to incoming ticket or the overall ticket volume. That just tells me do I need to bring on more agents or offer overtime to people that are currently working.

My team is small, as I mentioned nine people. When an agent isn’t performing– Because a lot of people might think, “Well, how do you find that?” Those problems bubble up to the top real quick.

Sid: Yes, the ability to compare it by itself.

Peter: Exactly. It’s not really scalable, so we’re looking at introducing CSATs, and relying on some of the technology to give us a better picture of how our agents and how our customers are feeling.

Sid: That makes sense. You just showed me a very interesting aspect here. I think it’s important if you look at it. You said these individual KPIs are particularly interested, but you’re interested in how that translates to a customer experience. How do you collect data about your customers’ experience today. Are they filling out surveys? Are you doing something other than KPIs to collect that?

Peter: No, nothing at all, really, surprisingly nothing at all. The feedback that we get is usually the email directly to me, they let me know how they feel. They let me know if one of their interactions didn’t go as they felt, or even they might even let the founder know. One of the things to mention that’s really important here is that our product mix has a certain degree of stickiness to it. We don’t have a lot of churn in our business because of the amount that people have to invest to get the product into their business and up and running, it’s not small.

That being said, you’re not going to have a lot of people that just say, “Well, I’m not going to use your products anymore because of a bad interaction.” Rather, they’re going to be motivated to work with my team to get to the bottom of the problem. That might mean I have to visit them on site. So, there’s some travel involved with this role.

Sid: Interesting. What are some of the challenges that you are seeing as your business continues to grow? Some of the things you mentioned and are somewhat obvious in terms of the scaling problems that you have. What do you foresee some of those things to be?

Peter: Really, it’s a matter of understanding the markets. We’re launching a new product called IronRoute. It just involves really a whole mix of all of our products together. Traditionally, you’d buy one or two pieces, but this is really a mix of them all. The challenges with the introducing that to different markets, whether it’s South America or if it’s Europe, there’s different challenges to that. Right now we’re having some problems streaming video from Iraq over to Slovenia. So, there’s challenges inherent with the geography and the whole political system that’s going on right now that requires my team to build out the log analysis that needs to be done.

That’s the challenges that we see scaling up to this is– This is one site. How about when it turns to a hundred sites, what does that look like? Do we have to build out an entire knock to start monitoring this? Are we going to get into the whole managed services side of the business? That’s all stuff that needs to be explored.

Sid: That’s such an interesting thought because from a customer perspective, their experience is the sum of the product quality, the service they get. In your case, or in your product’s case, also the network that delivers that service. What I’m hearing is you probably need to do more on all of these fronts to be able to control that overall experience. Does that sound right?

Peter: Yes, absolutely 100% accurate. We’re dealing with an Azure cloud infrastructure, we’re dealing with customers that cannot afford to losing any sort of connectivity. Primarily in our broadcast stream as we’re dealing with news agencies, that is obviously a very important delivery system for them to get the content to the TV sets. They can’t afford any downtime. Likewise, on the connectivity front, we’re looking at a whole bunch of different aspects that cannot lose that connectivity, whether it’s disaster recovery to the first responder market. There’s a lot of stuff. It’s not your typical consumer-based route. This is enterprise-level grade connectivity that needs to be looked after.

The team needs to scale with that. Those are the challenges that we’re currently looking at. You could say it’s somewhat of a chicken and egg problem.

Sid: How so?

Peter: We have the infrastructure to be built in order to sell it, but then we need to sell it in order to build it. Then you have to get the team in order to support it. What does that look like? Those are the challenges that we’re going through right now.

Sid: Interesting, interesting. Let’s actually take a step higher than that, Peter. What I’m looking at over here is the interdependency of customer experiences across the board. While your challenges are to deliver a great customer experience, that is somewhat hinged on the fact that you’re using different services and providers. That feeds into the customer experience that your customers end up receiving on the other end. Right?

Peter: Yes.

Sid: How are you managing those relationships today, because you can’t manage every aspect of the flow? What kind of things do you have in place with you as the consumer on the other end to say, “This is what I want to make sure my customers are happy.”?

Peter: Yes. That’s actually a really good question. We have a really solid DevOps team. Those guys are- they’re great, they’re great to be listening. Hi, guys. Basically, those guys do real standup job with keeping the infrastructure glued together. They’re on call 24/7 like my team. They manage the whole Azure side of things. They’re looking at the infrastructure, making sure that the databases are going along as they should be. Really, the entire Dejero infrastructure is- they’re all performing together. There’s a lot of interdependencies, as you mentioned, between our two teams.

We literally sit beside one another. It’s a matter where as soon as we start seeing customers complaining about a certain thing, we’re notifying them. More often in the cases that they’re notifying us to say, “Hey, look, we’re starting to see this specific infrastructure without getting into detail. It’s starting to tick up. You guys are going to start seeing impact.” Then we can respond from a support team much more effectively. We can start preparing notifications to customers and all of that good stuff.

Sid: That’s such an interesting trend, because you and I have been in this industry for a while. It used to be a very brick-fixed kind of business. You get a call, you answered it, you fix the problem, and you move on. Over time, as companies start delivering SAS solutions or cloud solutions, it’s turning into more of a proactive service which has always been the [unintelligible 00:17:07] for us to achieve. How do you see the DevOps and support relationship progressing towards that?

Peter: Yes. You’re right, it’s a transparency model. You have to be transparent with– Everybody talks about having five nines and all that stuff. That’s going to become more and more important because that’s going to be the delineator between one company versus another, and why should I pick you versus another one. You could start being transparent to those types of numbers. When you can start boasting that you have a 95% answer rate or your chat feedback is 100% or you have a great CSAT feedback of whatever number, more an NPS score of nine.

Those numbers, you’re going to start being able to advertise them as metrics to see why you should pick one company over another. That interdependency between DevOps and support is going to be extremely important. The two of them have the big enough difference between the skill sets required that you’re not going to see the two teams merge when you’ve got one team that’s very customer-focused versus one team that is clearly very database-driven. They are going to be more important towards the uptime side of things.

Sid: That makes a lot of sense. In fact, it’s a good segue into the question. Do you want me to pause here, Peter?

Peter: Yes. If you could. I got to answer– My doorbell just [unintelligible 00:18:58] Sorry.

Sid: I can pause. No worries. That’s actually a very interesting observation, Peter in the way the interdependencies are between service and service provision. In fact, it’s a great way to think about what the future holds for support in general. Where do you see support going in terms of us being able to turn the corner and achieve that philosophy of being able to get to customers before they get to us?

[silence]

Peter: Sure. Yes, repeat the question.

Sid: What I was saying was interesting observation in terms of how the services or the support and service delivery are getting intertwined. Where do you see the the future of support in terms of how the services are being delivered to a SAS consumer?

Peter: I think the [inaudible 00:20:22] we see we’re going is and more inter-dependency between customer experience and support. I’ve seen models where customer experience is the entire support department. They focus on a more proactive model, whereas your traditional support is reactive, as you mentioned, the whole brick-fixed scenario. That’s where we currently run right now. We don’t have a customer experience team by name, but the responsibilities that you typically find in a customer experience team are shared between our sales ops team, our support team. Our regional sales managers even to a certain extent are looking after certain aspects.

We can tell if a customer is not using our product. We will reach out proactively, which is traditionally a customer experience role. That being said, I think do we need to see a customer experience team? Probably. There will be some merging of the job roles as the guys that goes in where the support team that I currently lead will do away with a lot of the proactive stuff and really focus on that problem-solving idea.

Sid: What you said is very interesting, Peter, because given the size of the company and the way you’ve grown the culture from the grassroots, it sounds like it’s the customer experience is not a role, it’s a mindset. That’s some of the conversations we’ve had with our other guests on the show too, where for it to really take root in an organization that needs to be a shared responsibility between various other departments. Right?

Peter: Yes. It’s interesting you brought up your other guests. I did have the opportunity to listen to some of the other podcasts. The one point– I forget who it was, and I apologize, the one that resonated with me was how he took an entrepreneurial perspective to support where it’s your customer not say, for example, Dejero’s customer. It’s my ticket, it’s my customer. I’m going to see that through.

Their customer experience is still mine. I’m going to take care of that customer and see them through the entire journey, whatever that may be. That really resonated with me, in a sense where it’s entrepreneurial, like I own the business, even if clearly I don’t. I think people will do well when they really invested in the customer, they invested in that product. That translates well to– Definitely my experience with my career is that I constantly just treated the customer as my own.

Sid: Interesting. Given the experience you have, Peter, and the number of places you’ve worked at, who’s the one person who you would say, has been a great mentor for you that you’ve learned a lot of the support operations and tips and tricks from?

Peter: I would say this question brings up some good memories of an old manager whose name was Tom. Sadly, I heard that he passed a few years back. I think reflecting on what he taught me was in my role as a system access administrator, which I only held for a year. I was a contract position. We were constantly being audited by the provincial government on a monthly basis. It was banking and finance and all that stuff.

Sid: That must have been a fun experience.

[laughter]

Peter: It taught me a lot. What he taught me was to always be able to back up my decisions with documentation, sort of the CYA, if you will. The one thing I always remember him doing was, he used to look at me and hold up his hand, palm facing out, as in that that’s his imaginary piece of paper, showing me why he did what he did. It seems like an innocuous example, but my short time there gave me the tool to be successful in my roles to follow in my career. To always say, “This is why I did it.” Again, I’m holding up my palm here, an imaginary piece of paper. This is why I did it. I’m backing up every single one of my decisions.

With my dedication to the documentation aspect of things with my tickets, this is why I did it. My tickets are going to be really rich and notes in detail. That’s why I decided to do it. Sometimes I’m wrong. A lot of times I failed. The idea is that you keep on getting- picking yourself back up, dusting yourself off and continue to move forward.

Sid: That’s a great story. It even resonates with me more because one of the things that I’ve heard in the past is, you’re not always going to make the right decision. You will at least know that you made the right decision based on the data you had at that time. You’re not going to remember what it was unless you’ve written it down or you have it in a way that you can go back to it. I think it definitely helps from that perspective as well.

Peter: If I can share the one quote that is currently up on my whiteboard– You’ve been in my office, you’ve seen that quote, Sid where– Briefly so you can look it up. It’s Teddy Roosevelt’s the Man in the Arena, where the man bleeds and he sweats and he fights and he fails and he fails. He keeps on getting back up. I’m paraphrasing here. No matter how many times you fail, you pick yourself back up and you learn from your experience and you move on.

Sid: I have seen that quote. I think that’s a very poignant quote to end our discussion on. I think it’s been an absolute pleasure, Peter, talking to you and learning from your experience. It really is a unique industry in the one that you’re in. It gives us a lot of perspective about how support is on this cusp of an evolution. Thanks for your time and hopefully you enjoyed your chat. We look forward to hearing from you again.

Peter: Thank you very much, Sid. We’ll definitely talk later. Have a nice day.

Sid: You too.

[00:27:21] [END OF AUDIO]