Rethinking Self-Service starts with a simple change of perspective: Self-service projects rarely fail because the technology itself does not work. Scanners read barcodes, terminals process transactions, payment systems authorise payments and software manages the individual process steps.
Yet many projects still fail to deliver the results originally expected in day-to-day operation.
The cause often lies much earlier in the project: Decisions are made before it is clear how the overall system is supposed to work. Which technology should we use? How many devices do we need? Which supplier should we choose?
These are important questions. But they are asked too early.
Because self-checkout, self-scanning and other self-service terminals (SST) are not about a single device. Nor are they simply about software or IT infrastructure.
Self-service is a system – not a standalone solution.
Rethinking Self-Service: Technology is only one part of the system
A self-service system brings together a wide range of requirements. Customers need to understand what they are expected to do. Devices require space, power and data connectivity. Product and customer flows need to work. Staff need to support the process and intervene when necessary. At the same time, commercial objectives must be achieved and risks kept under control.
A decision made in one area therefore almost always affects others.
Industry research also shows that checkout is increasingly evolving from a single transaction point into a connected operating model that combines technology, processes, staff support and customer experience (see Diebold Nixdorf: Checkout of the Future).
If, for example, the number of self-checkout terminals is increased, this affects much more than the investment itself. The available floor space changes. Walking routes and customer guidance need to be adapted. Staffing and support requirements may change. Network and power infrastructure must be dimensioned accordingly. And the security and control concept also needs to fit the new situation.
Anyone looking only at the device is therefore seeing only a small part of the overall project. Which self-service solution is right for which store therefore depends on much more than the technology alone (see also Retail Engineering: Which Self-Service Solution for Which Store?).
Rethinking Self-Service means understanding the connections
This is where a fundamental problem arises in many projects: individual decisions may make perfect sense on their own, but together they still do not form a functioning overall system.
The consequences can become visible in many different ways. Processes become unnecessarily complicated. Customers do not understand individual steps. Staff have to intervene more often than expected. Areas that looked convincing on the plan work differently in day-to-day operation. Data is generated but not used consistently. Security measures are added afterwards instead of being designed into the system from the outset.
The result is often a self-service concept that works technically, but is not sufficiently aligned operationally.
The key change in perspective is therefore:
Do not start by asking for the solution. Start by understanding the connections.
The Multi-Level Approach: Five levels, one logic
The Multi-Level Approach (MLA) structures projects involving self-service terminals across five interconnected levels:
- Level 1 – Decision: Objectives, business case and the fundamental investment decision
- Level 2 – Structure: Space, sizing, positioning, customer guidance and operational support
- Level 3 – Connectivity: Infrastructure, data and analytics
- Level 4 – Usage: Usability, customer experience and accessibility
- Level 5 – Risk management: Fraud detection, loss prevention and risk management
These five levels are not a checklist to be worked through one after another.
They form one common project logic.
Decisions at one level affect the others. Layout influences usability and operational support. Usability affects process times and interventions. These, in turn, generate data that is relevant when evaluating the system. Security measures can change customer guidance and the way the system is used. And ultimately, all of this feeds back into the business case.
That is precisely why the five levels need to be considered together.
SCO zones are not an IT project
Self-checkout is often viewed primarily from a technical perspective. That is understandable, because hardware, software, interfaces and network infrastructure are visible and measurable.
But this perspective alone is not enough to make a project successful.
An SCO zone brings together investment, store layout, operational processes, customer behaviour, staff, technology, data and loss prevention. Accordingly, many different functions are involved in the decisions.
Self-service therefore becomes a business responsibility.
SCO zones are not an IT project. They are a management responsibility.
Not because every detailed decision should be made at management level, but because objectives, responsibilities and priorities need to be aligned across several areas of the organisation.
Significant investment, long-term operational consequences and clear accountability for results require an overarching view.
Success is determined before rollout
Whether a self-service system works in day-to-day operation is not decided only after installation.
Many of the prerequisites are established much earlier: When defining objectives, analysing the starting point, setting the project scope and deciding which interdependencies need to be considered during planning.
The later structural weaknesses are identified, the more difficult and expensive they become to correct.
That is why an MLA project does not begin with the question:
Which technology do we want to use?
It begins with:
What do we want to achieve and what structure do we need to achieve it?
This leads to the central principle of the Multi-Level Approach:
Structure first. Invest later.
The following articles in this series will show how this logic can be applied step by step to a self-service project – from the initial objectives and business case through structure, data and usage to risk management and end-to-end project ownership.
