The crucial interface in digitalisation projects

A prospective customer rings a medium-sized manufacturing company. They require custom-made transport packaging and describe over the phone what is to be packed, where it is to be transported and when it is needed. The office records the details and passes them on to the foreman. The foreman is familiar with the materials, construction methods and production capacity, but is currently working on the production line and cannot return the call himself. So his assessment is relayed back via the office. Later, the managing director receives the information and draws up the quotation.

At first glance, the process seems perfectly normal. Everyone involved fulfils their role. Nevertheless, the end result may be that an order is accepted for which the right materials are not available in time, or which cannot be slotted into the production schedule as planned. The consequence is not a spectacular system failure. Instead, something far more mundane – yet just as problematic for the business – arises: additional enquiries, unplanned coordination, time pressure and, in the worst-case scenario, a production bottleneck.

In digitalisation projects, the first thing people often discuss at this stage is software. A new form, a centralised application or automation is supposed to solve the problem. But before a technical solution is devised, it is worth asking another question: when is a process actually ready for the next step to begin reliably?

The fault does not lie with any one individual

It is easy to dismiss the problem described as a lack of communication. However, that would be an oversimplification. The office can only record what the prospective client says and what it is able to assess from a technical perspective. The foreman can only evaluate what is brought to his attention. The managing director can only make calculations based on the information available to him. The weak point therefore lies not primarily with the individuals involved, but between them.

With every verbal handover, a technical requirement is first turned into a note, then an interpretation, and finally a basis for decision-making. Some details may seem incidental during a conversation, even though they later prove crucial. Other details are taken for granted from the customer’s perspective and are therefore not mentioned at all. Furthermore, it often remains unclear whether feedback constituted a definitive approval or merely an initial assessment.

It is precisely these transitions that constitute organisational interfaces. They link different roles, levels of knowledge and areas of responsibility. Unlike technical interfaces, however, they are rarely explicitly described.

Technical interfaces have rules, organisational ones often have nothing more than habits

In the case of a technical interface, developers would naturally specify what data is expected, the format in which it must be provided, and how the system should respond to incomplete or invalid inputs. They would also define what output the interface returns and how other systems can tell whether processing was successful.

In day-to-day business operations, however, the corresponding rule is often simply: ‘Please let the foreman know.’ This can work for years, particularly in well-established teams. It becomes problematic, however, as soon as several people are involved, time pressure arises, stand-ins take over, or requirements vary from job to job.

An organisational interface should therefore be designed with the same care as a technical one. It is not a question of making every conversation bureaucratic. It is about making the information and decisions on which the next step depends binding.

Essentially, three things must be clarified: What information must be available, who makes the next decision, and under what conditions may the process be passed on?

A form is not yet a digital process

A digital form is a sensible first step. It can prevent key details from ending up merely on a piece of paper, in an email or in the memory of a single person. Nevertheless, a form initially only digitises the data entry. If the data submitted is subsequently printed out again, passed on verbally or incorporated into a quotation without being checked for technical accuracy, the actual handover problem remains.

A digital process only comes into being once it is clear what happens after the form is submitted. Who receives the enquiry? Who checks the technical feasibility? What details must be provided? What is the current status of the process? Under what conditions may a quotation be drawn up? And what happens if materials, capacity or information are missing?

The crucial distinction therefore lies between data capture and process logic. No matter how modern the interface may appear, without statuses, responsibilities and approvals, it merely replicates the existing workflow in digital form.

Five key elements of a reliable handover

Whether a handover works in day-to-day practice usually only becomes apparent when things deviate from the norm. This is precisely why it is worth explicitly describing its most important elements.

1. A clear trigger

A handover needs a clear starting point. In the example, this is not simply the first phone call, but the point at which sufficient information is available for a technical review. If this distinction is not made, half-finished tasks will circulate through the organisation and be completed anew by each person.

So the crucial question here, too, is: when is the task actually ready for the next step?

2. A complete set of information

Before handing over, it must be established which details are actually required for the next role. In the case of bespoke transport packaging, this may include the mode of transport, country of destination, transit time, internal dimensions, weight, quantity, desired design and any special protection requirements. Not every piece of information needs to be mandatory in every case. It is crucial to consciously distinguish between necessary information, helpful additions and points that can only be clarified jointly.

3. A responsible role

A process should not simply be sent to a department. It must be clear which role is responsible for making the next decision. In this context, responsibility does not mean that one person has to know everything on their own. It means that someone either approves the process, asks specific questions or forwards it to the correct department.

4. A verifiable approval criterion

Terms such as ‘checked’ or ‘feasible’ are only helpful if it is clear what they entail. A technical approval prior to drawing up a quotation could, for example, confirm that the requirements are technically feasible, that the intended material is available or can be procured, and that the desired production fits within the planned timeframe. Only then does senior management have a sound basis for setting the price and deadline.

5. A structured approach to handling errors

Incomplete or unusual enquiries are not a marginal issue, but part of normal operations. That is why the process must also function in the face of uncertainty. If a dimension is missing, a follow-up enquiry is triggered. If the material is unavailable, an alternative is assessed. If capacity is insufficient, no unrealistic deadline is promised. A good digital solution does not force such cases into an ill-fitting standard template, but rather makes them visible.

Figure: When is a process ready for the next step?

From a phone call to a verifiable process

So what can the company described do to ensure that a non-binding enquiry becomes a reliably verifiable process? A sensible first step is a guided enquiry process that takes prospective customers through the information relevant to an initial assessment. This includes, for example, the transport route, destination region, dimensions, weight, type of packaging and any special protection requirements.

The number of input fields is not the key factor here. What matters is that a free-form description is transformed into a shared, traceable data set. The prospective customer sees a summary of their details before submitting the enquiry. The office, technical review team and management can then all refer to the same baseline, rather than each creating their own versions of the order in turn.

This changes not only the quantity but, above all, the quality of the queries. Basic details no longer need to be repeatedly collated. Instead, the technical review team can focus on the questions that require expertise: Which design is suitable? What material is required? Can the desired deadline be accommodated given the available capacity?

The office no longer needs to reconcile multiple stages of discussion, and senior management can see the basis on which an assessment was made. This does not eliminate queries entirely. However, they arise where they are technically relevant, and no longer because basic information has been lost along the way.

For the shared dataset to become a reliable process, it also requires clear statuses. A sequence such as ‘Enquiry incomplete’, ‘Ready for technical review’, ‘Technically reviewed’, ‘Commercially approved’ and ‘Quotation sent’ may suffice to ensure a manageable workflow.

What matters is not so much the name of a status as the information it conveys. ‘Technically checked’, for example, must not automatically mean that the price, delivery date and material availability have also been confirmed as binding. A status should therefore indicate what has already been checked, who was responsible for it and what the next permissible step is.

This also defines how far the digital process should extend at this stage. However, a binding quotation should not be generated automatically from the inputs. In the case of bespoke manufacturing, feasibility, choice of materials and the level of effort involved still depend on experience and expert assessment. The digital process is not intended to replace this expertise. Rather, it is designed to ensure that this expertise is applied at the right stage and on the basis of better information.

Herein lies an often underestimated distinction: automation is not automatically the goal of every digitalisation project. Sometimes, the greatest progress lies in capturing information comprehensively, making decisions transparent and incorporating a binding checkpoint.

How to identify organisational interfaces within your own company

To do this, you do not initially need either a new platform or a comprehensive process model. Choose a process that frequently involves enquiries, updates or corrections. Then focus on a single handover and, together with the people involved, answer the following questions.

What triggers the handover? Describe the specific point in time at which a process may be handed over to the next role.

What information must then be available? Distinguish between mandatory details and optional additions, and avoid catch-all fields such as ‘Other’ if the same content regularly ends up there.

Who makes the next decision? Specify a role, rather than just a department or a distribution list.

How can approval be identified? Define what has been checked and what has not yet been explicitly confirmed.

What happens in the event of discrepancies? Specify who requests missing information, evaluates alternatives or puts a process on hold.

What information is currently being passed on multiple times? This is often the best starting point for digital support.

Taken together, these questions address three fundamental aspects of every organisational interface:

• What information is required,
• what decision needs to be made, and
• when may the process be passed on?

If these questions cannot be answered unambiguously, it is still too early to select software. The lack of clarity would simply be translated into data entry forms, notifications and access permissions. The result would be digital, but not necessarily better.

Not every handover requires a digital process

A structured enquiry process is not an end in itself. If a company offers only a few standardised products, if just one person decides on feasibility and price, and if missing details can be clarified without much effort, a telephone call may still be the simplest solution. Additional status updates, mandatory fields and approvals would then be more likely to create work than to save it.

Digital support becomes particularly useful where enquiries vary greatly, multiple roles are involved, or giving an early commitment could prove costly. A good indicator is information that is regularly requested multiple times, copied out or passed on verbally. Equally critical are decisions where, later on, no one can trace the level of knowledge on which they were based. In such cases, there is no need to reorganise the entire business. It is often sufficient simply to make this one handover more formalised.

Digitalisation should highlight friction, not hide it

Existing processes are often based on experience that has stood the test of time in day-to-day work. The office staff know the customers, the foreman recognises technical risks, and the management can put commercial decisions into context. A digitalisation project should not replace this experience with a rigid process. Instead, it should integrate them in such a way that relevant information no longer depends on chance conversations or the availability of individual people.

Small and medium-sized enterprises, in particular, do not necessarily need a completely new end-to-end system for this. Often, a well-designed enquiry workflow, a shared task status or a targeted extension of existing software is sufficient to begin with. However, this requires that the organisational interface has been understood beforehand.

Technical interfaces stand out when they are faulty. Organisational interfaces, on the other hand, appear to carry on functioning: people make phone calls, write notes and compensate for missing information through experience. The costs only become apparent later, for example through follow-up enquiries, delays or commitments that are difficult to meet in practice.

The most important interface in a digitalisation project is therefore often not the connection between two applications. It is the moment when responsibility, knowledge and decision-making authority are transferred from one person to the next. Anyone who structures this handover in such a way that information is complete, decisions are clearly assigned and a process only moves on when it is actually ready to do so lays the foundation for software to truly take the strain off.

Notes:

If you’re interested in further information on software development and process digitalisation, it’s worth taking a look at the website of Wils Solutions.

Would you like to support Nils Wils and discuss digitalisation, interfaces and clear handover procedures? Then please share this post on social media or within your organisation.