Every successful released product spreads around the globe. Older, more established companies are likely to already have processes and procedures in place to deal with service issues. Many leverage a combination of direct personnel, distributors, dealers and/or agents to deal with down machines in far flung places. Newer, less well-established companies may have no developed infrastructure for dealing with such problems.

Growing is Hard

When a company installs its first product at a friendly customer site, it’s easy to park a service person to deal with service problems. A second installation across town is not a problem … the engineer drives back and forth. But the third one is installed in a remote city, a two-hour flight away. When system #3 fails, the field engineer is dispatched to diagnose the problem, meaning an hour drive to the airport, a 90-minute wait, a two-hour flight, rental car, and driving. It takes 10 minutes to diagnose the problem. But the bearing that’s needed is not there. Then system #2 goes down.

Now scale that up to 100 systems in the field. Or 1,000.

Remote Service is Not New

Remote Access. The first viable commercial telephone modem was introduced in 1962 (the Bell 103).[1] For the first time, companies began using remote access to diagnose problems from afar. It required an analog phone line be installed for every machine in the field, and all the communication was point-to-point. Security was not assured, although security was far less of a problem in those days. The modem speed was abysmal by today’s standards, but it was possible to figure out many problems before dispatching an engineer. Although remote access was an advantage in every way, it suffered from the potential for human mistakes.

Telemetry. Modems also made it possible to get system telemetry back from the field. Although each system was usually not permanently connected, and the connections would frequently get dropped, a phone dialer could cycle around the fleet of deployed products, dialing one at a time, and download stored data. This provided companies with a primitive way to keep track of how systems were performing.

File Transfer. The advent of protocols such as the file transfer protocol (FTP) meant that the file system on the remote system could be manipulated, with files being uploaded to the service technician, or downloaded to the remote system. Being able to pull log files was a true benefit for remote diagnosis. Plus, as the baseline capability of operating systems was extended (from Unix and DOS to Linux and Windows), being able to push files meant that the technician could change a configuration or even download new software. Although file transfer was another significant advantage, it also suffered from the potential for human mistakes.

Remote Service. Most recently, the combination of telemetry, file transfer, and remote access has made remote service possible. This almost always involves a service technician typing commands into a terminal, as if he was standing at the console of the machine in the field. This capability is a real boon for companies because it means that problems can be diagnosed before a service engineer is dispatched. It may not be elegant, but it is very practical. But, as one might expect, remote service, too, suffers from the potential for human mistakes.

The Internet Changed Everything

As the world wide web developed, ethernet grew into a pervasive standard, and internet routers became commonplace, remote service shifted from telephone lines. The new bandwidths that became possible made file transfer of much larger files possible. Service actions over the internet became more real-time. IoT developed to make it easy to monitor simple process control parameters. And more robust, more secure means of remote access flourished.

Not surprisingly, the far better connections and connection speeds for the internet simply magnify all the benefits of the capabilities described above. But, as expected, along with the more widespread use of remote service comes the more widespread potential for human mistakes.

Finally—Service Automation

Service automation ties together these technologies. It is a powerful combination of remote access, telemetry, file transfer, remote service, all over the internet. But it has a huge benefit in that it mitigates a lot of the potential for human mistakes.

Service automation relies on predefined series of steps, where each step is a single command, such as “open a ticket”, or “upload a file”. Each series of steps is called a workflow. Workflows are created to perform series of steps that are frequent, complicated, or both.

Manual Task Automation

Suppose there is a commonly performed task such as “clear the log files and reboot the system”. A service technician may have to do this task quite regularly if it is a known mitigation for a problem. But any manual steps can be done incorrectly; for example, if the technician accidentally forgets to clear the log files, or neglects to reboot the system.

Service Automation allows a workflow to be created that never misses a step. By listing out those key steps in the correct sequence, the workflow engineer can ensure the technician cannot make a mistake. The technician simply launches the workflow.

Telemetry-triggered Preparatory Task Automation

Preparatory tasks are those that need to be performed before a service technician gets involved in the customer issue. A commonly performed task might be to “upload the three standard log files and the two configuration files to the cloud, then open a service ticket and set an alarm”. If the service technician must do this sequence of tasks each time a certain system problem arises, perhaps many times each day across the whole fleet the odds of something being overlooked or done incorrectly is quite great. It might also take a lot of that technician’s time.

If telemetry from the system in the field, such as an important error code, is received in the cloud, it can automatically trigger the running of a workflow that does these steps. It means, in this case, that the log files and configurations files will be in the cloud and ready to aid in the problem diagnosis before the technician is alerted to the problem, wasting less of the technician’s time.

Manually triggered Preparatory Task Automation

Telemetry is not always available to trigger these preparatory tasks. Instead, it may be a call from a customer that alerts service to the issue. In that case, the service technician can trigger the same workflow as mentioned above, then leave that workflow to do the required tasks. When the workflow is done, the files will be ready for inspection, and the technician will be notified that they are ready. While a telemetry trigger is preferred, this is still a big time-saver for the technician (as opposed to manually having to transfer a whole list of files), and it reduces the odds of human error.

Complete Service Automation

Suppose there is a situation such as “whenever the pump pressure is high, run the ‘flush filters’ process”. Let’s assume that “pump pressure” comes to the cloud as telemetry, as well as assume that there is a defined process of software steps for ‘flush filters’. then it is possible to create complete service automation workflow that actually solves the problem.

By creating a workflow that uses a condition that checks the pump pressure, plus defining the workflow steps that perform those software steps (from running a script on, running executables on, or sending messages to the system in the field), you can completely automate the workflow. A telemetry message of pump pressure triggers the workflow, which automatically flushes the filter. Problem solved, with no human intervention or human error.

There Will Always Be People

Automation is all around us, with AI and robotics in the news a lot recently. But surrounding all that high tech gadgetry are people. People are the glue holding the AI and robotics together.

Service engineers are still needed to solve complex problems, replace parts, and handle issues that were not predicted and that have not been automated. But for less complex, predicted tasks, Service Automation makes tasks easier and makes the reproducibility of the service process better, which increases quality and reduces errors. It improves the first-time fix rate (FTFR) and customer satisfaction (CSAT) and saves the service department a lot of money.

maiLink™ SRM software is a service relationship management platform that automates repetitive service tasks and helps you build a rich database about your installed devices. It seamlessly integrates telemetry from your products into a database rich with profound product insights. maiLink has no per-user fee—any employee you authorize can have access to the data. To learn more about maiLink software, visit www.maiData.io or email info@maidata.io.

[1] Bell 103 Modem, Wikipedia topic