A kiosk workflow begins long before somebody touches the screen. The useful question is not simply which hardware to buy or how polished the first page should look. It is what the person needs to achieve, what the organisation must know, which decisions happen along the way and what should happen when the ordinary route does not work.

That distinction matters because a kiosk is only the visible part of a wider service. A customer may use it to check in, place an order, collect a ticket or confirm a detail. Behind that moment, staff may need to check availability, update a record, start another task, produce a document or resolve an exception. If those steps are disconnected, the touch screen can make the front of the process look modern while leaving the real workload unchanged.

The MillInsight Delivery Kiosk case study is one public Axisware example. It describes a touch-screen application connected to live orders, delivery records, weight capture and printed documents. The lesson is wider than that particular setting: a kiosk is most useful when it is designed as part of the process rather than as an isolated screen.

Start by describing what a person is trying to do in ordinary language. “Use the kiosk” is not the job. “Arrive for a collection, identify the right order and receive the correct paperwork” is much closer. For another organisation, the job might be to register for an appointment, find a destination, request a service or confirm that an item has been collected.

This description gives the project a practical boundary. It also reveals who is involved. The person at the screen may be a customer, visitor, driver or member of staff. A second person may answer questions, authorise an exception or correct information. Someone else may need a clear record later. Designing only for the person standing in front of the display risks hiding the work that surrounds them.

Ask four questions before discussing screens:

• What outcome is the person trying to reach?
• What information is genuinely needed at this point?
• Which decisions can the system make, and which need a person?
• How will everyone know that the task is complete?

The answers form the beginning of a kiosk workflow. Hardware and layout choices can then support that workflow instead of defining it.

A useful map starts before the first on-screen instruction. How does the person know they should use the kiosk? What reference, booking, registration or other information might they have with them? Could the system find the right record without asking them to type details that the organisation already holds?

Follow the route through the screen and into the work behind it. A selection may need to check a live business record. A confirmation may create a task for another team. A completed step may need to produce a receipt, label or message. If the person changes their mind or the information does not match, somebody needs a safe way to review what happened.

The MillInsight example describes two clear routes for drivers: starting a bulk delivery and finishing one after loading. It also connects those routes to live orders and delivery records. That is useful evidence of the design principle, but it is not a template for every kiosk. The number of routes, the information shown and the people involved should come from the organisation's own work.

Use a real recent example when mapping the process. Note where information came from, who checked it, what was produced and where the task paused. Then add one awkward example. A missing reference, an unavailable item or a person who needs help often reveals more about the design than the smoothest possible journey.

At the screen, each step should answer three simple questions: where am I, what do I need to do, and what will happen next? A busy menu may offer many features while making the immediate task harder to recognise. A clear kiosk workflow presents the right choice at the right moment and uses familiar words from the service.

Short instructions and visible progress can help. So can a clear way to go back without losing work. Where a person must provide information, explain what is expected before showing an error. If the system needs time to check a record or contact another service, say what is happening rather than leaving the person to wonder whether their touch was noticed.

Completion deserves particular attention. The person should know that the task has finished and whether anything else is expected. If a ticket or receipt should print, the screen should say so. If a member of staff must complete the next step, explain where the person should go. A vague “success” message can still leave somebody uncertain.

The visible route should also make help easy to find. Not every person will be comfortable with the screen, and not every situation belongs in self-service. A staff-assisted alternative can be part of the design rather than an afterthought.

An isolated kiosk often creates another place where information has to be copied. A connected kiosk application can instead read and update the business records needed for the task, subject to the organisation's rules and permissions. That might mean finding a booking, confirming an order, recording an arrival or creating a request for a colleague.

The connection should be deliberate. Decide which system holds the dependable version of each fact, when the kiosk is allowed to change it and how another person can see what happened. If a connection is temporarily unavailable, the organisation needs an agreed response. It may be safer to pause the task and offer help than to accept information that cannot be checked.

The public MillInsight case study says its kiosk uses live MillInsight data and keeps the touch-screen activity connected to wider operational records. It also describes optional equipment and manual alternatives suited to that particular installation. Those details show why kiosk software needs to fit the setting, but they do not imply that Axisware supports every device or that another organisation requires the same equipment.

For a new project, the better starting point is a list of systems and responsibilities. Which record must be read? Which result must be written back? Who owns corrections? Which documents or notifications matter? The Axisware software development approach can shape an application around those answers rather than forcing the process into a general-purpose screen.

Self-service does not remove people from the process. It changes where their judgement is most useful. Staff may need to see tasks waiting for attention, help someone find the right route, correct a mistake or reissue a document. If those actions require a developer or a hidden database change, everyday support becomes unnecessarily difficult.

Design the staff view alongside the public-facing screens. It might show recent activity, the current state of a task and the reason an item needs attention. Correction controls should reflect real responsibilities: a colleague may be allowed to fix a mistyped detail but not reverse a completed transaction without further approval.

Talk to the people who currently handle questions and exceptions. They know which situations occur repeatedly, which information is usually missing and which workarounds have grown around the process. Their experience can prevent the project from automating an idealised route that rarely survives contact with daily work.

This conversation should also cover the physical setting. Lighting, noise, weather, available space, screen position and the time somebody can reasonably spend at the device may all affect the interface. Involve people with different needs and levels of confidence, and test the proposed route in a setting that resembles real use. Specialist accessibility or hardware advice may be appropriate where the context requires it.

The ordinary route may be simple, but confidence often depends on what happens when something goes wrong. A person may enter the wrong reference, select the wrong item, arrive earlier than expected or reach a step that needs staff approval. A printer or connected service may be unavailable. These possibilities should be designed as part of the workflow.

For each important step, ask:

• Can the person safely go back or cancel?
• What happens if the expected record cannot be found?
• Can staff see enough information to help without asking the person to start again?
• Is there a clear record of a correction or retry?
• What should the person be told if the task cannot continue?

The answer is not always more automation. A clear pause and a reliable handover can be better than allowing the kiosk to guess. The aim is to keep the process understandable for the person using it and manageable for the team supporting it.

The MillInsight case study describes operator searches, corrections and document reprints as part of the wider application. It also explains that optional scanning and equipment choices can have practical fallbacks. Those are case-study details that require team review in this article, but they illustrate the broader point: recovery is part of the service, not a separate technical concern.

A first version does not need to cover every service. Choose one useful journey with a clear beginning and end. Build enough of the surrounding workflow to complete it properly, including the staff response and one or two likely exceptions. Then observe real people trying it.

Test understanding, not just whether each button works. Can the person explain what they are being asked to do? Do they know when the task is finished? Can a colleague see the result? What happens when the tester deliberately chooses the wrong option or removes a piece of expected information?

Record what the test reveals and adjust the workflow before adding more routes. This can help the organisation distinguish a layout problem from a process problem. It also creates a firmer basis for deciding which hardware, connections and administrative tools belong in the next stage.

A practical first-version checklist might include:

• one named user outcome and a clear completion message;
• the minimum information needed to complete it;
• one dependable connection to the relevant business record;
• a visible route to help;
• a staff view for support and correction; and
• agreed responses for the most likely failure or exception.

A kiosk should not be judged only by the screen people see. Its value depends on whether the whole task becomes clearer: the person's route, the staff response, the business record and the recovery path when the ordinary journey changes.

Axisware can design bespoke kiosk applications that connect the user interaction to the underlying business workflow. The MillInsight Delivery Kiosk is one public example of that approach in an operational setting. Another organisation may need a very different interface, different connections and different support arrangements.

If you are considering a kiosk, begin with one real journey rather than a list of devices. Contact the Axisware team to explore the people, decisions, information and exceptions that a useful first kiosk workflow should support.