The Process Map

Problem categories
If errors are recurring, they can be detected automatically by AI methods trained with historical data. When a new error occurs, the system searches for similar previous errors and links them together. This is how the categories or clusters of errors are created.

Typical data sources:

• Log files
• visual data such as images and videos

Typical data quality requirements:

• Validated data with time stamp

Solution categories
If the errors are clustered, the solution of a previous error can be reused as a template for a similar problem. This saves the technicians from having to search for the error again, as a solution is automatically suggested by the system.

Typical data sources:

• Records containing categorised errors and solution (as tags), including textual descriptions.

Typical data quality requirements:

• Correctness and accuracy of the tags,
• precision of the descriptions

Ticket-Sentiment
The automatic recognition of certain phrases in textual data allows conclusions to be drawn about moods, so that critical tickets can be identified and prioritized. Customer satisfaction can thus be increased. Similarly, the mood of all tickets can be monitored to identify changes in service quality. The recognition of critical texts can also be used to forward tickets directly to service staff so that they can personally deal with such tickets.

Typical data sources:
Service tickets with free-text fields formulated by customers

Typical data quality requirements:
Texts must be written independently by customers to accurately capture sentiment. Tickets written by hotlines or service employees do not fulfil this requirement.

Anomaly detection
Connected devices record environmental data via sensors and analyse it in real time. For example, physical values such as temperature, speed or even fluid and material conditions are continuously documented and visualised. Thresholds for problematic deviations are defined in advance. Using their correlations, a prediction is made via machine learning as to when a service case will occur. This is followed by a predefined process, such as a notification, an alarm or a complete device shutdown. Ideally, this happens at a time when serious errors or long-term failures can be prevented. A concrete example of anomaly detection is cathodic corrosion protection (CCP) as used at Service-Meister. This is a statistical model developed and trained with historical sensor data for anomaly detection. In the process, an AI algorithm identifies anomalies in the CCP monitoring and then generates targeted warnings.

Typical data sources:
Sensor data (water flow rate, electrolytic conductivity, PPS data, coil temperature, status of sensor electronics).

Typical data quality requirements:
Timeliness, accuracy, relevance, completeness, continuous availability, complete time series data. It is important for the CCP to be able to access as many sensors as possible in a timely manner.

Oscillation analysis
Vibration analysis is a special form of anomaly detection. It makes it possible to detect irregularities in complex machines by means of the vibration curve.

Typical data sources:

• Motor current, measurement position/speed and also acceleration.

Typical data quality requirements:

• Good signal-to-noise ratio.

Service demand forecasts
A) With the help of predictive maintenance, the optimal maintenance time of a machine tool can be determined.

Typical data sources:
Machine data

Typical data quality requirements:
Robust, high-quality data that must be representative of the use case and should include complete or sufficient time series.

B) Service processes also collect a large amount of data that enables predictions to be made about future service requirements. These can be analysed and linked to further data, e.g. from sales or production.

Typical data sources:
Ticket systems, service data

Typical data quality requirements:
Data should include full service operations and associated service needs. The more historical data available, the better predictions can be made.

Service histories
All service reports are stored in a knowledge database. These can be examined and evaluated according to a wide variety of aspects. Common aspects are, for example, particularly good service solutions or frequently occurring errors that are likely to have implications for product development. The results of the evaluation should automatically lead to new solution proposals for the service, which are then available to all colleagues via the cycle in the next service case.

Typical data sources:
Databases on which knowledge management systems are built

Typical data quality requirements:
Machine-readable data or documents

Learning system
The system learns, so to speak, from all the error detections and suggested solutions that the experts have created in the past.

Error histories
A) An AI application creates a history according to pre-prioritised categories such as: customer, machine, machine type and associated errors as well as solutions in chronological order. A manufacturer can collect statistics on the recurrence and severity of each error.br />
Typical data sources:
Categorised service reports with data stamp

Typical quality requirements for data:
Data categorised in the same way, which is necessary for the classification of errors and solutions.

B) Intelligent information retrieval for technical documents

Through image recognition of technical devices in combination with an intelligent search, documents relevant to maintenance and repair can be found and made available quickly and efficiently. This shortens maintenance intervals and reduces costs.

Typical data sources:
PDF manuals, certificates, quick start guides, technical documents, product images, product hierarchy information

Typical data quality requirements:
Structured and machine-readable basic formats

Manuals
Document analysis using AI offers service staff the advantage of quickly receiving solution suggestions via keyword search during an on-site appointment.

Typical data sources:
Machine manuals and data sheets, old service reports, training reports

Typical data quality requirements:
The data must be a text document (no screenshots), either a PDF or a Word document. The more meaningful and comprehensive the text documents are, the more targeted the proposed solutions will be.

Best practices
In a knowledge society, knowledge is one of a company’s most important resources. Building, using and preserving it i,s therefore, a central task of companies and a key to future, sustainable and economic success. Here, knowledge management systems provide access to extensive information about one’s own company. They should therefore be stored centrally in knowledge databases. A best practice focus is particularly suitable for illustrating and documenting this knowledge.

Typical data sources:
Manuals, best practice guides, FAQ lists and service reports

Typical data quality requirements:
All data-driven knowledge must be centrally captured or stored

Route planning
Once the schedule for a service technician or team has been determined, the route to the customer should be determined. It makes sense to automatically link a route planning tool used in the company with the customer data in order to always be able to provide the best route as well as alternative suggestions directly and without effort.

Typical data sources:
Address data from the customer database, histories of route planning to take account of special features (correct entrance for large companies), possibly also access data for technicians, and contact persons at the customer.

Typical data quality requirements:
current address data, findings from previous routes used

Team composition
Dispatchers work with planning boards. This planning can be automated via statistical evaluations or a learning system: In addition to the people involved, their skills, schedules and locations should also be taken into account. The data held in the databases are linked to other sources. In this way, suitable service technicians can be recommended at the same time as solutions to a technical problem.

Typical data sources:
Links to the employee database (if possible with skills and calendar data)

Typical data quality requirements:
Categorised data from the employee database, calendar data including deployment locations

Chat bots
Chatbots are typically used on websites and in instant messenger apps. As a helping chatbot, they enter into a dialogue with the user and facilitate communication with the respective IT application.

Typical data sources:
Knowledge Databases, Key Value Store (KVS). The KVS enables the chatbot to communicate with other chatbots or access other services.

Typical data quality requirements:
The content of the knowledge base must be adapted to the target group, the field of application and the purpose of the chatbot. The vocabulary of the virtual assistant should be formulated according to the target group.

Service bots
A voicebot helps the service technician to have their hands free to solve problems quickly and effectively on site. This could be, for example, a service bot that reads out the relevant step sequences from the service manual via a mobile phone connection.

Typical data sources:
The voicebot is based on a chatbot and uses Amazon Alexa.

Expert knowledge on site
With the use of AI-based allocation of service tickets (ticket dispatchers), service staff at the user help desk (UHD) or service desk have more time to provide support and advice in particularly challenging cases.

Typical data sources:
Tickets of a service management system.

Typical data quality requirements:
There must be historical tickets with corresponding assignment/solution.

AI-supported documentation
Customer data (e.g. service contract, prices of individual services and spare parts) are already linked when a service case is triggered. The service case should already contain solution steps via the solution category. After a service order has been completed, the technician only has to confirm the specification or describe any deviations via a free text entry, checkbox or bot. With the help of this information, an invoice or effort documentation is automatically created. This documentation can in turn be used after a check or automatically in the next service case and serve as a specification. At the end of a technician’s assignment, documentation is created with the existing or used data using an AI.

Typical data sources:
Linked data on customers, contracts, spare parts, technicians with hourly rates, prices, etc., preconfigured process steps for problem and solution categories

Typical data qualities:
current database links

Speech-to-text input
Voicebots access Amazon Alexa for “speech-to-text” via corresponding interfaces.

1. Service message:
Is there a service requirement at all? This initial question is at the beginning of every technical service process. If this is the case, it is necessary to find out what kind of service case it is. In this first module for technical service, precisely this initial assessment is made.

Analog process:
In the event of a suspected machine malfunction, the service center is informed. Service center employees assess the malfunction on the basis of further details and, if necessary, assign a service technician. The service technician then travels to the customer or machine with the information in order to carry out the service.

AI-assisted process:
Connected sensors record the measured values of a machine precisely, quickly and reliably. If these deviate from the standard, the AI application analyzes the values and checks whether it is actually an anomaly. Only then is this information about the deviating values added to the service lifecycle. The application also has the advantage that it, or what is known as predictive analytics, can be used to make predictions and calculate the probability of certain events or the behavior of people.

2. Ticket assignment
In the days of analog processes, people used to talk about a case management system, but today they only talk about ticket systems. Service cases are created, cataloged and prioritized digitally. Either the customer calls the service provider and is transferred from there to the call center so that the case can be recorded and managed. Or a message arrives by e-mail.

AI-assisted process:
These entire steps of a digital service case recording are omitted in an AI application, since processes are executed automatically, and information is processed independently. For this purpose, AI-supported methods known as natural language processing (NLP) are used and speech is analyzed with them

Typical advantages of a ticket system with AI application:

1. Recognition of key terms based on which error categories are determined
2. Finding possible solutions in the existing data
3. Localization of e.g. negative customer reactions and prioritization assigned
4. Updating of a ticket by always newly generated information

3. Deployment planning
A dispatcher must think of many things so that the service case can be carried out smoothly and to the customer’s satisfaction: Schedules, travel routes, technicians with appropriate skills, required spare parts, etc. An AI system enables efficient prequalification.

AI-assisted process:

1. The fault history of the customer machine and the machine type are compiled
2. Known solution procedures and measures are clearly summarized
3. Necessary spare parts are listed
4. The service team is selected according to the requirements of the service case
5. The appointment is automatically entered in the calendar
6. The route planning to the customer is created
7. The customer is informed
8. An information and solution package is added to the tablet computers of the service team

4. On-site processing
Any technician who has already replaced a roller bearing knows the complications that can arise. The module is located on the outer edge of the machine and is therefore difficult to access. It is also not helpful to view the installation on the tablet in advance as a best practice, since the unfavorable positioning of the roller bearing allows little insight.

In this specific case, it is helpful for technicians to be able to call up the chatbot app via tablet and enter the case ID. The bot immediately sounds via Bluetooth headphones and asks how it can help. One option is to have the technician read out the action steps from the best-practice instructions. The default setting here is that the bot waits after each step until the person on the other end of the call says the key phrase “Service bot: next!”. In this way, the technician can change the roller bearing in just half an hour.

5. Service reports
Creating a service report is a chore and time-consuming. The most time-consuming version of this documentation is to record everything on paper, enter it into a system and compare it with price lists or orders. Even though many companies have already made this process easier for their technicians with online forms, only an AI application brings real benefits.

AI-assisted process using the service report as an example:

1. Das Serviceteam beendet den Servicefall mit der vorkonfigurierten Dokumentation direkt online.
2. Based on the completed or only confirmed forms, the application automatically creates an invoice by independently linking the necessary information from the customer database, technician hourly rates, spare parts database or other connected sources.
3. The final product, i.e. the report or invoice, is simultaneously sent to the customer by e-mail and transmitted to the accounting department.

6. Evaluation
Evaluations not only have a statistical value, but also a company-relevant value. Expert knowledge, new and particularly efficient solutions, incidents concerning product features and warranty cases can be recorded and made visible to all employees and departments. The immediate evaluation and transfer to a knowledge database helps to derive implications for further cases or, for example, for future contract design or product development.

Platform
Here you can integrate selected services or link several of them in a targeted manner for an overall solution. You have the option of integrating them either via standardised interfaces in your own IT environment or in a special AI platform with the corresponding prerequisites and open standards.

Sensors, measurements, monitoring
We differentiate between phase 0 and the first step in the service cycle. With this, we want to highlight: Phase 0 is already a stand-alone field in the market “Predictive Maintenance” via “IOT” or also “IIOT”:
There are three steps in implementing such condition monitoring (= predictive maintenance):

1. Install sensors
2. Connect sensors via connectors to a system, e.g. via the cloud
3. Make measurements visible and monitor them

This is also called “condition monitoring” for maintenance and monitoring.

To differentiate:
With our AI modules for service, we go one step further. We want to relate further conditions beyond displayed thresholds and ensure in a self-learning system that a reported alarm (anomaly) is actually a service message. This is because faulty alarms are an enormous cost factor in many sectors of the economy. With self-learning and automated evaluation, this can be avoided, and money can be saved.

This is exactly what we analyze via AI in Module 1 Service Notification.