What's New from Limble: Product & Partner Showcase

Hi, everyone. Welcome to the Maintenance Hero Summit on the product section, and my name is Jason Penckithman, the chief product and technology officer. And joining me is Lauren McCarthy, the VP of product. Lauren's responsible for product strategy and the road map, and so she's gonna walk through a lot of detail with you on all of the investments and great updates we have on the product side. And I will jump in later on to talk about some of the technology investments that we're making to enable some of that.

Hey, everyone, and thank you, Jason. I am Lauren McCarthy, and I lead our product management and user experience teams. Also, apologies. I have a bit of a cold.

So if my voice is off, I cough. I need to drink water. Apologize in advance, but, you know, we've all been there. I'm excited to share what's new from Limble.

In addition to new faces like mine and like Jason's, we have a refreshed focus for our product based on how we can better serve you as needs and demand shift and as technology evolves. We'll talk a little bit about it. I'm gonna walk through what we're seeing and how we're addressing in this session. But before we get into all of that, I'm gonna give you a little bit of a peek behind our product road map and product development curtain.

I wanna take a minute to explain how we build what we build. This is a group of builders and engineers, so I have a pretty good hunch you'll appreciate knowing how we build things at Limble.

I know that I personally love coming to see you guys at your locations and seeing how you build things and and just seeing the entire operation. So I thought you might appreciate seeing the structure behind how we build our products at Limble.

But first, I wanna thank all of you who have taken time to provide constructive feedback about your Limble experience, the good, the bad, the ugly. Sometimes, the really ugly, but oftentimes, very lovely, very kind, and very constructive.

We read it all. It may seem sometimes like it's going into a black hole, but I can a thousand percent assure you it's not. We read your feedback. We consider it as part of our planning process. It's actually critical to this process that's outlined on the screen.

So we follow this sort of cyclical iterative process that really starts with that feedback. Your feedback, your challenges, but also the opportunities we see for all of us and for Limble within this space. That starts off our ideation.

From there, we work through to make sure that the product functionality is thoughtfully designed so that there's no friction in your day to day work, or we reduce whatever friction you have. As the team builds it, we test it just to make sure, that the the capability or the feature or whatever it is is working properly, and then we release it to the wild so you can begin using it. And at this point, we continue to make sure we're providing value to you by evaluating your feedback, as I mentioned earlier, and also how you're using how you're using the application. And if we find that there's issues with something that we've released, we're gonna we're gonna take action and try to remedy it and enhance it or fix or address the core problem.

It's it's pretty simple, but I wanted to share that for following this process means we produce a better quality product that aligns with your needs and your expectations and where the market is going. So just just wanted to give you that peek behind the curtain. And over the remaining slides, we're gonna dig into what we see as opportunities within our space and how we're thinking about solving them. So this sort of set the stage for how we do that.

But that product is just discipline I mentioned on the last slide and how we build is important just because of everything that you do and all the important work that you are doing today in Limble.

You, and your organizations entrust Limble with seven and a half million assets, and there's 58,000,000 jobs that you've completed on that... Those assets. Because all of this work and related details and everything is managed within Limble, we have been able to celebrate your wins of reducing downtime and unplanned work. So, like, kudos to everybody for making some really nice progress. So together, we're tracking that work. We're tracking assets and parts better. So we're firefighting less, and we're boosting overall productivity. So win win.

But... Sorry. There's always a but. There's more that we can be doing.

There are still questions that you have and that we have so that together we can be more proactive and more predictive. I always kinda think of it as the three p's. We can be more proactive, we can be more predictive, and we can be more productive. We all wanna know why does this hydraulic press keep failing?

What critical asset may need to be replaced in the next eighteen months? And answering those questions requires data. Not just any data. We need data that's structured and consistent and, most importantly, trustworthy so that we can analyze it at scale.

And when you're managing thousands of assets, structuring how you name and define those assets matter if you wanna start predicting failure or extending the lifespan of an ax...

Asset.

Adding sensor data only enriches this, and that's something we're gonna talk about sensors, in a bit.

But, think about it. Right? We've all been in a rush to do something, so we quickly dash off a note in shorthand thinking we'll clean up later. Like, I am the queen of Post it notes all over my desk.

I'm like, yep. Just gonna write this down. I'll get to it later. Do I? Not always.

So...

But it's often we don't. But that quick note that might be jotted down in a work order now becomes history, that's missing essential context information. So infer...

That's information that might help the next guy or the next gal working on a...

On an asset, identify a potential issue before it happens. So it's a reminder to all of us to stop with the Post its as much as possible. When data is inconsistently captured or the right level of detail is missing, we tend to get stuck in this cycle of compounding data issues that results in more firefighting. If we don't know why something failed or what the resolution was, it's so much harder to plan.

Without the right preventative maintenance program, we're gonna end up with more failures. So we rush to fix the issue to minimize downtime, and then we might not fully log the right level of information.

The cycle continues, and the problem compounds.

So confession. This is the kind of stuff that keeps me up at night, and I probably... We all know I probably should get out more, but it's true. So I'm always thinking about kind of this pension that we have of how to preserve Limble's ease of use that y'all love with ways to make it easier to capture data more consistently. So we're gonna talk a little bit about that as we go through the rest of the slides.

And so what happens when that data isn't captured consistently or in a way that's easy to access is that we lose trust. So across the board, we have found that there is low trust in asset data due to these inconsistencies. And, unfortunately, the bigger you are, the less trust exists.

Part of this is we don't force a standard structure or naming convention today in Limble, and that's intentional.

And I think it's often seen as a really good thing. You've got the flexibility you need to configure Limble the way you need to according to organization's needs and policies, and we give you that. But sometimes that flexibility makes it harder to see consistency across multiple sites or across multiple assets. So the global leader can't look across multiple sites to confidently analyze downtime or failure rates. That's gonna become a bigger problem in terms of of data.

And that inability to plan and predict downtime is gonna result in sort of real costs. We see that when there's twenty to... Ten to twenty hours of unplanned downtime per month, it's estimated that's a cost of about a $100,000 or more.

So this low trust and incomplete or thin data issue isn't necessarily a hygiene issue. It's also a p and l issue.

So I said that this is keeping me up at night.

So...

But the challenge... So the challenge is on Limble to maintain that flexibility, to keep Limble easy to loo... Easy to use, and to make sure that you have all that trustworthy information needed to make better decisions. So the way we think about that is in three care... Key areas of the product that we're committed to improving. Number one, hands down, first and foremost, is the focus on the technician experience.

We live and breathe by making it simple for technicians to log information at the point of... At the time and the point of work. That is our number one priority.

If Limble is hard for technicians to use, they're gonna do like me, and they're gonna write things on a sheet of paper, and that work's never gonna end up back in Limble. So that's number one. Number two, we want Limble to connect to your other systems so they can work together, not against each other. Sensors can predict and drive work.

ERPs can help manage parts inventory so you have the tools you need on hand to do work. We really want you to have that complete holistic picture of your maintenance operations, and that's where sort of integrations and connected ecosystems come into play. And last but not least, the system has to be responsive. Right?

Nobody... Ain't nobody got time for a screen to load, right, especially if you're if you're trying to triage or respond to to a failure or an issue. So Limble has to scale to support operations across global locations and across thousands of assets, and we have to do it so it's responsive and performant.

I'm gonna share what we're doing in these three areas to improve performance and consistency of your data while supporting that ease of use that you guys value. So that's what we'll we'll walk through. Let's start with number one, the technician experience. As I said, this is our our... Really our number one priority and where we've focused a lot of attention over the last year.

If the data problem starts at the point of work, then where we're gonna fix that is the mobile app. Right? So that is where we we address the point of work. We've heard a lot of feedback, lots of feedback from you guys on the mobile app, so we rebuilt it from the ground up.

We focused on making the new app specifically for technicians on the floor, focused just on that user. It's designed to have fewer taps, faster screens. Right? No more sort of white screen and wanting to be responsive.

And there is nothing on the screen that a technician does not need in that moment. So we've really narrowed it down to to improve that user experience for the technician.

This is... The great news is it's available today. Right?

So we have rebuilt the new app. It is out in the wild. If you have not already, I highly encourage you during this webinar to download and install it from either the App Store if you're on iOS or Google Play if you're on Android.

And here's why. The new app has load times that are about seven times faster. It has that new redesigned home screen around sort of technician workflow and what technicians need to do. And there's also this novel idea that we have an offline mode that just works that configuration.

So if you're in a low coverage network environment, the app's not gonna lag. You're gonna be offline. Or if you're somewhere where there is zero coverage, right, then you'll still be able to do your work, and it'll sync up when you're back in coverage. As I mentioned, if you're not using the app yet, just...

It's easy to start using. Download it from the App Store. It's a new app, but you don't have to do any data migration. You don't have to do anything fancy.

You just have to log in with your existing credentials, and you can start using it. So I hope that you do that if you're not already. And we would...

As I mentioned earlier, we would love to hear your feedback because we we...

Again, we do read it. So your feedback's really important to us. We do have a bunch of customers that are using the app today, one of whom is PolyXcel. So at PolyXcel, with the new app, they were able to get 75% of their team working directly from with the app.

That means no more going to web, no more going to desktop, doing the work where they were actually doing the work and entering at the point of work. This is exactly what we wanted.

So, the idea is, again, capture it where you're working, not in notes app, not on my pink Post it notes, not in somebody's head. And so far, so good. It's working. At PolyXcel, what they've seen so far is that 50% less time has been wasted, and that means 30% faster repair time. So technicians are able to get their job... Get to their job faster. They're able to complete the job faster. This is because fewer taps on the mobile app means that work is getting done faster, and that work is getting captured within Limble so that it is available for all the data analysis we've talked to or the next tech who has to do any work on that asset.

Our core belief is that a better mobile app isn't a nice to have. Like, it's a foundational part of of the way you use Limble, and it's a foundational part of making sure we have the right data managed within Limble.

Alright. So that was number one. Our second priority is making sure that Limble is connected to your overall maintenance ecosystem so you have a holistic understanding of your assets. So you've got sensors capturing really rich information about real time machine performance, and sending that information into Limble is the difference between reacting to a failure or responding to a work order triggered by the sensor. That data captured by sensor supports overall asset life cycle and planning, So really valuable. The other integration we see a lot of is ERP integrations to support inventory management and purchasing so work doesn't have to wait for parts, and inventory is understood across multiple systems in real time, and you don't have to do any manual reconciliation across across, systems.

We're gonna keep investing in our integration ecosystem. We're doing it a couple ways. We're adding new integration partners. We're adding new standard integrations, and we're also building out the team of folks at Limble who build and maintain integrations. So that way, we've got more attention on our integration space.

APIs are the foundation upon which we can expand those standard integrations offered through our partner network or that you can even use to build your own integrations. We are investing heavily in API enhancements this year and into next year and really continuously. APIs are also the foundation to our MCP server, which we launched earlier this year. I'll talk a little bit more about MCP, but MCP puts analysis in your hands, and it can provide you with the tools to ask the questions we contemplated earlier, like which asset had the most downtime this year.

Again, that answer is only as good as the data supporting it, so we're gonna talk a little bit more about that as well.

As mentioned, we have an expansive list of integrations today, spanning ERP, sensor, and IoT, and other productivity systems and global information data. We're gonna keep investing in and expanding this list based on what we hear from you all, what we hear from our partners, what we see across the across the market. And this list is always updated on our website. So if you ever have a question about who we're integrating with, it's probably the best place for you to get the most up to date info.

And I mentioned our APIs, which are the foundation on which all of our integration work rests. And our APIs are getting a lot of new usage. Our usage went from about 500,000 to 1,400,000 calls, and, like, we love to see it. You all are taking Limble Data, you're building with it, and we hope you're doing amazing things. We encourage this huge. So we are expanding endpoints to reach deeper system data, more hardware and software workflows, and adding more bulk operations so that you can move larger datasets. This is an area of focus for us is how to put this sort of tooling and this data access in your hands so you can do more with it.

And I would say the newest and probably, in my biased opinion, the most fun part of our ecosystem is built on top of this expanding API infrastructure.

And that's MCP server, which I mentioned earlier. This is our third branch of our integration strategy. This is where and how we make it easier for you to ask the questions that you need to answer and eventually to take answer, take action on those answers.

So these questions might be difficult today to answer in a custom dashboard or a Power BI report. As we've discussed, this information might sit in lots of different places across Limble. It might be hard to pull in one place.

There might need to be some data massaging, but MCP is designed to make that easier.

Today, we have a read only MCP server. We plan to enhance what we currently have to improve the data it pulls on. Again, talk more about data in a minute, and then to take action on that data. If your query identifies that an asset is at risk of failure, our goal is that you can create a work order to have it replaced or serviced.

All from whatever you're using today that you're connecting to your... For an LLM like Clot or ChatGPT. So you're using a tool you're familiar with.

But any AI capability is only as good as the data that it sits on top of, which is exactly why we're focusing on our data foundation.

So everything that we just talked about is depends... Is dependent on accurate, reliable, and complete data and trustworthy data, as I mentioned earlier. We're making it easier for technicians to enter information. We're bringing more data into the Li... Limble ecosystem so it's more complete. This third priority is to make sure that the data works for you and not against you, and this is so you can use use it to drive forward those three p's we talked about, being proactive, being predictive, and being productive.

And and AI is a huge opportunity for our industry. I mean, it's, like, all we're talking about. I'm sure you guys too. 92% of leaders agree that AI needs good, complete maintenance data to work. And I I don't think that there's anyone that disagrees with this, but the big risk is that most of the market is pushing these sort of shiny new AI toys without necessarily fixing the data that sits underneath. So AI capabilities that are gonna return incomplete or inaccurate data aren't gonna serve you or market well, and it's gonna continue to drive that lack of trust. Right?

So this is something that we're we're very much thinking about, and this is where I would really love Jason to chime in here on what Limble's point of view is on all this AI work.

Well, thanks, Lauren. We believe that architecture is needed before we get into the algorithms. And so if you think about training, AI models on a decade of data that is just free text, you're gonna get a lot of maybe confident answers from AI that are just plain wrong. So we're gonna lose trust in the data. So what's important is that we start to build the foundation, the... That foundation layer first to ensure that everything we build on top of that from a product standpoint is gonna give you the trust that you need. So it might not be exciting to talk about some of the foundational investments that we're making, but I think it's really important to to address here because that's how AI is going to work at its best.

So let's talk about it. There are essentially three things that we focus on. The first is that we want to ensure that we've got normalized data that's structured really well. If we make the asset the central object and that everything else, all of the rest of the data is associated with it, then that will create a better architecture for for AI to run on top of. And we need to have consistent mapping for all of our data elements so that there's no hallucination that we would end up with, and we can trust the outcomes.

And, you know, I'm sure you've seen the same thing when you're running queries with AI. You've gotta provide the right context, and a lot of that is how the data is organized.

So... And finally, we want to have an architecture that internally has also a clean API layer. If we have a clean API API layer within the product, we can expose a lot of those endpoints and make them available to our customers. And then you can run MCP on that. So agentic workflows running on that data, running deeper into the heart of the product to get the outcomes that you're looking for.

So this is what those investments are going to look like in terms of the benefit for you as our customer. As I mentioned before, we're investing in the data architecture layer and the platform, and there's three areas that, you'll get... That you'll see these benefits. First is that we're gonna focus on the the user experience and how that will manifest itself for you is you'll see faster interface, simpler navigation. All the jobs that you're working on will be easier to navigate through, reducing a lot of friction. And that's one of the main things that we're focusing on, in addition to the performance.

The second thing that we're working on is investing more in enterprise level, functionality. So for customers that have multisite operations, you want to have views across those different sites. You also have more complex ecosystems. We want to build capabilities to be able to integrate into those more complex ecosystems and also the workflows that accompany them, you know, getting more complex too. So we wanna ensure that we're supporting that as your business grows, the product is able to support that growth as well. And then finally, the intelligence layer I talked about in the previous slide.

We wanna make sure that we have a data first architecture so that as you're running queries on the data, we can move into a predictive state where you move from reactive to predictive. And that is possible when you have the intelligence engine running correctly on that data, and we can automate a lot more of the workflows that you have and get to that point where you're reducing downtime and saving costs.

So that's the areas that we're investing. And now what I'll do is I'll turn it back over to Lauren, and she can get into more detail on some of the features that you'll see in in the product. Thanks, Lauren.

Okay. Thank you, Jason, for taking us through our data architecture and what we're working on there. Yep. We're building a new Limble, but we're gonna run it side by side with the Limble that you use today. The new Limble will look different. Like, just look at that simplified beautiful tasks screen and filtering and searching capabilities on it.

But it's the same account. It's the same data, and you can toggle back and forth between the two systems. We are gonna add new capabilities iteratively, and you can choose to adopt these capabilities as we ship them or or, like, or you can wait. Your customer success team is the best, resource to guide you through this as to whether you wanna, you know, take advantage of this iteratively or or just wait until we've finished building everything out. I'm pretty sure that you wanna know more about the three areas that Jason talked about on his slides, so I'm gonna drill into those, in a little bit more detail than he went into. So we spoke already about our investment in the mobile app experience for technicians, which is already out, and you have... While we... While you've been on this webinar, you've already multitasked and downloaded the app on your phone.

So I applaud you.

So we've already invested in new mobile app experience. But on the web app, we're focused on making task navigation noticeably faster. So we're focusing on the desktop now.

We wanna make that experience as fast and perform it as mobile.

What we're doing is we're streamlining the jobs that you do within the app so it's easier and faster for you to find what you're looking for. That task screenshot on the earlier slide is just a little teaser of how that is designed to make it easier for you to find information to search for completed tasks, open tasks, etcetera.

This means it's easier for techs and users to adopt and use the product without training or hand holding because we've made it a lot more simple and sort of obvious as to where to find information.

We believe that making Limble easier and faster to use is gonna result in better, more complete, and more actionable data entered. So that's sort of the first pillar of the three things that Jason spoke about. The second Is that we we all love the simplicity and ease of use of Limble as we've talked about. It's one of Limble's core strengths.

But we also need to make it work just as well for large large organizations with multiple sites and tens or even hundreds of thousands of assets. So for those multisite organizations, we're building in global governance so policies can be set centrally while each location can manage to truly local needs. We understand that there's a balance that needs to exist between sort of global governance yet local operations. That central global governance structure ensures that data can be organized organized and analyzed across the entire organization, but it can also be sort of entered and managed at the local level in a way that's gonna work for the users at the local level.

Open APIs and expanded integrations are gonna allow for Limble to connect with with... Within your maintenance and corporate ecosystem and paint a richer picture of asset health and maintenance operations. That's another area. And then lastly, like, normalized data, we've talked a lot about data, means that there'll be standard metrics across site. MTTR, MTBF data can be trusted from location to location or from asset to asset. And the outcome that we're aiming for here is one operational view without sort of custom configuration to manage or without a lot of different reconciliation or manual manipulation in order to see that operational view. That... That's our goal here.

And then I think what you'll probably wanna know is how does this show up? What does this look like? Like, when we think about what success looks like at the end of this effort, how does that show up? Today, what might happen is a ticket gets created after a machine stops working when there's failure.

Troubleshooting that failure will be based... Could be based on whoever remembered the last fix, or whatever information could be found within Limble. The cost of that work and digging into it is gonna show up as downtime and potentially even overtime.

When there's clean data underneath, the idea is that the work orders are gonna kind of right themselves with the right parts, the right safety steps, and the right checklist and instruction sets already within them. Sensors and anomaly detection are gonna flag issues before they become a failure, so you don't have to be firefighting as much. And that institutional knowledge, the kind that is at risk today of walking out the door when someone retires is gonna be surfaced to the technician standing at the machine because it's gonna be on their phone.

Every single one of those things depends on the foundation that we just walked through, which is why we have sequenced it in the way that we have sequenced it.

And then I think each type of user here is gonna see direct benefits from what we're doing in this new Limble platform. If you're a director, you're gonna see asset names that are consistently matched across every facility. So cross site comparison can be done without that manual reconciliation we talked about. This means you can forecast and you can plan based on a defensible asset history.

If you're a manager, this is gonna make your job easier to configure at once and have those settings apply everywhere. Compliance and PM reports may not need manual cleanup before you send them on, And then training and adoption should take your users minutes, not weeks. It should just be handed over to them, and they should be able to pick it up. And then if you're a technician, we've talked about this experience with mobile.

Fewer taps, don't have to wait on screens to load. Your asset history, your parts, your manuals are all available as you're preparing to do the work. It should be right all at your fingertips. Closing out a job should be just picking closure from a list and not writing a paragraph.

So it it sounds nice. Right? So here's how we're gonna deliver it all to you and what our plan is.

As we mentioned, the foundation is first. I think with this group of sort of engineers and builders and maintenance operations folks, we all understand the importance of a solid foundation to start. This is the work that knee... Is needed to be done to improve speed, data operate... Data architecture, global settings, ease of use, everything we just talked about. Good news is that work is happening right now and is gonna continue into the first half of twenty twenty seven. So that's that's where you saw the screenshot of the tasks screen.

Coming next is intelligence on your own history. So these are the work orders that might draft themselves that we talked about. We might see failure patterns that surface before the failure actually happens.

Better and cleaner asset history and documentation is available on on demand. This is where we can start to enhance our existing read only MCP and supercharge it, as we like to say. We cannot do this work as much as we want to because this is the really fun stuff, until we complete the foundational work. So we've gotta do the foundation first before we can start building, the intelligence on top of that.

The the later section, I don't wanna say last because we are always evolving, but the later the later group is comparison recommendation. This is where we might look at cross site benchmarking. So we're all competitive. Right?

Site a, how are they doing next to site b? And this is where also we might make, some prescriptive guidance. That later stage is later and third on a purpose. It's because that is only trustworthy when that...

Those recommendations and those benchmarks sit on top of clean, trustworthy data. So we'd rather be late and right to this party than early and wrong. We don't wanna further...

We don't wanna erode trust. We wanna make sure that the the right data structure is in place so that you all can be truly successful with with that intelligence and with those recommendations.

So I mentioned this work is already happening.

Good news. We've got a small group of customers who have been onboarded into a beta program today for new Limble. Again, this is a web experience. We already have mobile out.

These beta customers are running the new platform in their real environments right alongside their current level. So they are using new new functionality and current functionality side by side. This crew is helping to define what we deliver next. They're providing feedback on the overall experience. It's been super valuable, I will say.

Really, we value all the feedback that we've received from our beta customers. We're learning really quickly based on what they're sharing. And because of our product development life cycle I shared at the very beginning, we're able to iterate pretty quickly and pivot based on the feedback that we're hearing.

That said, for the majority of you guys here today, nothing's gonna change. You're gonna stay using current Limble. You're gonna be fully supported. Nothing changes with that relationship until we're further along with the new Limble, which will be, you know, as we get into, through the first half of next year.

And then we will share updates. We know we're gonna always share updates as we're as we're going along. If you want to be part of that beta group or you wanna test out the side by side comparison, please talk to your CSM. We are adding select customers on a rolling basis to that sort of early adopter period.

So we would love to understand if it's something you're interested in and if it's a if it's a good scenario for both of us. So just talk to your CSM and...

To learn more.

In conclusion, thank you so much for listening to all these updates. I really appreciate you taking the time to hear what Jason and I have to share. Thank you again for your time today. We really appreciate that you've spent, this time with us learning about what we're doing on the product end. If there's if there's one thing I hope you took away from today, it's that you should be downloading the new mobile app.

Think we put the hard sell, during this webinar to download it. But, please, if you're not using it today, we'd love for you to download it from either, the Google Play Store or the App Store, and start using it and let us know your feedback.

We're we're eager to hear what you think. The other couple takeaways that are important is we're working on this new foundation to improve data capture and help give you the intelligence that you need to be more predictive and to prevent downtime, and we're doing that now.

So that that foundation is being iterated. We're in beta now. If you wanna understand more about how you can participate early, we'd love to hear from you. Please talk to your CSM or your Limble success team, to learn more, and, and and we'll hopefully chat with you about it further.

And then definitely start digging into integrations. There's a lot of opportunity around bringing more data in to Limble to help give you that complete picture of maintenance operations. So we invite you to see where our integrations live and expand, your integration footprint if if that will help you on your end. Thanks again.

Appreciate all of you.

‍