AI Agents and Field Operations at Scale: Bell Canada’s Approach

with Bruce Dean and Matthew Billy

Bell runs one of Canada’s largest field service organizations, with a team of over 10,000 handling more than 10,000 tasks daily. When manual operations and dispatch processes couldn’t keep up, Bell partnered with Ateko to rebuild their entire field service management ecosystem on ServiceNow.

In this session, Bell’s field service leadership – together with the Ateko team – will share how they successfully deployed AI-powered schedule optimization to automate field operations, increase workforce productivity, and master the complexity of dispatching at scale.

Bell partnered with Ateko to transform their field operations and dispatching at scale.

Transcription

Bruce Dean: Awesome. That’s what we’re here to talk about today. Perfect, okay, so I mentioned I work 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 TV stations, data centers, you name it. 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 page there, right? Municipalities around doing site visits. You know, certainly utilities have some similarities. But I was talking to a friend at an FI the other day, and they have a whole fleet that goes out and services their point-of-sale terminals, services ATMs, does maintenance at the banks. Same for retailers, you know, you name it.

And an interesting one that was totally, I hadn’t even thought of, was healthcare is actually one of the biggest FSM users in terms of sending, you know, nurses to customers’ homes, scheduling visits. And so it really is a whole, um, you know, product that spans literally every industry. It was really eye-opening for me.

A little bit about Bell and, you know, some background on what we can share. So, my team at Bell in the field side of the business is about 10,000. So on any given day, you know, probably about 5,000 or 6,000 techs are out in trucks 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. Across the country, we actually have 600 distinct territories that we serve. And so for those of you in the FSM space, you can imagine what that means about how do you optimize within a territory, across territory, how do you set those border limits? How do you travel inside and outside of those borders?

And while we have a certainly a large number 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 excavate, right? If there’s a damage underground, we have to excavate it. We have locators that locate facilities, uh, you know, other tasks like burying wires, replacing infrastructure, you name it. So it’s a very, very big and complex environment that obviously requires real seamless execution.

The example I like to use for 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 know the trade-off. 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 were left disappointed. And so this is really the problem at the 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 the right skills so that ultimately, at the end of the day, we probably have 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 in 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 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 efficiency to deliver on those goals? And that’s what Matt here has helped us out with.

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 to 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 in their shift and then has a different part of their schedule from another 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 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 Gantt chart of work, both on 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 who are 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 answer is actually in between. For some areas, it makes sense. In other areas, typically higher density areas, 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 start at a work center or start 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 helped with that soon. The other thing that we have is the 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.

Matthew Billy: We actually have boats too. We’re getting there. Alright. 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 an appointment 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 map’s average, right? The average might work really good in a low time, but is it really what you need at rush hour 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 a 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 or at the start of the day.

And then 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 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 that just work on FSM. It’s a little bit of like eating an elephant. So you might ask, how do you eat an elephant?

Bruce Dean: One bite at a time.

Matthew Billy: The answer is we co-innovate 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 at 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 roadmap that has features that we’ve built for Bell that are going to come online for all the rest of the product’s 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, configurations, which would have required manual maintenance and upgrades and patching.

Bruce Dean: Yeah, I got to say to that point, working with ServiceNow and and the particularly the FSM product team, and in fact, I see Nikki back there, has been phenomenal because we are a build, we are a very large-scale organization and the team with FSM has been very, very open to adopting and adjusting the product roadmap to help deliver a lot of that functionality that large, complex organizations have, right? With some other platforms out there, you get the product that’s out there. If it doesn’t work for your industry, well, you know, it’s not great. But the adaptability that we’ve had here has been phenomenal. So 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 of people nodding here, right? That’s the challenge, right, 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. Yeah. 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, it’s 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 no 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 dispatching at a technician level and not at a global setting. The product maturity has 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 with ServiceNow. The receptivity to it has just been phenomenal and it’s just really building a really great product for us.

Matthew Billy: Yep, I’m just one release away from being able to remove that customization and I’m super looking forward to it. So, let’s talk about the elephant in the room, or rather the agentic agents 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 work with Bell to dispatch or build a COE, a ServiceNow COE focused around agentic value, agentic control, agentic, what’s the word, compliance basically, or consideration 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 order. 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 with ServiceNow, but a lot of it is because Bell has such a large customer knowledge imprint, it’s actually spread vastly across. We have an agent that gathers all that data for the case agent.

Bruce Dean: Yeah, and to that point, 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 planned 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, that’s where 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’s a hazard. And we now have to engage potentially the power company or another organization. When those handoffs start to happen, what we found in the past was you’d lose, first of all, the record. And so the customer would call in and say, “Hey, what’s going on? The technician was here, he said there was a problem,” and that L1 agent or that 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 rebooked, we can reach back out, and so on. And this is really targeting that, yes, only 15% of the orders, but I would say it’s probably 80% of the complaints that we were getting.

Matthew Billy: Great. Another example of co-innovation at work. So we’re building an agent that will recommend a solution for those unmet demands that are part of your load at the beginning of the day. Maybe a couple of people called in sick, maybe your in-day load was higher than planned. How do you do it? As a dispatcher, as a workforce manager, what’s the right answer? Do I call 10 people? Do I flex my overtime? We’re building an agent that’s going to actually help the system understand and put that in front of a workforce manager to say, “Yep, let’s do that. Call in five people and then flex overtime for these 10,” because the agent and the agentic workflow knows where the tasks are, they know where the next task was, they know when the complexity of the tools and the skills were needed. It can actually do that. It’s it’s it’s quite impressive.

Bruce Dean: And it can be consistent, right? Because the challenge we have, right, is one dispatcher will do one task, the other dispatcher will do it another way, and this really helps standardize that.

Matthew Billy: Yep. Another agent that we’ve discussed with ServiceNow that we’re looking at building is making secondary agent memberships. So everyone knows that you’ve got a primary territory that you’re part of. Maybe you’ve defined your territories with overlap out of the box. Maybe you do it by memberships. Well, based on where an agent is working today, their secondary membership might not be a static thing. You might actually want to customize or make sure you’re making the right recommendation. We have a workflow that’ll automatically execute secondary agent memberships on the platform so that the optimizer in-day can see and flex that load, resulting in fewer, less travel time, and fewer missed appointments. But I want to make sure that we understand that just because we have agentic on the platform doesn’t mean we can’t leverage agentic in other tools too. ServiceNow, and what we’re doing with Bell, we’re going to have other agents that are part of our monitoring tools. So as the technician is going along, they’re installing your home services, they connect to your set-top box, right? That set-top box talks over the network, straight to a monitoring tool, registers its MAC, and now all the network monitoring tools are coming live. Now me, the FSM system, I know nothing about where the agent’s at within their schedule, right? I just saw a two-hour piece of time and I don’t know where the agent’s at other than they have an hour of time for rest. But maybe this customer already has their set-top boxes in the wires already in place, and he’s now half an hour to an hour ahead of schedule. Our monitoring tools or Bell’s monitoring tools can actually tell ServiceNow through their other agentic workflows, other pieces of information that ServiceNow didn’t have. So ServiceNow is also easy to integrate with other agentic tools and other models, and it’s something that you need to consider when you’re dealing with FSM and ServiceNow as a whole.

All right, so what are the types of outcomes that we’re looking for here? So on the dispatch side, over 90% of the actual dispatch tasks have been fully automated. No need for any kind of touch, no kind of kickout, no discrepancy, uh, fully automated. Uh, all the manual exceptions, 80% of them have been streamlined so that they go through either the the agentic process that you mentioned or through other workflows so that we don’t have manual processes happening outside of the system, right? Through email, through phone calls, through other departments. It’s all in one system of record. It’s also allowing us to free up about one in eight of our dispatchers to now focus on more valuable work than simply managing the very basic tasks. And with Ateko’s help, we’ve been able to get at this value a lot faster than we would have otherwise, which has been really, really helpful.

Yeah. So I also want to share and some of the cool things that Ateko is doing with some of our other customers. So we’re building an agentic workflow that looks at weather events from a, you know, a national kind of database like, think of NOAA, 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 and like financially important, uh, little assets to make sure that the chain of custody on the asset is handled properly and it’s captured in the work order. And that’s for a large utility. And lastly, we’re building AI workflow 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 techs to go fix the parts as needed.

Thank you. Thankfully, you’ve reached the end of our presentation. We have a couple more minutes. I’d be happy to take some questions.