When Connecting EPOS and Booking Software Makes Sense

Start with the duplicated work

Before asking suppliers about integrations or connections, spend a day looking at what staff actually type, copy and check.

Does reception copy a booking reference into the till? Does somebody enter the guest count in one system and then change it in another? When an extra place is sold, does the payment get recorded while the original reservation still shows the old number?

Write down each repeated step. That gives you a practical reason for considering a connection.

Do not connect systems simply because you can

Two products exchanging information is not automatically valuable. If the information being transferred is something your team never uses, the connection may add little to the working day.

Equally, a connection does not need to eliminate every manual task to be useful. It may remove one particularly repetitive handover while leaving another action for staff to complete deliberately.

“Judge a connection by the repeated work and conflicting records it removes, not by the word ‘integration’ on a feature list.”

Decide which records need to agree

Booking software and EPOS software may have different jobs. Rather than expecting every field to exist everywhere, identify the information that genuinely needs to stay aligned for your operation.

Follow one ordinary customer

Hypothetical example: a parent reserves a Saturday party for ten children and makes the required online payment. When the family arrives, reception needs enough information to identify the correct booking and understand the relevant status of that visit.

Now two additional children arrive. If the venue agrees to add them, the booking side may need an updated guest count while the sales side may need to record the agreed additional charge.

Those are related changes, but they are not necessarily the same record. Your job when evaluating a proposed connection is to establish what happens to each one.

The table is deliberately written as things to check rather than promises about how a particular product behaves. The answers depend on the systems, connection and configuration being considered.

Ask exactly what the connection does

“Does it integrate?” is too broad a question. Break it into actions that can be demonstrated.

Can reception identify or find the relevant online booking through the proposed workflow? Which booking details can staff see? If staff agree an additional guest, where should that change be entered? Does any related information move to the other system, or does somebody need to update it separately?

Then ask the same questions about moving and cancelling a reservation.

Separate viewing from changing

A system may be able to display information from somewhere else without allowing staff to edit it there. That is not necessarily a problem, but your team needs to know the difference.

For each important piece of information, ask:

Where is it created? Which system first records it?

Where can staff see it? Is it visible in one place or several?

Where should it be changed? Which system is the agreed source for amendments?

What happens next? Does the other record update, does staff action remain necessary, or is there no relationship between them?

Test changes, not just perfect new bookings

A demonstration in which somebody creates a booking and then finds that same booking elsewhere is a useful starting point. It is not a complete test.

Real customers change things.

Run the extra-guests scenario

Hypothetical example: create a test party for ten children using the supplier’s supported test process. Find it using the workflow proposed for reception. Then ask to increase the booking to twelve where that change is permitted.

Watch every action rather than accepting “that synchronises”. Which screen does the receptionist use? Where does the new guest count appear? If an additional charge is due, how is that recorded? Does anything still require a separate update?

Then make the scenario harder

Move the test reservation to another available date using the appropriate process. Check what happens to the booking information and ask whether any related sales action needs to be handled separately.

Finally, test a cancellation. Ask what happens to the booking, the availability that had been reserved and any payment action required under your own terms.

The important outcome is not that every step happens automatically. It is that staff know which steps happen automatically and which remain theirs.

Give staff one clear place to make each change

If the same information can apparently be changed in several places, ask how conflicting updates are prevented or resolved.

Avoid the twelve-versus-ten problem

Hypothetical example: reception changes a party from ten children to twelve in one system. Later, another member of staff opens a separate record that still says ten.

Which number should they trust?

Before going live, agree where staff make each type of amendment. Your procedure might say that reservation details are always changed through the booking process, while an additional sale is recorded through the appropriate sales process. The exact arrangement depends on the products and connection you choose.

What matters is that staff do not invent their own answer during a queue.

Write the manual steps down

If adding a guest requires two deliberate actions, say so. A short instruction such as “update the booking count, then record the agreed additional sale” is safer than letting staff assume the second action happens automatically.

Manual does not necessarily mean bad. Hidden manual work is the problem.

Use a complete demonstration checklist

Take your own script into supplier demonstrations. It prevents the conversation stopping after the easiest success.

Ask the supplier to perform the test using the products and setup actually being proposed. If an answer depends on a third party, mark it for confirmation rather than treating an assumption as a capability.

Plan for an update that does not arrive

A connected workflow also needs a sensible exception process. Ask what staff see if the expected exchange of information is temporarily unavailable or unsuccessful.

Will there be an obvious warning? Does something remain pending? Could the receptionist simply see that expected information is missing? The answer will depend on the particular systems, so ask for the real behaviour to be demonstrated or documented.

Do not create duplicates just because something is missing

Hypothetical example: a parent gives reception a valid booking reference, but the expected information is not visible through the normal connected workflow.

The safest operational response is not automatically to create another reservation. Give staff an agreed way to investigate the original reference, check the appropriate source and escalate the issue.

Decide who owns unresolved updates. If everybody assumes “IT will see it”, a missing change can remain unnoticed until the customer returns.

Know who supports which part

Where two suppliers or a third-party service are involved, ask who your team contacts first when information stops moving as expected. Keep those responsibilities with your implementation notes so staff are not trying to work them out during service.

Decide whether connecting the systems is worthwhile

Once you understand the proposed workflow, return to the repeated work you identified at the beginning.

Which entries disappear? Which checks become easier? Which records are less likely to drift apart? Which manual actions remain?

Compare a normal week, not an ideal transaction

If reception currently copies information between systems dozens of times as part of normal operations, removing that particular handover may be valuable. If staff rarely need the information being shared, the benefit may be smaller.

Also consider the additional setup, supplier relationships, ongoing charges and staff procedures that apply to the connection you are evaluating. Ask suppliers for those details rather than assuming them.

A connection can be useful without doing everything

The aim does not have to be total automation. A workflow in which the booking appears where reception needs it but certain amendments remain deliberate staff actions may suit a venue perfectly well, provided everybody understands the boundary.

The warning sign is not a manual step. It is a manual step nobody knew existed.