IFS Service CollABorative: Think Tank Session – How Remote Capabilities Are Changing Field Service Delivery

Date of Meeting: 20 September 2023 11:00 AM US Eastern Time 

Insights from Sarah:

Slide: The world of break-fix service is in the rearview

• Remote capabilities, remote service and where things are, where things are heading. So, I think largely speaking, the world of break fix service is in the rear-view or at least it's nearer to that. I think we all know that today's customer expectations are not that we wait for something to break, we call someone and then we wait for them to come fix it. Hopefully the first time, maybe the second or third time, right? So, what does that mean?
• So we're looking at a variety of different tools and technological capabilities that increase opportunities for self-service, remote service and then bring more automation into the service process. So that we are really delivering service in a more intelligent way
• Using augmented reality to allow teams to support customers and one another in a sort of hands on but not really hands on manner.
• Developing an informed service delivery strategy and revenue model based on both the capabilities that exist today but also customer needs and interests and getting ahead of how all these changes in service delivery are going to evolve the role of the frontline technician in the years to come.
• So, I think when I think about service, this is the topic that I really enjoy because I think it's one of the biggest areas of opportunity areas of innovation over the coming years. And I think there are some sort of misperceptions though around what we mean when we talk about remote service. But I think one of those is that remote service means remote only. And I don't think that's the goal for many folks at all. And I'm going to give you some examples here in a moment, but it also isn't just one technology, it can be a lot of different technologies, but the idea is really to reflect on your current service delivery model. What is the time that's wasted. What is the inefficiency is that that aren't serving anyone well, they're not serving the customer well. They're not enjoyable for the technicians because the reason this is such a good area of opportunity is, technologically speaking, there are so many ways to dive into that process and remove those inefficiencies, those friction points in a way that provides better service to your customers and also helps you counteract to some degree the labor challenges that you're all facing, right? So I think it's really an exciting area of discussion.

Slide: Ricoh – When’s the right time for disruptive innovation

• So, I just want to go through some different examples. now these are not all IFS customers, some are, some aren't. But again, we're not talking necessarily just about IFS. We're just talking about the topic here. I really like this point that Darren Elmore of Ricoh made. When is the right time for disruptive innovation? If you are still in the break fix world, the transactional service world, this evolution of service delivery is not just about putting in place a new technology that changes an aspect of that service delivery. You can't do that without also changing the customer experience without also then changing how you're describing the value proposition. And sometimes that does tie into your revenue model. How are you charging for service? If it's always been, you call us, we come, we bill you for hours on site, then that's a big discussion, right? So, I agree with Darren, it is a massive paradigm shift and it's one where you don't want to fall into the trap of thinking too narrowly about what you would define remote service as. Darren was on the podcast and I liked how he talked about as a leader, the personal risk that comes into play when you are spearheading innovation in your business and knowing when to make bets and when you believe in something enough that you are ready to push that paradigm shift.

Slide: Mettler Toledo – Moving past inefficient historical norms

• Steven from Mettler Toledo was on and this is an important one because it was honestly a light bulb moment for me. What Stephen said, in their context of service there is actually very little that can be resolved remotely. It would be a very tiny percentage of actual remote resolution that could take place. However, historically they always did an initial triage visit. They had a truck roll just to go see what's going on? Here is what it is. Now we know what we need to fix it. Now we'll schedule the actual service visit. So, essentially he's talking about that's just what their norm was. These inefficient historical norms the way we've always done it, and people get very stuck in that. What he's saying is if we put remote tools in place to just do the triage remotely, automatically, they're reducing truck rolls by about 50%. And those triage visits hold no value to the customer, right? Other than someone shows up to see what's going on, but they're not really resolving anything then. So, his point is having to do 2 visits drain capacity. The amount of inefficiency there is crazy, so my point in why that was a light bulb moment for me was remote service also doesn't have to mean remote resolution. So the goal doesn't always have to be that you are resolving service tickets remotely. It could be something like this, where you're taking out an efficiency in just an initial triage visit, et cetera.

Slide: Konica Minolta – Embracing – and managing – change

• Konica Minolta is on their remote by default mission, and Ged kindly spoke at our UK event this year and talked about the mindset and moving past the historical thinking, embracing and being ready to manage that change. So we'll talk about that a little bit more.

Slide: Munters – Implementing a new tool doesn’t have to be super complex

• Munters, I like this example. Now Munters rolled out IFS remote assistance at the very, very beginning of the pandemic. And the thing I like about this and I never want to minimize the complexity of change. But on the flip side, I did want to put this example in here because they were able to roll this tool out a merged reality tool to 200 technicians across 15 countries in two weeks. And so I also want to say yes, you have to think about the bigger picture. Yes, you have to be ready to manage change, but at the same time, sometimes I think the angst of something new makes us inflate what it really has to mean. So there are sometimes things we can do that don't have to be incredibly expensive, time consuming, or complex.

Other Notes:

• We talked about sort of the premise, right, the era of traditional break fix service is in the rear-view. We talked about the fact that there are different types of remote capabilities. We're not talking about just one thing here. Sometimes I think because IFS’s tool is remote assistance. When we say remote service, we mean, people are deploying that merged reality remote assistance tool. That's one, but there are a lot of different things we could be talking about here. We could be talking about self service. We can talk about AI and machine learning and self repair and predictive capabilities. We can talk about more traditional remote access to systems. And then, of course, augmented reality, virtual reality et cetera. So, some of the myths that I encounter often, I already said the one which is remote brings about the idea of remote only versus, remote first or where would remote make sense. I think another myth is assuming customers will react poorly. There's stories on both sides of this customers that absolutely love the idea, customers that are more hesitant. But we shouldn't assume that that will be the case. And then the last is that it's too complex and that's why I put in that Munters example.
• Value drivers. It's a viable opportunity to reduce demand on a strained talent pool. It can lower the cost to serve and maximize efficiency. It can improve the customer experience and customer value and you have an opportunity I think still to get ahead of the curve and be a leader, not a laggard. Obviously considerations here are change management. Driving more value based conversations with customers, particularly in situations where those customers are used to that transactional service model. Focusing on customers who are ready and more innovative first.
• So, this is something that comes up in a lot of my conversations with people. If you choose to go down this path of looking at adopting more remote capabilities, that doesn't mean that they have to be in place with every customer from day one. You can pick the areas of opportunity you have to get going and then use that to build upon. There are some industries where in certain remote situations have very real security objections. And so there's a difference between objections that are founded and real. And then ones that are just more surface level because again it's something different. 
• I think one of the biggest areas of discussion here has to be around how the role of the technician will change and the possibilities that that brings. So at our Paris event this year, Ravichandra Kshirsagar, from Schneider Electric came and spoke and we talked a lot about what the role of the field technician will look like in 2025. And one of the things that he said, and it was so simple, but just really made me think, is they've just recently changed the title of their technicians from field technician to service technician, and they're doing that with this thought in mind that over the next couple of years, the work those technicians do, maybe less on site and more remote. And so getting rid of that field assumption. I think you have the opportunity for some real flexibility when we start thinking about remote service and what that can mean to the role of the technician, allowing other roles within the business to fit some of the remote service roles, giving technicians who don't want to travel, or travel as much, an option to work remotely or in the office, giving technicians more flexibility because they're able to split time between remote and on site or manage schedules differently, et cetera.

Customer Experiences (Questions / Answers / Feedback / Responses):

• Q: I am interested in learning more about self-help. We're trying to figure out a way to do more self-help so actually have our customers possibly scan a barcode, walk them through a knowledge base. Force them to do some kind of troubleshooting before they just send it over to dispatch. But I was just curious if anybody out there has done anything like that and what the success rate has been. And I'll state that our traditional model is, they have to call us today and we have to log a ticket over the phone.
  A: So what we do a number of things actually. We monitor the entire estate and if we get jobs that we know that the customer can resolve themselves, we will send that job down to the customer themselves. We'll interface to the customer and then they will pass it down via an iPad or tablet to do that job and they'll the fingertip jobs, it can be consumable jobs, it could be triage jobs, it could be all sorts of jobs. And we do quite a lot of that. A lot of our ticketing equipment most of it nowadays is will touch card, but the legacy equipment which the ticket things in like that is electrical mechanical equipment and you run out of ticket stock you get jams, you get all sorts of things. So we passed down fingerprint jobs automatically to the device, and then we escalate on that we record when it went when it happened so we're able to then measure the performance of our own customer of that makes sense. And some stations are better than others, some stuff better than others some push back on it, some never responded, but what we then do is if it triggers certain amount of time we'll take the back off to them and then we'll go and attend to it ourselves or we'll escalate it something like that. We never just throw it at them and leave it. We'll kind of almost hold their hand and some are very good some will do it straight away, others won't do it and then we have to escalate things. And that works pretty well actually and it's certainly cut down our engineer visits and it's certainly enabled the experience of the passenger to be able to do it because very often they won't even know that it's occurred it's a monitored situation, so they won't even know that the device 200 yards always got a ticket jam, so we'll tell them. The next thing we do, because we monitor, we can interact with it, so we will go and nudge the machine ourselves. Certain devices where there is a ticket stop, we can roll the belt automatically. We can fire that stuff down. So, no one has to interact with it. We will see the fault and then we will send down instructions to go and reboot or things like that. Now, that sounds brilliant, but a reboot for example will actually take the device out of service for 7 seconds. So what we actually do is reboot it, and get the device back into operation, totally remotely or totally automated, but we'll log a 7 second incident, fully encapsulated downtime incident as a service incident so that the customer has full transparency at the fact that we automatically reboot that and that there was a 7 second gap that enabled the customer not to be able to do it, because you might find that that customer complained at that precise moment. So we are automating self service right and device by knowing instructions and knowing the estate, but also logging the repercussions of that and capturing that that was a self service short duration fault. So there's a number of ways we do that.
  F: I think that's smart because yes, there's the chance in that 7 seconds they log a complaint, right? But also, even if not, it gives you the opportunity to articulate the value you're providing in that proactive predictive service, because otherwise this is where you get into, well, it's not broken. It's working. What are you doing for me? This is where we get into having the data to support the value of service delivered in a different way and that's important.
  R: But the other thing about it of course is that because we're collecting all this valuable information and we know how many times we have to reboot it, we've backed feed that into engineering to fix it at source. As to why, this is the scale of it, and this is the impact it's having on our ability to provide our service because we guarantee hours of being outcome and 14 * 7 seconds adds up to 100 times adds up etcetera. And so, we then back feed it. And that back feeding happens automatically as well because if we if we have storms of those and high trees of those and tall trees are those there are automatically reports that go to engineering to say these are these are our big hitters at the moment look at these, and no one has to look at that they are generally created and then they are assessed at like a monthly review of the instant base, so we're automating the sort of view of it as well, so that's how we do it. But going back to the station staff, we post jobs down to the customer and let them deal with it on their devices. We don't pass it to a device that is a device that we give to the customer we pass it to their ERP system and let them manage it down there to their device and then that way, they can control it they can do whatever they want with it.
  F: About your operation, I think, this is the other thing is we probably need to think about this as a bit of a continuum like every technological advancement or area of opportunity and service, which what was describing I think is pretty sophisticated. So, there's a couple of things that that may be different. One is, knowing that you're talking about lottery systems that I think are largely deployed in customer sites where they might not have the technical capabilities to do anything to extreme or what have you. I think to start it might be a conversation of thinking about like, so right now a customer calls to log a ticket. What, if any, troubleshooting do they do on that call? Are there some steps that that call center could take to help customers maybe work on a bit of remote resolution and that could be with them using the knowledge base and then of course, there's the idea as you stated about, creating more of a knowledge base for customers where they can go and find some of the insights themselves to do a repair and then, maybe if they can't sort it out, they log a ticket through a portal instead of having to call in, that sort of thing. I guess what I'm saying, is there's no reason that Scientific Games can't do the same thing that that Cubics doing or something similar, but there may be steps toward more of a predictive, automated process where we start with just, OK, if right now it's just call in log a complaint, someone will come check it out. You can start with, OK, can we equip the call center to do some troubleshooting? OK, can we do some simple self help things where customers have another way to contact us or to look through some information versus calling in etcetera? 
  R: It's just something that came to mind when you said about the lottery. And this is happened in our industry as well. We've got many different types of contracts. We've got many different types of capabilities of an end user and we've got that confidence level. So again, you've got an end user and I'm thinking lottery now, so you've got a person in a shop environment who's one of the task is to push the buttons into a machine, create a lottery ticket handed to the customer as part of a transaction, not the full transaction. Normally a lottery is a is a part of a transaction. Have they got the confidence to stop? Have they got the time to stop because there's a queue behind the people, especially if it's on one of the big supermarket from desks where the people are buying the groceries as well as their lottery ticket. So, you've got to take this into account, and then you've got to go back to your contract because again, with the printers, we had many, many years ago the contract was we will be there in 4 hours. And if we don't get there in four hours, we'll give you €100. And we had the confidence to say and the bandwidth to be able to do that. And so it's a process of, first of all, developing what the outcomes they want to be, then finding the customers that want to join that and have the bandwidth to do that, then helping the customers have the confidence by creating the tools that give them the visualizations, the access to training, the access to, for instance, I'll call it my favourite thing, Google to get an answer. And then making it easy and again one of the things we learned very quickly, our products are not designed for our end users to fix. They're designed for it engineers to fix. So, what you have to do then is go back to the factories and start a 5-6 year process of, how do you make it easier for the customer to feed. The feedback loop to the customer, it even that 7 seconds, that creates information for your customer and honesty with your customer, that creates discussion with the customer about, yeah your system down for seven seconds, but if you let us come in at 2:00 AM in the morning and we upgraded all the firmware because we learned like 7 seconds can go back to R&D and keep saying we have this 7 seconds in seven second, R&D can then say when we've got a firmware fix for this, the firmware fixed going to be deployed at a quiet time. Generally, if you ask some of our people, they'd go, oh, well, it's really convenient for me. And 8:30 – 09:00 AM to change all the gates on London transport. I bet you that goes down really well with the customers. It's the busiest time, but if you can do that, maybe 02:00 or 03:00 AM, not Saturday morning, you get the feedback loop because the systems are actually set for you to do that, and these are the things that it's a process you've got to start thinking of what's possible now, where do you want to be in 18 months time? Where do you want to be in five years time? And then start having them conversations with customers about the art of possible. So that in two or three years time they actually start repeating what you're saying to them. They actually start employing people. They start creating the bandwidth within their people, and they build it into their own training things because again, when the lottery machines down, I don't know what percentage they make, but they're not making money if the tills down, they're not making money. If the gates are down, you're not making money. This is where we've got to sit and think, where do we help the customers, customer make money.
  F: We also want to keep in mind that remote capabilities can mean interfacing with our customers remotely. They can also mean just interfacing with the equipment remotely, and so I know most of your lottery equipment is IoT enabled, so it could also be something where if you feel like the customer is not going to be inclined or capable of doing a lot of self service, it can also be looking at OK, how do we interface better with our equipment to allow more of this assessing or that sort of thing. The other thing is thinking about how you make the process as simple and seamless for the customer as possible. If you do feel you want to take that step, it could be that in the situation of your customer base, rather than having sort of a self-help library that could feel very cumbersome, something like remote assistance where you can send them a link, they log in, you're in live, someone seeing what they see and you can walk them through it pretty quickly. That may be a more attainable experience for them, because they can feel more supported and the technician is hands on even though they aren't there physically. So, there's obviously a lot to sort through there, but it's interesting.

• F: We've started noticing for a couple of years that clients say they're ready, but my dispatcher will talk to a buyer. They're not going to talk to the person in the factory floor, so we've started just bigger, mandates. More complex mandates, make it mandatory, which is just have that remote service, which is just a preparatory visit to save them time on the field. If we're going offshore on a rig, this is really, really time sensitive. You don't want to spend too much money on stuff like that, so that's helped. We've also put some technicians depending on the department, because we have many different departments that are always on standby during the week to take those extra remote calls to save time and ultimately money. So, the clients know they can count on us, but this idea of automating tickets for self-service and the bar codes I think is just really, really interesting and can save even more time. So, we're really a partner to help our clients. I find that aspect quite interesting.
  R: I got what you said that sometimes the buyer says they're ready but then that buyer isn't the person actually interfacing right. So what are you doing? Are you doing like sort of a readiness assessment essentially, is that sort of what you're saying?
  F: Absolutely. So, if we're going for a better job, we're going to make sure we're putting meeting time. We have all the requirements. Installing checklists so we can make sure, like you said, readiness and it's really our technician going to do the job or a senior tech that it's as full time job to really help with this things and the end user on the floor, the engineer, the project manager so many that can really make sure all the ducks are in a row.
  R: And are they interfacing remotely?
  F: Yes, teams right now, but obviously other capabilities would be probably more interesting.

• F: I wanted to point out something you mentioned right before, remote service is not only that people interaction with the back office, it is also machines and from our point of view we are building machines running in very rough circumstances. Underground, and all these things about remote is depending from a machine data and more based on IoT. And that is a long way. We heard before, thinking about what you are wanting two years or five years. We started journey 10 years ago. And the first thing single question was how we get data out of the machine, how we can get data to our back office and we are not cross the finish line, but we huge step forward. At the moment if we have technical issues on machines and customer ask for support and you have keep in mind that in our machines nearly very good, very well trained person from customer side maintains the machine make regular service on the machine. So, we get a lot of questions like ‘why is this happening’ and not like ok, there's something broken down. Say change the part in the machine is still running, but the question is what was the reason and why and how we can prevent that in the future and for the next machines and so on. And we are still in on this journey and a point, where we now have the data we are now can visualize the data. We are starting to more analyse data to understand and what's changing in the last 3-4 years is that if we have technical issues and more delicate or difficult issues where we need more explore and more time to evolve this, that in the past we need some pictures. We need some more information and today the first question is where is the data we have to look into the data. How does the customers use the machine? What was the circumstances and so on and so on. And I think our journey will be in the next year's to understand this data better to make more knowledge out of the data, so that we get at the end of the day, we could mention directly to the customer or to our service engineer, inform the machines, but due to some complexities of machines and environment underground, I think it will be take another 10 years.
  R:  Like you said, we started our journey two or five years from now 10 years ago, right? And that's part of why I wanted to have this conversation today, right? Is because I do see this topic overall, which includes a lot of different flavours as a huge area of change in the coming years. And so if you're not thinking about it, if you're not taking steps, if you're not, like imagining the art of what is possible, you will be behind, right? So, we do need to be planning, not only for the next two or five years, but really thinking long term.

• F: So remote assistance, so we're actually on the same journey as many of you, although we have some complications by virtue of how our business is designed. The machines were supporting aren't really complex. We are swapping registers. We are swapping access points. We're swapping servers. We're swapping payment terminals and where does differentiates us from many of you folks, is that the whole point of given a technician a remote assistance capability, we've investigated it. It looks cool and sure it's something we can brag about, but it doesn't help because if they can't figure out how to swap a server or swap a register, swap a terminal, then they're not going to figure out how to use a mobile app either. And by that definition, it's not technology that was seemingly worked for us to invest in, And very much similar with the people on the floor in these retail locations that we primarily support, the people there aren't going to benefit from us walking them through remotely the capabilities. So we kind of have to change tracks a little bit and what we are now further investigating is more down the IoT plus AI path. So, we found this partner called Canopy, previously known as Banyan, and they have this solution to where they're basically building these Raspberry pies devices or something equivalent. I'm sure they branded differently than that, OK, because I'm simplifying it big time, but it's a device that they're connecting within the customers environment and not only does it gather feedback, which they call leaves, but they they're calling their leaves and they're putting these leaves on their network and it's collecting all of this IoT feedback, which you can then parse through the standard data engines. Deep mark. You've got more data than you know what to do with. It's going to parse through. Where canopy for us as made a little bit of a difference, is that not only does it have a lot of existing database information on all of these error messages, it falls back onto AI to translate some of these messages, to make sense of them and identify which ones may be meaningful to act upon, or to just file away for a non events. But it also has all of the data it collects. So, if we had tie it up to a zebra scanner, it already knows what messages on a zebra scanner are useful, so it's not something we have to come up with from scratch. Because if we're using a native IoT connective out of IFS, for example, we're getting the data back from Zebra. Great. But we're going to start from page one. We're going to start from scratch and figuring out which messages are useful to us, so partnering with the company already has a lot of that data is key. But here's the differentiator. It can also reboot on command. We can execute device, we can control the device remotely through the same leaf device application. Could either be software or hardware and it can send like a reboot command. So, if we find that 90% of the Zebra devices that have an error message ABC1, are resolved by rebooting the device, we can trigger that reboot remotely, have that device restart, and if it didn't come back up or it still has the issue, then we can automatically dispatch it technician. So we gained 3 benefits here by leveraging remote technology in combination with AI and IoT, which is one we get the information, we get the data right, always your key element is getting the data cause without data you're blind. You can't act upon what you don't know. Two, it uses the existing databases and information to kind of see which data is relevant to us. And of course, we can play into that further by getting our own learnings apply to that. Knowing that, this shouldn't have been ignored, this should be ignored going forward and that's that very long strenuous path depower of shaping the data to your needs. And three, it allows us to take some kind of remote control action against these devices to where we don't have to roll a truck preventing a truck roll is a huge benefit. And that gets us back up in good graces with our customers, cause not only are we now the truck rolling company, we are positioning ourselves much more as an MSP versus a just professional services dispatch organization.
  R: That’s really good. Like I said earlier from, it is important to look at this in the big picture that we're not just talking about anyone specific tool, right? There's a not only a lot of different tools, but different contexts of what remote capabilities can mean. It can be a company at a customer, it can be back office to technician. It can be data and AI. It can be all of these different facets and honestly I think it serves companies well to look at all of that and how it fits in or doesn't to your current process and what the future might look like. I do think one of the pieces that we haven't really talked about a lot on this conversation and really is its own topic though is, thinking about these capabilities can help with the labor challenges a lot of you have. There are a lot of options to start to introduce different types of flexibility and things that we really haven't been able to do before. And I think that's important to be thinking about.

• Q: How do you present this back to the customers? And I haven't solved for this yet? We are starting down the journey of this. We're not live on any customer yet. I think we have a trial coming up, a pilot coming up, proof of concept, if you will. But has anyone gotten any good recommendations how you ultimately share back to your client to results of your remote capabilities?
  R: Yeah, based on our experience, we collect data and use this for remote services and for remote analyzing and something like remote engineering at the end of the day to make sense better as a manufacturer in our machines. But you have to involve the customer and in the very beginning of this journey, 2008, to make reports to customer to make it transparent what we are doing with data, what we are doing on the machines or what's the machines are doing at customer side. And this is today in a status that we have in a product, at the end of the day. So, when do we sell this information back to the customer like a PDF report that is sent in the morning via email to the dictated email distribution list. Or maybe they have the opportunity for a little bit more money on a web page to see the performance of the machine. See performance of a shift like reports or error messages and so on and so on. And so at the end of the day, our experience is that we get the errors of the machine. We have a monitoring of the machine and the first customers in Asia ask us to operate and monitoring center to support them and maybe it takes 1-2 years to bring that up with experienced person and data lines and so on. But to say, OK, we see the error messages, we see your data on our screens, but we cannot interpret them.  OK, we need ad hoc service. Then maybe your phone call, my chat, my teams link or something like this, but I think we are at a point that customers are willing to pay for this and that is something that we hope years before. But yeah, we get the data out of the machine, we analyze them for our purpose and we make reports. We make calculations on them and sell products based on this data back to the customer and hopefully this journey will go on and only increase on that. At the moment, we earn a lot of money to sell machines, but yeah, it sounds easy to make additional after sales revenue, but it's a long journey and it's takes time that customers not only in Europe as well in Australia and Asia thinking about that. But I think Asia is going on the way that this willingness to pay for that.
  F: If you have review meetings with your customers. Have it as innovation. If you've got exhibitions, show it as innovation on your sites. Your competition in my marketplace, they talk about feed speeds and output of the product. They don't talk so much about service, so talk about your service. Be proud of your service, but be proud of the innovation in your service because when somebody goes to a different stand or the next person comes in for the review meeting. We have lots of clients who've got multiple vendors. When the other vendors come in and they say what are you doing on remote visualization tools and they say, ‘what?’ It gives you that benefit you teach ourselves how to do it and you explain your service engineers in the training parts, and we have engineers from 17 years old into 70 years old, and you talk about it. We're not ripping the customer off, we're actually bringing more value. We're bringing more uptime. We're bringing more first time fix. We'll bring in less truck rolls. We're saving the environment, and build that into your conversations with your customers. Don't talk about what's in it for you. Talk about what's in it for them. Try and find examples where you've helped a similar type of customer, don't give their name unless it's obvious, but talk about how somebody in a similar situation improve their uptime by 10,15-20% and turn that into a value. If you can turn that into a value when you're talking to a buyer, then they'll turn that into a value back to their people they sell to. So that was just my words. So that's how we do it or try.
  R: I think one of the things is when we start thinking about doing things differently and how that impacts our customer experience, we get nervous because we know that people are naturally resistant to change, right? And so if things are working relatively well, then you fear disrupting that. One of the things that I think is a really good point is, go into the conversation with confidence because it this is the way things are going. So again, that takes different shapes for all of your businesses and all of your customers. But there is no part of me that believes that we're not going more toward, more remote capabilities up time, outcomes versus transactions and break fix. So, go into the conversations confident knowing that you are presenting an accurate portrayal of the future. So, rather than wait for them to be ready, give them the confidence in you that you are ready. The other thing is there's kind of different answers to your question, I think whether we're talking about communicating with customers, you're starting to do this or communicating with customers once you've started doing it. So on the first part, we do need to think in this came up earlier, it can very well be a different contact within the business, right, because these capabilities tie into a conversation around delivering value and delivering outcomes versus delivering transactions. And so, if you're working with someone who is used to that transactional model and doesn't have a lot of per view of the business or interest outside of that, they're not going to give a crap what you're saying about value based conversations and outcomes. So you want to make sure you're talking to the right person and you need to practice. Also, it sounds so obvious, like don't talk about what's in it for you, but so many times companies make this mistake. It's like, we can reduce truck rolls. Well, the customer doesn't care because they're not paying for the truck roll, right? Like they care about first time fix and they're the same thing. Just said differently, right? But if you're not used to articulating that value based narrative, you can get stock in using internal language externally and then I think when you talk about the, once you're doing it part. So first of all, the point was also made and it's a very good one. And I see this in so many of my conversations. Find someone within your customer base who is more forward thinking and more innovative to start with so that you can practice with them a bit. You can build some proof points from that, and then you can create some momentum right? And then you can use those examples to build out from there. I think some of the things that were brought up earlier, people want ease and simplicity and outcomes and peace of mind, but they also want visibility and data and information so they don't want to have to participate in the outcomes or uptime anymore than they have to. But they also don't want to not see the work you're doing to make it happen. So, I think being able to have those quarterly business reviews, monthly reports, whatever it is, however, you're documenting the value. Like I said, with the seven second example earlier, it isn't about just covering your butt in case they contact you in that 7 seconds. It's about being able to say, hey, customer this past month we avoided, 30 instances of downtime for you through your remote service, and making sure that you are helping them visualize what the value is you're providing, not just expecting them to be happy with the fact that things are working.

If you are an IFS Customer and would like to watch the recording, please email jessica.foon@ifs.com

A copy of the slides can be found in the attachments section below.

Next Meeting: 17 October 2023 10:00 AM US Eastern Time
IFS Service CollABorative: Tech Talk Session with Stephen Jeffs-Watts, SVP Service Applications at IFS

If you are an IFS Customer and you would like to join the CollABoratives, please click here to fill out the form.