“Integrated” Should Mean More Than a Logo

Start with the job you want the integration to do

“Does it integrate?” is too broad a question to produce a useful answer. Start instead with a task that happens in your business today and describe what you want to change.

Hypothetical example: an online food order arrives and a colleague currently has to read it from one system and enter it again at the till. The business wants to remove that duplicate entry. That gives a supplier something specific to demonstrate: place an online order and show what arrives in the EPOS process without somebody retyping it.

But follow the task all the way through. If the kitchen also needs the ordered items, permitted choices and a collection or order reference, transferring only the final monetary total would leave important work unfinished. The question is not merely whether data arrives. It is whether enough of the right information arrives for the next person to do their job.

Describe the outcome before discussing technology

Write one sentence for each problem you hope a connection will solve. For example: “Staff should not have to enter the same online order manually a second time.” Or: “When an item becomes unavailable, we need a defined process for preventing further online orders for it.”

Take those sentences into the supplier conversation. They are far more useful than asking for a general tour of integration features because you can test whether the proposed setup actually changes the work that matters to you.

Map exactly what information moves

An order is not one piece of information. It may contain products, quantities, permitted choices, prices, customer or collection references, payment information and other details relevant to your operation. Different connections may handle those elements differently.

Make a short list of the information your staff use after an order is placed. Then ask the supplier to show each item arriving through the proposed setup. Do not fill gaps with assumptions based on how another system works or how you expect an integration to behave.

Do not assume information travels both ways

A connection can work in one direction without providing the reverse journey. Orders might move from an online ordering platform into an EPOS process while product or availability changes still have to be maintained separately. The existence of one successful data flow does not prove another exists.

Ask directional questions explicitly. Does information move from the ordering platform to EPOS? Does anything move from EPOS back to the ordering platform? Ask those questions separately for orders, prices, availability, status changes and any other information important to your operation.

Hypothetical example: a pub discovers during service that a particular meal has sold out. Staff mark it unavailable in one system. The important test is what happens next. If the business also accepts orders through another channel, does that channel change automatically, require a separate update or follow some other process? The supplier should be able to explain the expected workflow for the proposed setup.

Manual does not automatically mean bad

Some steps may legitimately remain manual. That can be workable when the team knows exactly what the step is, who owns it and when it must happen. The bigger operational risk is assuming something is automatic when nobody has confirmed that it is.

If an availability change needs to be made in two places, put that into the operating procedure and assign responsibility. You can then judge the proposed integration based on the work it genuinely removes rather than the work you hoped it would remove.

Test changes, cancellations and exceptions

A demonstration built around one perfect order proves only the easiest path. Real service includes customers making permitted choices, staff correcting mistakes and businesses handling cancellations or refunds through their established processes.

Give the supplier realistic scenarios and watch them from beginning to end. Place an order with a choice attached to one item. Where the proposed setup supports the relevant workflow, demonstrate an allowed change or cancellation. Ask how a refund is handled through the applicable payment and ordering processes and inspect the records afterwards.

The purpose is not to demand that every action happens automatically. It is to discover what actually happens before staff and customers depend on it.

Follow the reference as well as the money

When several systems are involved, staff need a practical way to identify the same transaction while investigating a problem. Ask what order or transaction references are visible in the systems your team will use and how staff match them when they need to check an exception.

This becomes particularly important when an employee is deciding whether they are looking at a delayed update or a genuinely separate order. Establish the correct investigation process with the relevant suppliers rather than creating a duplicate transaction simply to make the immediate problem disappear.

Ask what happens when the connection fails

The most revealing integration question may be: “How will our team know when something has not worked?” A customer can have a confirmation while another part of the operation has not received the expected information. Staff need an agreed way to recognise and investigate that situation.

Ask the suppliers involved what a failed or delayed update looks like in the proposed configuration. Establish whether staff receive a visible status, error, queue or another form of notification, if any. Then identify who in your business is expected to check it and what they should do next.

If two suppliers are involved, also ask how support responsibility works. Staff should know which provider to contact first, what references or evidence to have ready and how the issue can be described without sending the customer between companies.

Write down the fallback process

Your fallback should be based on the documented processes for the systems involved. Record who checks whether an order exists, how its status is established and when another action is appropriate. Avoid improvising a new order or payment until staff understand what happened to the original transaction.

Compare the staff workload before and after

An integration should be assessed in terms of changed work, not the number of systems named on a compatibility page. Draw the current process on paper, one staff action per line. Then create a second version for the proposed connected setup.

Hypothetical example: today a colleague receives an online order, re-enters each item, checks the total and passes the order into the normal preparation process. In the proposed setup, the re-entry may disappear but staff may gain a new responsibility for monitoring exceptions. Put both versions side by side. You can now see what has genuinely changed.

Integration review checklist

• Write down the specific repeated task you want to remove.
• List the information staff need at every stage of that task.
• Ask which fields or details move through the proposed connection.
• Confirm the direction of each important information flow.
• Test a realistic order containing permitted item choices.
• Test how availability changes are handled across relevant channels.
• Ask how cancellations and refunds follow the applicable processes.
• Establish what staff see when an update fails or is delayed.
• Identify the references staff use to investigate a transaction.
• Record every manual step that remains after integration.
• Identify who owns those remaining steps during service.
• Confirm which supplier handles support for each part of the connection.

Get the actual scope recorded

A useful demonstration should become a clear record of what is being proposed. Ask for the supported systems or product versions relevant to your setup, the information expected to be shared, the direction of those flows and any manual processes your team will still need to perform.

Keep that information with the proposal and implementation notes. If either side of the connection changes later — for example, you replace an ordering platform or substantially change the way orders are handled — revisit the integration scope instead of assuming the previous arrangement carries across unchanged.

That is what EPOS integration should mean in practice. “Integrated” should describe a defined operational relationship between systems. It should tell you what happens to an order, a change or a problem and what the people running the business need to do about it.

A small connection that reliably removes one repetitive task can be genuinely useful. A much broader claim is difficult to evaluate until its boundaries are clear. The logo tells you where to start the conversation; the workflow tells you what you are actually buying.