This webinar is for companies who have deployed hundreds of connected devices, and now need to continue scaling into the thousands and perhaps millions.

Once you've deployed hundreds of devices, you've reached perhaps the most critical point in the IoT journey. Processes that work at this scale will completely fall-apart at larger scales. You will likely experience a host of service quality and usability issues which will prevent successful scaling if you don't discover and address them. So at this stage it is vital to put in place the tools and processes needed to measure your service quality, so you can drive up quality sufficiently to protect your revenue, control costs and enable scaling.

In this 20 minute video, DevicePilot CEO Pilgrim Beart provides a map for the journey, and suggests a "To Do" list of key actions to take at this critical stage.

WATCH THE VIDEO

Transcript

Welcome to this DevicePilot webinar "Beyond the Hundreds". Our audience today is companies who have deployed hundreds of connected devices - there or thereabouts - and are aiming at lots more.

The deliverables I'm hoping to give you today are:

1) a map showing you some of the things that you might need to do next

2) more specifically, a "to-do" list of a few actions you can take now, which will radically transform your prospects for success as you grow.

Congratulations!

So first of all, congratulations! Getting devices designed and built and into the hands of your first few hundred customers is a real achievement, and has taken a lot of hard work. So well done!

But this is also the point where it dawns on you that building it was one thing - but running it is another. And you've now got what will be - hopefully – an exponentially growing estate of connected devices that need to be run. You need to make sure they're working, you need to make sure they're delivering what the customer is paying for. And so there's still an awful lot left to do to achieve that.

The key point is that a connected product is a service. It's only valuable to the customer if it delivers - day on day, week on week - what the customer is actually paying for, if it's actually working. So that's a lot of what I'll be talking about today.

The challenges of Smart products

So you had some reason for connecting your product - it might be remote control, or live billing - there's tens of different reasons that people are choosing to make their devices smart, and that's great.

But along with that comes a whole load of other consequences of IoT - consequences of connecting your device. If the device is supposed to be online, then sometimes it will be offline. It will get misconfigured. It will have hardware bugs. It will have plenty of software bugs. It may even sometimes have the wrong version of firmware on it. You will have security issues - you'll need to do updates to address those. There may be physical issues, with devices getting damaged. There may be usability issues where customers don't understand how to use the product.

All these things - and more - can distract from the core value, and the core proposition.

You have to find a way to manage them, to get them under control, to eliminate them as much as possible, in order to deliver a quality service to your customers.

The Service Monitoring Maturity Curve

This is the "map" I was promising. We call it the "Service Monitoring Maturity Curve" and really it's a classic S-shaped technology curve, going through five stages:

1. R&D, which is fairly self-explanatory, the phase you've just come from.
2. Roll out - the phase you're in now, where you're deploying maybe a few hundred or a few thousand devices
3. Through the stages of inflection...
4. And growth, where growth happens really rapidly
5. Until eventually you saturate the market

We're going to have a look at a number of different 'dimensions' or aspects of your company that will change as you go through these phases.

People

The first one is the most important one, which is people. At some point after you roll out it will become apparent that devices aren't always doing what they should. Customers aren't always happy. And the only solution to this is to make sure that you have somebody appointed to be in charge of that problem, who reports to the CEO or the Board and has responsibility and the mandate to fix whatever the problems. They may have a title like "Head of Customer" or "Head of customer support" or "Head of Operations" or "Head of network" - lots of different titles, but essentially they are the person who is entirely customer-focused.

And over time of course they will lead a team of people. Now the important factor is that that team cannot grow in proportion to the number of devices you deploy! So if you go from 100 devices this year to 1,000 devices next year, the team can't grow by that same factor of 10. But it will still need to grow somewhat, and over time it will become structured. Usually the way to structure it is:

• you'll have a frontline team, which you call customer support. They deal with individual problems with devices or individual unhappy customers, often on a minute by minute or hour by hour basis
• behind them you'll have second line, which is sometimes called Operations. They're dealing with things on a slightly slower beat, of maybe a week or so. They're really looking at systemic problems that are occurring e.g. "we've got this issue with a firmware, that's occurring under certain circumstances, we need to triage that, we need to root-cause it, we need to identify how it's going to get resolved, and then deploy that resolution into the field". So they're taking a slightly bigger picture view of what's going on and building processes and so on.
• sometimes there's also a Product team, that are looking at the the overall proposition for the customer - what is it supposed to do is it doing, is it doing that? Feeding that back either into product evolution in field (releasing new features with software updates), or possibly into the next version of the product.

Processes

People do processes - at least to begin with – and the processes that the team will be using in the early days to support devices will be quite "ad hoc" and reactive, and in the very early days of roll-out that's absolutely fine. The issues that occur will often be novel - there will be things you haven't seen before, that you weren't expecting, and therefore you have no alternative but to just stick a human on the end of that and just react to whatever occurs and try and understand it, and try and make it good for that customer, try and "keep the wheels on", so you can continue on the customer journey, continue learning with that customer.

And that's absolutely fine - but that approach does not scale, for the reasons I alluded to previously. You can't grow your team in proportion to the size of your device estate. And if you try, you'll just end up in an awful "firefighting" situation, where your team is completely beaten into the ground with incoming requests, that they don't have the time to handle properly, and you're serving the customer really badly.

Because ultimately, dealing with every problem as though it's a new problem is just an incredibly inefficient way to behave. Over time you will start to realize that actually a lot of issues that occur - maybe as much as 80% or more will either have occurred before, or are entirely possible to anticipate. So for example if your devices have batteries, the batteries will run out, so that's something you could design and plan a process for, which will anticipate – deal with it and resolve it, and keep the customer happy.

So you need to move into a much more planned and orchestrated mode. You also need to become much more proactive. In that battery example, rather than waiting for the customer to call up and say "the battery's gone flat on my device", you actually want to be proactive – if you see the battery running down, you could perhaps dispatch a battery to the customer. And that transforms a potential issue into a really delightful customer experience, where the customer can see that you're ahead of the curve, you're looking at things, you're thinking about things, you're anticipating their needs. That can really develop a lovely customer relationship.

Ultimately, once you have a number of processes set up to detect and react to issues, you can then start to look at automating them. It's hard to automate them until you have defined them really well, but once you have them defined and you have people executing them, you can look at automating them. And to the extent that you can automate them, obviously you'll be able to resolve them much more quickly, leading to happy customers! But you'll also be able to lower your costs, because machines are basically cheaper than humans - and you should be spending your humans on the long tail of unusual or new problems, because humans are very good at doing that sort of thing - and leave the machines to do all the handle cranking.

Tools

People use tools to do processes.

In the early days, the tools you'll be using will be quite general-purpose, like sending emails to each other to track problems, or logging issues on spreadsheets. In those very early days, that's a perfectly appropriate thing to do - but it completely fails to scale. So processes which involve e.g. sending emails to each other will cause all sorts of dropped balls, where customer problems are just dropped between people and don't get resolved in a timely way. It's also very hard to keep track of what's actually going on - how many problems are you getting, how quickly are they being resolved and so on.

In terms of spreadsheets, as soon as a spreadsheet has more than about a thousand devices on, it just becomes very hard for a human to understand what they're looking at.

So you naturally tend to then move towards specialist tools. And an obvious one would be a ticketing tool or CRM tool, which helps you keep track of every issue, either per-device or per-customer or per-job, and track it through to resolution, so you don't drop the balls. There are plenty of off-the-shelf CRM tools out there which do that very well.

You'll also need a way to do triage - your front line team, your customer-support team, will need a way to triage problems: to turn telemetry into insight that helps them understand what's actually going on and what action needs to be taken to resolve a problem.

Above that perhaps your second-line people will also need a way to do performance management, to understand "how well are we serving the customers as a whole?", "where are the gaps?", "how big is the gap?", "Are we are we at 100% yet?". You won't be, so what are the drivers of all of those problems, and what should we do about them? Part of that obviously will be reporting - you'll want to be reporting internally to the company about how well you're doing and whether you're hitting your targets for quality and so on, and as you get large customers they may force you to report to them about whether you're meeting your service level agreement.

Metrics

Metrics are already something to do with reporting: In the early days your natural tendency will be to have quite technical metrics. An obvious metric is "uptime" - the device is supposed to be connected, it's supposed to be sending a heartbeat e.g. every five minutes, how often is it doing that across all of your devices? If you take the last week, what percentage of your devices were "up" for that last week? Is it 50%, 90%, 99% or whatever? It's a very useful number to measure, and there are a lot of things you can do to improve it.

But as time goes on you'll realize that actually it's not enough to do just technical measurements - it's necessary but not sufficient. You'll want to try and find some metrics which are even closer to customer experience, more commercial metrics. An example of that would be say we were deploying electric vehicle charging points into a parking lot: we've got we've got five charging points in a parking lot. If one of them is broken then as an EV charging customer, I arrive with my car… well I can't use that one, but if the one next to it is working and available, then I can charge my car. So although there's a technical uptime problem on that site, there actually isn't a commercial availability problem - there's actually 100% availability right now, because there's at least one charger available and working.

The converse of that situation would be that all of the chargers are working fine - so there's 100% percent uptime, no technical problem - but they're all in use. So the next driver to try and charge their car do so. That's not a technical problem, but it's certainly a commercial problem.

Net Promoter Score (NPS) is a classic way to measure customer satisfaction. It's usually done manually by asking people whether they'd refer you to a friend, and it's often done somewhat in arrears. It's quite an expensive process to do, and if - as you often can - you can find metrics that you can measure automatically which are highly correlated with Net Promoter Score, then that's a much better way of driving your business. You want metrics that are live, so you're not looking at the past and trying to steer yourself with reference to data that's now out of date.

And as I said, as you start to get large consolidated channel partners taking you to market then they will probably enforce SLAs on you. So you need to track SLAs – e.g. your performance over any given month.

Top Challenge

The top challenge that you're addressing as a company will change a lot as well over time. In the R&D phase obviously it's mainly the technical questions about your choice of technologies and actually implementing them.

As you go into rollout then obviously adoption is often a big question - we need to find those early customers to use the product, to pay us, to give us that feedback and show us what we still need to do.

And then as you go into the inflection and growth phases, then quality and growth tend to be the top challenges. They tend to be very interrelated actually, because it's very hard to grow without quality. If you have a problem where 20 of your customers are unhappy then if you try and grow by a factor of 10 you have 10 times as many unhappy customers, which will probably just completely drown you. So you need to get the quality up in order to grow.

But interestingly there's also a relationship in the other direction, because often you need to grow in order to drive quality. Because if you have say a hundred devices in the field, it's actually hard to get enough statistical data to diagnose and root-cause all of your issues. If you have a "1% problem" then that's one device maybe that's exhibiting that problem, and it may not be repeatable-enough, or you may not have enough information to really get to the bottom of it. By the time you've grown to 1,000 or 10,000 devices that one device has become a hundred devices, and now you're probably getting a lot more insight into the circumstances under which it goes wrong, which can help you understand whether it's a software problem or hardware problem or whatever.

Then as you start to saturate the market you'll probably become much more interested simply in your financial margin - in squeezing every last penny out of the proposition, and making yourself as efficient as possible.

So that brings me on to one of three things which vary more gradually as you evolve as a company.

Flexibility <-> Efficiency

In the early days you will tend to value flexibility a lot, because to some extent you're dealing with the unexpected. You're putting a proposition into the hands of your customers for the first time and you don't really know what you'll find. You may find technical issues, you may find propositional issues. So the ability to be quite flexible and quickly change things is really, really valuable to you. To some extent at any cost - you don't have that many customers to amortize the cost against, you're still learning, flexibility is great.

As the scale gets bigger and bigger you get much more confident in what you're doing: you get confident that the hardware is right, the software is right, the proposition is right. And what you get more concerned with is simply efficiency. And it actually gets easier to be efficient as you get more confident in the solution, because you can really nail down every aspect of it, and find ways to optimize what you're doing for efficiency. That's true in terms of technical costs, it's true in terms of team costs and everything else.

Focus: Build then Run

Another thing that changes perhaps somewhat gradually is your operational focus. So as I said at the beginning, in the early days you'll be really focused on building it: designing it, building it, getting your devices deployed into the real world, into the hands of customers. And sometimes it's hard to think beyond that - you just need to get those things out, and you'll be measuring yourself simply by shipping stuff. But that is absolutely not enough, that's not where the story ends - in many ways it's where the story starts for a connected device, because you then need to deliver an excellent service for your customers, day by day, week by week. So you go from focusing on build, to being focused on running it, and that becomes an exponentially-bigger problem that you need to manage.

Business model

Finally another aspect of the business that will evolve, and often quite gradually is your business model. If you come from an historical perspective of selling unconnected products (or "dumb" products), then you may have a business model which is a one-off sale. So if I buy an ice cream, I pay the money, I get the ice cream, I eat it and that's the end of it. But obviously connected devices are intrinsically not like that: they intrinsically deliver service continuously, and they have costs to support them - not just customer support but updating the software to deal with security issues or evolving standards or whatever. So there is intrinsically a cost in delivering any connected product, and therefore it's often a good idea to try and find a business model that matches that. And often you can, because you are delivering value on an ongoing basis.

The propensity to move to delivering things "as a service" is happening in the world generally, so instead of delivering making heaters you might sell heat-as-a-service, or comfort-as-a-service for example. So this is just happening in the world anyway, and it's extremely connected to IoT, because IoT is a great way to deliver it, and IoT - because the costs and value are delivered continuously - is just a natural fit for it anyway. So trying to find recurring revenue business models, more service-like business models, is often something that people want to do.

To Do List

So that was the map. The second thing I promised you was a "to-do" list, something you can focus on in the short term to really make your life easier. I've got three things to suggest.

1) The first one is simply to measure your service quality. You may you may have some idea of the kinds of issues that you're having, some sort of anecdotal information but really that's not good enough. We've seen plenty of situations where people have fooled themselves that a problem is the most important problem, it needs to be fixed and they spend a lot of time and effort fixing it - and then discover actually it was only really affecting 1% of customers, it's not that big a deal, and maybe they left another issue which is affecting half their customers. So when I say "measure", I mean actually measuring in numbers how well you're serving your customers, how happy your customers are.

2) The second thing is that once you've done that you can then identify and fix those issues and improve your quality, step by step, in a rational way.

3) And the third thing is being proactive. It's easy to say, it's harder to do, but if you come from a background where you wait for the phone to ring with a customer complaint, then there is so much opportunity to become proactive with IoT, to use that live telemetry stream to spot problems before the customer knows perhaps that they've even happened, and transform your relationship with your customer, transform the quality of experience that the customer is having.

There are massive benefits to your customer, but also to you of doing that - it can make you not only into a much better company in terms of the product you serve, but also into a much more efficient company that's really on the front foot. So it's really worth thinking about ways to start to transform yourself.

A little more about measuring service quality

On that first point of measuring service quality, just to paint a little bit of a picture around that… Ultimately what you're trying to do is measure how many customers are happy. The shorthand they use for that in the telco world is "nines", they talk about maybe achieving "five nines", which means that 99.999% of the time their stuff's working. Those are the kinds of numbers that telco can hit.

Frankly at the hundreds of devices deployed scale, we often see people struggle to reach 90%! And at a larger scale 99% is probably a more realistic target to hit. There's usually plenty to do to achieve those levels.

Once you're measuring that, you can then start to look at the gap and start to break that down. How much of that gap is being driven by software issues? by hardware issues? comms issues? Usability? and so on. And then break down each of those categories – "of all the software issues we've got, how much is to do with version 1.3's propensity to become disconnected when it gets too hot?". You can just relentlessly break it down, work out the root cause, work out how many customers it's affecting, what percentage of your uptime or availability it's damaging, and therefore prioritize it, resolve it, deploy the fix and nail that problem.

Conclusion

So I hope that's been a good - if slightly whistle-stop - tour of some of the things you might want to be thinking about as you go "beyond the hundreds". Obviously at DevicePilot that's what we do - we help companies through this stage and beyond with a suite of tools that can empower the customer support and operations team to deliver fantastic customer service, and we'd love to talk to you at any time.

Thank you.