Service CollABorative March 2024 Session

IFS Service CollABorative: Tech Talk – Making the Most of Planning & Scheduling Optimization

Date of Meeting: 20 March 2024 11:00 AM US Eastern Time

Presentation:

Slide: The Team Online

• Jonathan – I lead our solution consulting practice for service management in IFS and go to market activities related to that. I am a long time PSO Super user. I've been using it pretty much every day since I joined IFS 7-8 years ago. I’ve been part of so many implementations.

Slide: Agenda

• What we'll talk about, first of all, the power of PSO. Common challenges which we always face when we implement PSO. And then we'll shift gears to what are the best practices for getting the optimal results with PSO. And #4 which I really look forward to are the features and capabilities to be aware of, or features and capabilities which you might not be aware or might not be using today which you maybe should be using, to get more out of out of PSO. Because there has been quite a lot of innovation on this feature set for the last couple of years. And when overlooking day-to-day operations, you might not see what's in the release notes for every release, and certain features might get overlooked in on implementation where the bigger focus is just to going live, and then we'll have a discussion.

Slide: The Power of PSO: Managing Complexity – Scheduling Optimization in numbers

• First of all, PSO solves a mathematically really complex problem. When I studied optimization in engineering some years ago, we managed to create the solver which solved a very simple routing problem overnight. The solver took like 12 hours to run, to come up with a reasonable result, and then I came to IFS. PSO who solved similar problems and in less than a minute, I didn't even think it was real to begin with. So that is really something to appreciate from an engineering perspective. First of all, that it solves a really complex math problem.

Slide: The Power of PSO: Managing Complexity – Scheduling Optimization in factors

• But it also solve a very complex business challenge in automating all of the business constraints that are part of our day to day life when scheduling jobs for field service. Getting the right job for the right resource in the right time with the right parts. At the same time, adhering to all these constraints. That's not an easy task either, so math and business both of them are really complex.

Slide: The Power of PSO: Business Benefits – Scheduling Optimization from IFS is proven to provide real business benefit

• And when you manage to solve those with good automation levels, you typically also reap very good business benefits and that's what we are all after, I think here. So, this puzzle is really worth solving. But in solving the also we will also face some challenges.

Slide: The Scheduling Optimization Journey & Challenge – Huge business benefits also means a lot of things needs to be in place

• As you know, scheduling as a journey right? This slide is so important that we acknowledge the fact that scheduling is a journey and the more business benefits we want to reap, the more we need to change the business. And that is obviously hard and there is a lot of factors to consider when climbing this journey or ladder, such as buy in from end users, such as how does the SLA's or appointment look like with the customers? What does management want to do? And also technological factors like where are we when it comes to process maturities, where are we with our data quality and our IT landscape, can we even orchestrate integration? What mobile devices do we have? But these are all factors that needs to be considered when we walk this journey towards full dynamic, drip feed, in the scheduling if we really want to go that far.

Slide: Management Challenges for Optimization Projects

• And this typically means that under ways that we find undocumented practices around how we schedule work. That's certain geographical or job role type imbalances might be revealed because we get quite a lot of transparency when we put PSO to schedule a work fully automatically without human bias that the manual process has. It also enforces that our data quality and data entry will have to be validated on high quality. And this all means that job roles and working patterns over time might change with PSO right? Which I will elaborate on in the 2 coming slides. And I think a valid question for the discussion afterwards is how to reward these productivity gains inside of the organization. So, if dispatchers are now 50% or 60% more efficient in their day job, how do we reward that? If we get the field technicians to do one more job in their daily schedule, how do we reward and celebrate that? That’s definitely a challenge to overcome, I think.

Slide: A transformation of the dispatcher’s role – From high volume/low value to low volume/high value

• And if we look at the dispatchers role as one example, that goes from focusing on 99% of the work, to then totally ignoring 99% of the work and focusing all of the efforts on the high complexity, high value exception resolving type work, which is of course a big challenge. Going from very labor intensive process to rather more investigative type process for dispatching.

Slide: A transformation of the technicians role – From fixing everything themselves to focusing on work execution

• And same for technicians who might have been totally self reliant in the past, looked after their own schedules, their own places to go and eat lunch, etcetera, along with the focus on customers. And with PSO we at least enable them to focus less on the misc task that they might have in their job to focus fully and solely on customer service and work execution.

Slide: Best practises for managing the Journey – Understand where you are, to-be-state and what needs to change

• Then quickly onto best practices to overcome these challenges. First of all, back to the journey again. I think that organizations have to understand where they are in the journey and also where they want to be and where they realistically can be on the scheduling journey. That's the starting point I think to map out where are we here on this ladder today and where do we want to be in the future. That determines how you need to need to implement PSO. Considering all these factors.

Slide: Successful Optimization Implementations

• Secondly, pre and post launch activities are very important. Getting sponsorship from executive management, selecting a good pilot area where you can actually achieve some results and get some quick wins. Simulate results in test environments before going live is really important. Benchmarking the current KPI’s is important and choosing champions and super users with the right attitude and knowledge.
• So then after post launch, we can track our performance against benchmarks that we have set up. That we use our super users and champions to champion the idea of letting the optimization engine make our decisions. And third, might be the most important one as the PSO is not a set and forget. Because as the business changes, modeling data in PSO also needs to change. So, everyone needs to strive for continuous improvement. Otherwise, your optimization engine will quickly get out of date or out dated, because it's being outpaced by the business and that is something I've seen in many scenarios where set and forget has happened. And then obviously celebrate and reward our successes is important and continue to use that super user and champions team as the rollout progresses.

Slide: What gets measured, gets done

• And measuring stuff is really, really important. When I see mediocre implementations, the following four things are not typically measured. But if we start the master scheduling automation, which PSO has standard KPIs for, at least standard ways of measuring, this four we can also start to manage that and the same with dispatch automation or dispatch rules, well modelled to reality. How many exceptions do we get? What types of exceptions do we do get? Do we acknowledge the exceptions? Do we fix them so that they don't show up the next time? And how often do we need to reschedule stuff in the middle of the process? I think these four measures really tells you what you have a good PSO implementation or not. And then, of course, for different businesses, there might be different definitions of what good looks like on these 4 ones.

Slide: Capabilities to be aware of

• Then onto the onto the final section before we get to the discussion. Capabilities to be aware of. Some of you might have seen, some of you of course will use this, but I think a lot of PSO customers have overlooked these capabilities.

Slide: Schedule Audit Train & Snapshots – Track performance against benchmarks with schedule play-back

• The first one is actually audit trail and snapshots in PSO. We do have the ability to capture the schedule on a regular basis, along with all the allocations, all the travel data, all the KPI facts, etcetera and store those. And that is important, both from a tactical strategic perspective that we can go back in time and see what our KPIs were like. But operationally, they can also be very good to have an audit trail when we do a debrief of the day. After a day's worth of scheduling, to be able to go back and just recap the entire day, quarter of an hour by quarter of an hour, has proven to be very, very useful. So that's common best practice to recap the day in that way, just to see how everything went and to learn from that.

Slide: Schedule Reporting – Track performance against benchmarks

• Secondly, scheduling, reporting from what I see is quite underused, despite the fact that you can get so much good the information from the scheduling archive, with all the prepopulated or pre-calculated KPIs that are in there, with all the preset schema for facts and dimensions. And there are some really good the power BI examples too to look there as well, which we can provide you guys with.

Slide: Automated Intelligent Travel Profiles – Let the optimization engine make the decisions

• Automated intelligent travel profiles. So being able to get to the most accurate travel estimates, we released the automated intelligent travel profiles a couple of years back. And with this, we can of course unlock higher levels of automation as the scheduling engine will act on more accurate information compared to just using the hierarchical travel matrix. But this is definitely one to look into if you haven't implemented automated intelligent travel profiles.

Slide: What-if-Scenario Explorer: Strategic Forecasting – Strive for continuous improvement

• And finally, when we talk about striving for continuous improvements, W.I.S.E can of course be a game changer and we encourage you to, if you have it, to use it every now and then to explore new scenarios around changes in the business, changes in KPIs, or desired behaviors, changes in main resourcing, changes in in workload. And this is also an area where we, from an R&D perspective will spend a lot of effort in the coming years. So all feedback that you can provide to us with regards to strategic forecasting is very much welcome. It is being looked into for the coming releases. Many improvements planned here.

Questions / Answers / Feedback / Responses:

• Q: Can you go back to the slide with the reporting and power BI? Can you help me understand that one. So, you offer some standard KPI’s here. What we see on the scheduling with the automation actions versus expected durations, but what does it mean that they are ready for BI reporting?
• A: It means that when you query the archiving service, you get to combine certain dimensions. So, for example, the customer, contract activity type, et cetera, we insert in predefined KPI’s.
• Q: Oh so the data model is prepared for it?
• A: Yeah exactly. So if you want to report on SLA hit rate per customer, boom there you go, its just there.
• Q: But do you have a list of these of these KPI which are ready out of the box so to say?
• A: I don't know them by heart, but it should be in the documentation, like SLA hit rate, travel time and so on. They are there.
• Q: Could you share this with everyone?
• A: Yes absolutely.
  If I may just add to that, it's not just the KPI which are available as a summary statement. The Schedule Archive actually contains the entire schedule, so you are very much capable of building your own KPI’s, things we didn't think about. The main point is anything which PSO knows about is available for a consumption, by a power BI report and then it enables you to create great things.
• F: I'm very interested in the KPI's I don't know about so to say. And that is why I'm interested in this list because it's quite hard sometimes to figure it out ourselves. So if we can get that list, it would be great.
• F: So, if we get could get in one of these sessions, maybe to exchange a bit what different companies are tracking in terms of their KPIs around planning optimization? Because we had a discovery session on schedule reporting and it's super interesting. There's plenty data in there, but I think it's always good to get a bit of a guidance on, OK, where do we start, what would be the recommendation of the data that we should start looking at.

• Q: I've a couple of questions, but maybe starting with first one. What I'm missing here is to bring this Optimization and Planning into success or making the most of that. One thing is to involve the customer because that will come up, maybe a lot of changes if you see engineers you haven't seen before due to route optimization. And the other thing is getting rid of old restrictions. What do I mean with old restrictions is, if you have relationships between customers and engineers, or a group of customers, or forbidden customers, or skills or whatever, we have so many restrictions that is almost impossible for any dispatching tool to make the best out of it. And my question is more to the audience if maybe somebody else has experience in that and how they get rid of this situation?
• A: One of the slides talked about (Slide: Successful Optimization Implementations) what you need to do in advance and during the project and if we went back to that slide, they are very, very important points that he's put there, those points about what you need to do and what you don't need to do. Now, first of all, regards talking to the customer, you do absolutely need to take your customers on the journey with you because they will notice an impact and they'll notice it in many ways. When you've got manual scheduling and when you're scheduling with people and roots and places like that, you often find that you end up with personal relationships being formed. So, you might have controller that's friendly with an engineer, who in turn is friendly with a group of places and they end up over a number of years creating their own patterns. And some of these patterns become the norm and the accepted way of practice, and we've always done it that way and legacy process, et cetera. And if we set the system up properly, it'll actually chip away at those and you'll start seeing different engineers going to better places more efficiently, better routing, etcetera. So, they’ll notice it from maybe different engineers turning up maybe more timely things like that. So, they're going to notice. Another way they're going to notice is your performance, the SLA that you offered them will ultimately get better. And one of the SLA’s someone mentioned it earlier, one of the things that we notice when we implemented it was that our outcome improved considerably. Our SLA’s improved, our downtime dropped and things like that. Now they are going to notice that as well. However, when you first go live, there's bound to be the impact, because you're going to have people using the system and some of these people are going to be strong personalities who claim to have been using the system for many years, and know the system better and there's nothing can beat the system, I'm better than this and that sort of stuff. And they're going to try and fight against it. And the biggest issue with the system is the people problems trying to fight against it because there are suspicion by people that they can do it better. So, we took the customer on a journey and said you're going to notice a few things. You’re going to notice maybe different engineers attending some of the sites, you might notice a drop in our performance and then we hope a big improvement. You're going to notice that you might get engineers, believe it or not, leaving a place if there's multiple faults there of different priorities, you might get one engineer or two engineers leave and join because the system is so much more. I can set it up to say, he'll go to one place and stay all day long if you want. But if you're SLA driven, it might be that it will send an engineer to a place and then someone else will leave and come and go like that because you're serving the bigger, bigger thing. So, consulting the customer is absolutely the best thing to do.
• With regards to your restrictions and things you said in place. A lot of these restrictions and things you have in place are actually stuff that people have put in themselves. The customer putting it in themselves and a lot of them are, we've always done it that way and that's the working practice and that's the SLA, and that's the way we've done this and that job there and all that. And what we did when we started putting the system as we started working and chipping away at those and saying, is that really an actual proper valid thing? Is that really a restriction? Why are we doing that? Do we actually have to log on at every place? Do we actually have to go to every customer? And it was hard work and also understanding the SLA’s, this one here where it said benchmark current performance and SLA's and things, understanding your current SLA’s is really important so that you know why you're doing stuff. So yeah, I would say that although you've got a lot of constraints, I'm going to bet that probably 30% of them at least are just legacy stuff that when you scratch the surface, you'll realize it's just done that way because you've always done it that way and that you can just get rid of them and just be brutal about them.
• Q: I'm absolutely with you. We are not that much SLA driven, not on most of the customers and I think you can convince most of the customers by saying you will get a faster service than before. You will have higher capacity on your assets and so on and so on, but this is what we know with another dispatching tool we are using for many, many years, which is maybe similar to PSO. For one question, I have no answer. This is the psychological aspect of the engineers, because the answer is always, especially when you're talking to more west countries, that if I do not feel responsible, this is my customer. This is my essence, then the motivation level gets down and that is always a problem where we do not really have a good answer on that. So, I'm not sure if we have the only company on that?
• A: We had engineers that refused to go to certain places because they didn't like them. And then we had we had others that wanted to go to certain places because they liked them. And what we had to do was, we had to change the mindset and explain to them that what they're actually doing is they're not directly serving the customer, they're serving the customers customer, and they're making a difference to a lot of people. And what they’re actually doing is making a massive impact. We do transportation systems to the general public and putting their egos aside like, oh, I like going this place and that, and actually thinking about the bigger picture. Now, you're always going to have a bell curve of engineers. You're going to some who are ambivalent to everything and the other end you’re going to have those that really, really militant, and you're never going to change that. But if you do get a couple of the key influencers on side, a couple of the key personalities on side in each of the areas, it won't take long for it to filter down because you often find that it's like the herd mentality, the lead cow follows, everyone goes with them. So, just get them engaged, get those key stakeholders as key champions. Those key people and get them involved early and get them a part of the decision process. If you utilize some of the functionality and it's closely related with how they've suggested the system should be used, call it their name. Say, oh, this was the John Smith functionality and then he'd go off and say, oh, they set the system up and they are calling it my name and all that. It's a mind over matter sort of thing.
• R: I've shared this example I believe in this group before, but last year at our event, Future of Field Service event in Birmingham, another PSO customer for IFS spoke and I thought it was really cool that he shared that one of the ways they have helped manage the change and make the shift more palatable for their technicians is to figure out how to give back to them. So, they allow their technicians to choose their start and end time each day because the tool will sort everything else out. And that was a way to put a positive view on it for the technicians. Some want to start early and be done to pick their kids up from school. Vice versa, that sort of thing. But I think that combined with what was said earlier, it's really just digging into your specific scenario and figuring out, how to personalize the situation and that sort of thing.
• R: A long along those lines, I've heard many customers argue with their end users or technicians specifically around the fact that back office and dispatch will now get more capacity, which means that you as a technician will be able to get more service from your back office. You can thereby also assume that your parts will be planned for all of your jobs, all of the access will be cleared. Back office will have fixed that for you because now we have time to.

• Q: Some of our folks are just worried, hey, what's going to happen to my job? Because that's the fear with automation and I really enjoyed that slide where you're saying you're focusing on those exceptions as opposed to 99 percent of the stuff that could be automated. So, we actually went back to basics and we said we want to get here, how do we get here by fixing this. So, if we can just work on this concept, we can build on it, and we are having that whole mindset change. So, this brings me into my one question. We talked about forecasting, so how would this tie into the funnel to quoting because that is one of our big issues, where we have emergencies, some clients don't necessarily have a contract or an SLA, but I need to know if that one resource is available or I have a big project coming up. So, would this drive those tentative replan mandates. Would that help me with this?
• A: In the forecasting, that's something you need to build in I think, as an additional source of unknown work which you know will drop into the schedules.
• Q: So, its not tied into the quoting tool or the business opportunity module or anything like that?
• A: No, it's not connected to sales or anything in IFS cloud, it's intended to be standalone.
• R: Just one comment on what you said though going back to kind of connect it to some previous points, I think one thing that's important to remember is that resistance to change is completely normal. It isn't an indication that you're doing anything wrong or you're not on the right path, or it isn't worth working through it. It's just human response, and I think to your point, if you can get to the root cause of where is that resistance coming from? Is it fear of losing their job? Is it that they really like a particular customer that they visit now? Is it they feel they have less freedom or autonomy? If you can identify the root cause, then you can figure out how to work with that and come to a resolution. But I think the emergence of those emotions and having to navigate those situations is something everyone's going to encounter because it's just it's human nature, it's completely normal.
• F: I totally agree. And you guys gave some great ideas. To reward the positive, I think it's a really, really good idea.
• R: Another thing that's come up along those lines, I did a podcast a while back with a woman who is a neuroscientist and wrote a book about the Neuroscience of Change Management. And one point she brought up that I really liked is, not only rewarding success but rewarding effort, because when you introduce something new, it's going to take time for someone to learn it and get it right. And a lot of the frustration comes in the efforts they're making that aren't quite to the success versus once they've achieved the success. So, if you can think about what ways you can reward effort, open mindedness trying, et cetera, it can help you get to that ultimate success that you're trying to achieve.

• Q: Regarding W.I.S.E and I know we worked before on the W.I.S.E demo that has been two years now. It would be nice if you could share some road mapping on the W.I.S.E just to understand what's coming. In addition to what was where we left off around one year or two years ago.
• A: So with the over the last over the last two years, there's primarily been usability improvements to the to the W.I.S.E. It's been more incremental. But we're what we're looking at now for the future, and that is in the design stages at the moment. So it's not something that is implemented, but that is things like ability to be able to define more KPIs, ability to be able to easier compare different scenarios side by side and understanding the impact of impact of those. That's some examples of what R&D are looking at right now.

• Q: We're on an implementation track of IFS. So obviously I'm very interested in this change management approach you shared on one of the slides and it's not on only one but on several, because obviously we would have to go through all of them. Looking at the implementation, very simple and I guess you will answer that with the yeses. We have expert services with IFS. Obviously, looking at who's around the table, any suggestion on how to approach this best? Starting small with the examples you mentioned in choosing champions, choosing an area, how to set up a test environment, would be obviously very welcome.  How would we do this in the most efficient way? Looking at the graph you presented on one of the slides, we have to go through all the stages to get the implementation done. I will look at it more from an IT point of view. I have a colleague on the call who is looking at it more from a business point of view. So, my focus might potentially be on getting a test environment setup, doing some benchmark checks on where we are. If we go from manual to automated, what are the benefits? Improvements. Whether on KPI’s or on service. Anyway, how would we best approach this? Starting small, obviously I'm thinking, but any input this is welcome.
• A: I mean I could talk for hours about this. I'm just going to sort of give you a couple of bits of advice. I'm going to park the infrastructure. I'm going to park that completely. I'm going to talk about the system setting that up because infrastructures you can talk technical with IFS about that. But the from our point of view, how we moved from the bottom to the right (Slide: Best Practises for manging the Journey) was first of all, we looked at our jobs, and the type of jobs we do and how they relate to the SLA, and we really understood the impact of those jobs. So the individual work order, you might come in for two devices. One might have this error. One might that error. How do they impact? How do they affect it? What's SLA? And then we actually looked at the contract and really understood the SLA and contracts and we did a lot of work, in advance of the system, which was actually proven to be really valuable because when we then we're ready to go, we had all that data, that important data about what is the activity, what is the SLA, what is the location, what are the travel profiles for it, what are the constraints about getting into the place, the opening times. We had all of that information there for the job, and we had our templates of SLA, so that was the first thing, and I think doing that bit of work up in front really helps us. Because when we then got into going through from 2 to 3 on this diagram here, we modelled the data that over and over again, and then we went live with assisted. Dropping in on a daily basis and watching it and comparing it to live with one of our key customer, but it's one of the smaller customers. Now, because if we put that work in advance, we were really quite pleased that the system started optimizing how we hoped. It wasn't perfect and continuous improvement is incredibly important, but we hit it pretty close first time. So, our activities that we would expect them to be P1’s were P1’s and they were scheduled out we thought they were going to be in. Our activities that were generally the bread and butter ones if you like, the important ones that need to carry the weight of the business, they were getting dealt with accordingly as well. So, for us, I think the simple best thing to get you through this path is to absolutely understand the data that you're going to set up in the system. And the other thing is, that most of the data we set up were hard constraints to start with. We didn't set up flavors of skills. We said that they had the skill or didn't have the skill and things like that. And that made it a lot easier as well. And with continuously improvement, we've added flavours to them. But to start with, we stuck to hard constraints so that we understood the parameters, the system was able to do with the parameters very effectively and because we put the hard work in, it meant our transition through from well 2 to 4 in the slide happened pretty quickly, within the matter of weeks.

• Q: So, we implemented PSO relatively recently. We implemented, we went live in January, so we're into two months into our PSO journey. And where I struggle a little bit is not so much with what it's good at, the service automation, the SLA’s, the commits, the skills, the rosters, etcetera, all of that is logic driven and when it comes to logic driven, we're good. It's where I think the organizations executive expectation versus reality for a company that's relatively complex. So, our company is complex in that it does both project and service work. About 60% of our total dispatches are project work. It’s scheduled this months in advance. It’s sometimes overnight, sometimes it’s during the day, sometimes 8 hours, sometimes 10 hours, sometimes 6 hours. Sometimes dependency sometimes not. It gets complicated, and where we were hoping that PSO would really help us out as automating also this project schedule. So let's say a customer comes to us and says I need 1000 stores. They only have 600. I need 600 stores updated with new registers and we go OK, great. We'll do that over a period of three months. The installation happens overnight, but I can't keep my technicians 24/7 available, right? So, my technicians schedule needs a certain baseline, otherwise it just drops 24 hours worth of work in that first day, and my technician won't be happy with that either. I'm struggling with the dynamic nature of the PSO engine, in where I would like it to recommend what schedule my technician should be working, not just apply to baseline calendar and drop a job within that calendar, but also OK. I have an overnight requirement so one of my 10 technicians in New York City needs to do an overnight shift this week to meet that schedule, but then when the job runs over right, how do I really get the best out of their calendar? It seems that it's pretty good at managing the day-to-day intake, new job availability plus matching skills, and assigns the job. But when it comes to really applying some intelligence, and perhaps even some AI aspects to, now what does my technician schedule look and how do I really optimize their schedule? That's where I'm lacking, and that's where we're struggling, but also to spread the jobs out right because the project can take place over three months. But I don't want to schedule all jobs in first week, so I need to stagger how many of those project jobs I allocate per week if you will. I'm wondering if it really was meant towards service and not so much towards the project side of the world, but I'd love to hear some feedback if anybody else has solved them. I'm hoping I'm making sense. It's a chaotic problem.
• A: I was waiting for some other customer to chip in with their experiences, but I think you made a couple of really good points. PSO was designed for high volume services to begin with, but later also evolved into being able to handle multi day type work and assignments and so on. You made a real interesting point there in like, OK, PSO is great at optimizing, given the business constraints that I have. One of those constraints being how my rosters currently look like. Couldn't PSO also tell me how to set off the rostering? Give them the work I expect. That is something which I personally think that we should look into for the future, to not only optimize the operational schedule, but also optimize the modelling data that builds up the optimization. fantastic key point. Then where it was a project that activity scheduling, I think that is that is very unique to your implementation and setup. How that should be solved, whether you stagger the work by having SLA’s for certain time periods to split up the project into smaller chunks, how you want to do that, there's many ways that could resolve.
• F: So right now, we're manually manipulating the time commit to say you know start and commit date. We're staggering it from that level, but that's basically the same as they can in Excel sheet and dropping names on to it. When it comes to the project optimization, the project work, the staggering, the curve of the project implementation, multi site, that's where we're really not seeing the benefit just yet. Service is great, right? But service is again logic driven, vanilla, SLA driven, waiting driven. I'm not going to say it's easy, but it's easy, right? It's an easier logic to apply.

• Q: We are on the journey to implement PSO with IFS cloud. I caught somebody saying that PSO was designed to handle high volume schedules and I was wondering what are high volume schedules? Because this is a topic that's really top of mind currently at our side. We're getting contradictory information when it comes to volumes. One time I get feedback saying your volumes of your company are likely too high. The PSO engine will not be able to schedule optimize your volumes effectively, so need to downscale or you need to change that. So typically in terms of high volumes, what are we talking about or maybe in the community here? What are your volumes that you're currently pushing through PSO? Maybe the dynamic scheduling engine and also the appointment booking engine maybe? Any feedback on that that would be interesting for us.
• A: First of all, I think that the official documentation has performance benchmarks for up to half a million activities in the same schedule. Just as a benchmark in the same in the same schedule. That is the performance benchmark by R&D, then it is of course individual to your scheduling problem.

Podcast Link:

The Neuroscience of Leading Through Change

https://www.futureoffieldservice.com/2023/02/15/the-neuroscience-of-leading-through-change/

Next Meeting: 17 April 2024 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 do not have the next meeting invitation to this CollABorative and would like to join, please click here to fill out the form.