Transcript

Bruce Dean: Hey, good afternoon everyone. Thanks so much for joining us here for our session on field services. Quick introductions to get us started. I’m Bruce Dean. I’m Bell Canada’s senior VP of network and field services.

Matthew Billy: And with me today… I’m Matthew Billy. I’m a technical lead and architect for Ateko. Ateko is Canada’s largest elite ServiceNow partner. We focus in the financial services industry as well as telecommunications and other government sectors jobs. My job is implementing FSM for him and his wonderful team in ServiceNow.

Bruce Dean: And we appreciate you, Matt. Uh, hey, maybe before we get started, just to get a sense of the room here, who’s doing an FSM implementation right now? Okay. Hopefully my team has their hand up. And and who has done one? Okay, so most people are either doing one or or has done one.

Matthew Billy: Yeah. And we know that FSM can be uh pretty complex. Who’s on the low end of complexity, they think? Show of hands, low end? Okay, everyone’s a unicorn. It’s super highly complex. Awesome. That’s what we’re here to talk about today.

Bruce Dean: Perfect. Okay. So, I mentioned I work for for Bell. So Bell is Canada’s largest telco. So we have, you know, large wireline network, large mobility network. We also have media in Canada, right? So, so TV stations, uh data centers, you name it. We’re we’re a huge organization with a huge fleet. And, you know, I thought field service management was a very telco specific problem. I always thought, oh, this is this software is for a telco. And as I started talking to colleagues over the last couple of years, I realized this challenge really spans all industries, right? We put some up on the the page there, right? municipalities around doing site visits. You know, certainly utilities have some similarities, but I was talking to a friend at a at an FI the other day and they have a whole fleet that goes out and services their point of sale terminals, uh services ATMs, does maintenance at the banks. Same for retailers, you know, you kind of name it. An interesting one that was totally I I hadn’t even thought of was healthcare is actually one of the biggest FSM users in terms of sending, you know, nurses to customer’s homes, scheduling visits. And so it really is a a a whole um, you know, product that spans literally every industry. It was really eye opening for me. Uh, a little bit about Bell and and you know, some background on on what we can share. So my team at at Bell uh in the field side of the business is about 10,000. So on any given day, you know, probably about 5 or 6,000 techs are out in trucks, uh visiting customers, maintaining our infrastructure. We’re seeing over 10,000 customers every day right across the entire country. So it’s a very large scale operation. You know, you mentioned complexity. We’re certainly complex, right? 400 different skill sets I mentioned, right? Everything from basic things like installing somebody’s internet to doing complex underground cable repairs, maintaining power infrastructure, mobility tower infrastructure, enterprise customers, you know, you name it. Uh, across the country, we actually have 600 distinct territories that we serve. And so for those of you uh in the FSM space, you can imagine what that means about how do you optimize within territory, across territory, how do you set those border limits? How do you travel inside and outside of those borders? Uh, and while we have a certainly a large number of uh of technicians that are with Bell, we also have about 60 different partners that we work with. And so we have workflow that has to flow to other partners, right? Think about things like, you know, we work with construction companies to go out and uh excavate, right? If there’s a damage uh underground, we have to excavate it. We have locators that locate facilities. Uh, you know, other tasks like varying wires, replacing infrastructure, you name it. So it’s a very, very big uh and complex environment that obviously requires real seamless execution. You know, the example when I’m talking to friends who don’t know the industry very well, is I like to use the airline industry problem, which is, you know, we’re trying to balance efficiency and customer experience. And so if we wanted to show up to every customer appointment on time, I see you nodding, you you know the tradeoffs. It’s very easy to show up to every customer appointment on time, but it requires a lot of extra capacity in the system, which is expensive. Or you know, you do what airlines used to do in the past, which is overbook it, make sure you’ve got fully utilized capacity but customers who are left disappointed. And so this is really the problem at heart of what we’re trying to solve with FSM, which is how do we minimize any of that white space or underutilized time? How do we make sure that we’re minimizing our travel time? How do we make sure that we’re getting to customers on time? How do we make sure we’re sending the right customer or the right technicians there with with the right skills? So that ultimately at the end of the day, we probably hit the same goals and constraints that all of you have, which is I need to improve customer service, but I also have to significantly reduce cost. And that’s what we’ve been able to do on the journey that we’re on here. And I think scale is probably the biggest thing I mentioned, right? We span across the country of Canada. I mentioned the 10,000 technicians. And so everything that we’re doing has to be fully automated because if it’s not automated, one, that’s a lot of manual work which which takes a lot of, you know, time and and labor, but it also means that you’re not being efficient. And so for us, the challenge was how do we optimize such a large ecosystem and really deliver it with with efficiency uh to to deliver on those goals and that’s uh that’s what Matt here has helped us out with.

Matthew Billy: Thank you very much. I’m gonna have to switch sides with you.

Bruce Dean: We’ll switch. All right, perfect.

Matthew Billy: Thanks. So Bruce mentioned a lot of things about scaling, whether it’s geography, territories, technologies, product stacks, product offerings. Let’s start and think about some of the things that we’ve actually encountered dealing with FSM for Bell. So we got three categories. There’s lots more categories. As I’m sure you guys have already heard, lots of constraints, lots of objectives. Let’s talk about some of the technician dispatching challenges Bell threw at us. Intraday scheduling of technicians where the technician has a different start and end point or where the technician starts from a location at one point of their shift and then has a different part of their schedule from a different location. That can affect their pre-travel times, their post-travel times, their allowance for overtime. All of that has to happen per technician per day and not related to their shift.

Bruce Dean: What I’d even add to that, Matt, which which is a challenge probably many of you face is we have one schedule that’s set at the start of the day, but that schedule changes pretty much the second we open shop, right? Customers aren’t home that you expected to be home, travel conditions are worse than you expected. We take a bunch of customer appointments in day and so not only is it optimizing at that level of one technician, but that that gant chart of work, both on the the technician capacity available and the customer demand is constantly changing throughout the day.

Matthew Billy: Yeah. Drip and bulk technician, for those of you implementing FSM, you’re aware that it’s a global setting where one size fits all, not with Bell. Not only are we doing drip and bulk technician at a technician preference, we’re also doing it on a day-to-day basis. How do you do that in FSM?

Bruce Dean: On that point, I’ll tell you, this this is where Matt will know the right technology answer, but I will argue drip versus bulk becomes almost a psychological debate. And we’ve had some very fierce debates on is it better for a tech to see that they’ve got five jobs to get done that day and they know they need to get it done and it’s up to them on how they do it? Or is it more efficient for them to see one job at a time so that you’re sending them the next most efficient job? And you all probably have strong opinions on it. I know internally we did as well. And I think the the answer is actually in between that for some areas it makes sense. In other areas, typically higher density areas, the the drip makes more sense.

Matthew Billy: For Bell, the drip and bulk dispatch question isn’t actually about the workload they’re doing or the territory the tech’s operating in today. It’s more about the technician, their seniority, their skill sets, their privileges, whether or not they started at a work center, started from home. Those are the kinds of variables that FSM just wasn’t kind of built to handle. And we’ll talk about how we help that soon. The other thing that we have as a complexity is optimized flexible lunches. Not only does Bell want to offer a lunch that works best for our schedule and our appointments, we also want to optimize for our labor force considerations. So the 60 plus partners and those agreements as well as the regulatory framework across Canada. As you can tell, it gets pretty complex pretty fast.

Bruce Dean: It is true. We do have snowmobiles in Canada in our fleet.

Matthew Billy: We’re getting there. We’re getting there. All right, travel methodologies. How many of you can find the setting for optimizing an EV, an electric vehicle’s range in day inside of FSM? Right. There isn’t one yet, but there will be one soon. Those are some of the challenges. How about scheduling appointments around a technician that needs to take a snowmobile or a boat or a helicopter to reach their destination? And how about optimizing for real traffic? The things that happen in day, the real rush hour ebb and flow, the real road closures, the real detours and not just using some sort of maps average, right? The average might work really good in the low time, but is it really what you need at rush hour or when that road is closed? Probably not. And lastly, scale considerations. So having a flexible workforce means that we have to scale and adapt for prioritizing for today’s load. Our technicians, the flexible technicians that Bruce is talking about, sometimes they’re doing copper, sometimes they’re doing fiber, sometimes they’re on repair, sometimes they’re on circuits. That load has to be optimized and prioritized based on the technician and not just today’s load. Making mass changes to travel plans. If you know that there’s a storm coming, you want to adjust all of your travel scenarios to make sure that you have the most accurate optimization output at the end of the or at the start of the day. And a regulated environment. So we are impacting our lead time, our lead time complexity for things like wholesale and win back because of the telco market and industry. What it what it boils down to is that Bell had built their field service tool over the last 10 years and heavily customized it. And for rollout, they expected about 90% of their customizations to just work on FSM. It’s a little bit of like eating an elephant. So you might ask, how do you eat an elephant? One bite at a time. The answer is we co-innovated with ServiceNow. What does co-innovation with ServiceNow mean? We broke down the problems and the features that were needed by Bell and we worked with our partners in ServiceNow to make sure or rather to review whether or not those needs for the field service management platform were needs that other customers in other industries might also have. What that means is that while we did have to make some customizations and while we are building some tools and features that will be only for Bell, the FSM product as a whole has a road map that has features that we’ve built for Bell that are going to come online for all the rest of the product consumers. It’s actually a win-win. Not only do you guys as consumers of field service management get some of the newer things that ServiceNow hadn’t quite dreamed of yet, we also benefit because as they roll out those features, they’re kind of custom built for our needs, which means I get to remove customizations and configuration which would have required manual maintenance and upgrades at patching.

Bruce Dean: Yeah, I got to say to to that point, working with ServiceNow and and the particularly the FSM product team, in fact I see Nikki back there, has been phenomenal because we are building or we are a very large scale organization and the team with FSM has been very, very open to adopting and and adjusting the product road map to help deliver a lot of that functionality that large complex organizations have. Right with some other other platforms out there, you get the product that’s out there and if it doesn’t work for your industry, well, you know, it’s not great. But the the adaptability that we’ve had here has been phenomenal and so we we really appreciate that. Likewise though, I think Matt, what Ateko has been very helpful with is also challenging us to not just implement a system that does the same stuff we did for the last 20 years. I see some nodding, a couple people nodding here, right? That’s the challenge right is is the business and I’m the business in this case, you know, we have a bunch of great reasons for why we do all these different steps and buttons we have to push and handoffs that have to happen. But over years it becomes more and more additive and as you take on a transformation, it’s a great time to actually question all of that and we’ve drastically, I’d say simplified that. I’m sure there’s still more you’d like us to do but it’s been a very helpful experience.

Matthew Billy: We’re focusing on business outcomes to make sure that you have the same results, maybe just in the ServiceNow way and that way we have the supported methodology and not everything needs to be custom on the top. So, here’s an example of our co-innovation with ServiceNow. As I said earlier, bulk and drip dispatching inside of ServiceNow and FSM up until Z and A is kind of a global setting. That doesn’t work for Bell. So really early on, we engaged with ServiceNow and we co-innovated the product roadmap and we indicated that we needed a product and a feature that could do bulk or drip per agent on a schedule, not something that’s a global setting, not something that’s just based on their queue depth, but actual time-based drip functionality. Maybe we drip it sooner if there’s an appointment. Maybe we drip it earlier at the beginning of the day and later at the end of the day. Maybe after 2:00, I drip the rest of the appointments for an agent. Those are some of the features that we were building. So what do we do? Me and my team, we built a custom dispatch logic. We built an event-driven model that scales natively on the platform to handle things like time, agent preference, and events. That means that as our territories grow, as our optimization grows, we can actually scale this dispatch solution natively on the platform using the event queue and queue management. We shared these recommendations and requirements with ServiceNow. We developed the customization and then we reviewed it with ServiceNow and they’re like, can we get a little more detail? I’d like to be able to see how we could build this on the platform. And soon, as of I think Brazil, maybe Q4, you’ll actually be able to see time-based drip, time-based drip and bulk dispatch at a technician level and not at a global setting. The product maturity is improved because we have this symbiotic relationship, this co-innovation. And that, like I said earlier, that means that all FSM customers benefit from the work that we’ve been doing with Bell as a large, complicated telco.

Bruce Dean: I do, it’s a great point. Like I do feel like we’re truly co-creating this with ServiceNow. It’s it’s the the receptivity to it has just been phenomenal and it’s just really building a a really great product for us.

Matthew Billy: Yeah.

Bruce Dean: To to that point, I got to say that…

Matthew Billy: All right. So, let’s talk about the elephant in the room or rather the agentic agent in the room. So, Bell Canada has over 40 plus ServiceNow implementations, either completed or in flight. Our agentic process or Bell’s agentic process covers all of their instances and all of their product models. They have a holistic view on building ServiceNow modules and capabilities with agentic in mind. Now, you’re saying, well, not every module has agentic or not every module touches AI. That’s okay. There are a couple of things that we’ve done with them. So, we worked with Bell to dispatch or build a COE, a ServiceNow COE focused around agentic value, agentic control, agentic, what’s the word, compliance basically, so that the business knows where all of its people are spending their time investing or inventing agentic components, right? That also means that that COE is able to push out training, push out knowledge, push out best practices and identify risks and control strategies for all the agents they’re building across all of their instances. So, you might ask, what are some agents that they’re building? So we have a dispatch coded orders. For any of you in field service, when the order doesn’t go right at the door, right? That we call that a coded order. ServiceNow or Bell built a coded order agent tool. That coded order flows directly from the field agent back into case management and the case agent, instead of just seeing, oh, I got to rebook them an appointment, actually gets a customer 360 view from all of Bell’s customer information tools about the products they have, their customer satisfaction, the interactions that have happened. Now, some of that is native to ServiceNow, but a lot of it is because Bell has such a large customer knowledge inference, it’s it’s actually spread vastly across. We have an agent that gathers all that data for the case agent.

Bruce Dean: Yeah, to to that point and and for those of you in Telco, you know exactly what I’m talking about. But on any given appointment, about 85% of the time, everything goes totally smoothly, right? The technician shows up when he or she should, the customer’s home, we have the right tools to do it. There’s no plant or infrastructure issues. You know, you name it, everything gets completed, everything’s automated, all is good. and you rarely see a complaint on those types of visits. The other 15% though is what way disproportionately will drive the complaints because as you said, now something has gone wrong and a handoff has occurred and it’s not usually just as simple as oh we need to rebook. It could be something like my technician has gone to climb a pole and he’s realized that it’s unsafe, right? There there’s uh a hazard and we now have to engage potentially the the power company or or another organization. When those handoffs start to happen, what we found in the past was you’d lose, first of all, that record and so the customer would call in and ask, hey, what’s going on? The technician was here, he says there was a problem. They would call back in and that L1 agent or that care agent would say, I don’t I don’t see anything noted on your file here, I don’t see what’s going on. You know, that would happen a couple more times, they’d write a complaint and so on. And this would happen on, you know, each use case is a very, very small percentage of the time, right? A safety issue might happen, an engineering issue might happen, something complex about the customer, an address mismatch, you name it. And so by having this agent that can link it with case, we now have both full visibility to it, which is great, but we can be proactive with that, right? So if that uh if that safety issue is not being resolved within a certain threshold of time, we can trigger an action on it. If that appointment’s not being re-booked, we can reach back out and so on. And this is really targeting that, yeah, it’s only 15% of the orders, but I would say it’s probably 80% of the the complaints that we were getting.

Matthew Billy: Great. Another example of co-innovation at work. So, we’re building an agentic workflow that looks at weather events from a, you know, a national kind of database like think of Noah and publishes reactive and proactive events for assets that are in the field based on weather alerts, weather severity, weather perception, things that you could have to respond to either before or after the weather happens. That’s for a large outdoor media company. Field service parts tracking. We’re using RFID trackers in the truck to track sensitive, well, sensitive and and like financially important uh little assets to make sure that the chain of custody on the asset is handled properly. That’s for a large utility. And lastly, we’re building an AI workforce and workflow that looks at vehicle scanning, so automated vehicle scanning and tool scanning, identifies problems through an image recognition software and then generates proactive or reactive work orders to fix it, dispatching text to go fix the part as needed. Thankfully, you’ve reached the end of our presentation. We have a couple more minutes. I’d be happy to take some questions, so would Bruce.