Software implementation in a working venue

A factory can close for a week to install new machinery. A restaurant cannot. The new till, booking system or kitchen screen has to be set up, tested and learned while the venue keeps serving lunch and dinner every day, and the first night on the new system has to go as smoothly as the last night on the old one. Most venues dread it for exactly that reason.

The dread is usually worse than the reality, as long as the work is planned. A software implementation in a working venue succeeds when the setup happens in the background, the team practises before they use it for real, the switch happens on a quiet day and the old system is kept to hand until the new one has proved itself.

This guide covers a three week plan for bringing in a new system without interrupting a single service, the tasks that must be finished before go live and how to handle the first days on the new system. Every venue and figure in it is an example.

Implementations go wrong for predictable reasons. The setup is rushed, so the menu has mistakes and the floor plan does not match the room. The team is trained on the day, so the first service is also the first time they use it. The switch happens on a busy night. And the old system is switched off before anyone is sure the new one works.

Each of these can be avoided. None of them is about the software itself; they are about the plan around it.

A three week plan works for most single venues. Week one is setup: the menu, the floor plan, the team and the devices, done in the background while the venue trades. Week two is practice and testing: the team learns the new system and it is checked against real services. Week three is the switch, on a quiet day, followed by close support.

Larger venues or groups may need longer. But the order stays the same: set up, practise, switch, support.

Before starting, decide what moves to the new system and what stays behind. The menu, the floor plan, the team and future bookings must move. Guest lists usually move. Past sales history usually does not, and does not need to.

This is the data migration plan, and it is worth writing down. A list of what moves, how and who is responsible avoids the discovery, the night before the switch, that something important was forgotten.

The menu is the biggest setup task and the one most likely to contain mistakes. Every dish, its price, its category, its options, its allergens and dietary tags and the kitchen station it goes to must be entered and checked.

Have the chef check the menu in the new system, dish by dish, against the current menu. An allergen missing from a dish, or a dish sent to the wrong station, is far easier to fix in week one than on the first busy night.

Draw the floor plan in the new system to match the room: every table, with its number, its seats and its zone. Set the booking rules for each shift, and each table's rules if some tables are held for walk-ins or only offered at certain times.

Walk the room with the plan on a tablet, checking every table. A floor plan that does not match the room confuses hosts and servers from the first booking.

Set up the team: each person with their own login, the right role and access to the venues they work at. Decide the roles carefully, because they decide what each person can do on the till and in the reports.

Ask each person to set up their own PIN in week one, so the first time they sign in is not on the night of the switch.

Set up the devices: tills, host stands, kitchen screens and printers, each connected to the venue and tested. Check that each device works in its real place, on the venue's own network, at the busiest point of the room.

Test the network too. A till that works perfectly in the office and drops its connection at the far end of the terrace is a problem worth finding in week one.

Import the guest list, if it is moving, and check it: duplicates removed, names and contact details clean, and marketing consent handled properly, which often means asking guests again rather than assuming it carried over.

Future bookings need the most care. Enter them in the new system, check every one against the old diary and decide which system the hosts will use for each date during the changeover.

Data migration is where most implementation problems hide. The old system may export data in a format the new one does not read, may lose details along the way or may contain years of messy records that are best left behind.

Move only what is useful, check it after it moves and keep an archive of what stays behind. Our guide to owning your guest data when you switch systems covers the guest side in detail.

Week two is for training, in short sessions before services, on the real system with the real menu. Servers practise opening tables, adding dishes and allergies and sending orders; hosts practise taking bookings and seating guests; the kitchen practises reading and bumping tickets.

Short, practical sessions work far better than a long demonstration. Twenty minutes of practice on real tasks, repeated over several days, builds confidence that a two-hour session never does.

Train a few people first, the most confident and respected members of each team, so they can help everyone else. A champion in the kitchen, one on the floor and one at the host stand can answer questions during service that would otherwise all go to the manager.

Champions also help software adoption more than any instruction can. When the team sees a respected colleague using the new system easily, they are far more willing to try it themselves.

Test the new system with real services before the switch. Ring a few real orders through it alongside the old system, send them to the kitchen screen and check what arrives. Take a few test bookings and check the confirmations.

Running the two systems side by side for a few services, often called parallel running, shows whether the new system produces the right results before anyone depends on it.

Check the reports in week two. Does the new system's end-of-day total match the old system's for the same orders? Are the categories right? Do the tax figures match? Will the accountant receive what they need?

Agree with the accountant how figures will reach them from the new system before the switch, so the first month end is not also the first time anyone looks at the new reports.

Set up a practice table in the new system, a table number that does not exist in the room, so staff can open checks, add dishes, split bills and take test payments without touching real orders. Practice on the real screens, with the real menu, is worth far more than any demonstration.

Clear the practice table's orders at the end of each session, and remove it from the floor plan before the switch, so no real order is ever rung to it by mistake.

Before the switch, run through a go-live checklist. Menu checked by the chef. Floor plan checked in the room. Every member of staff can sign in. Every device works in its real place. Future bookings entered and checked. Guest list imported. Payment methods tested. Reports checked against the old system.

If any item is not ready, move the date. A switch delayed by a week is far less costly than a switch that goes wrong on a full night.

Printers and payment terminals cause a surprising share of first-night problems. Test every receipt printer and kitchen printer with real orders, and every card terminal with a real card payment and a refund, before the switch.

Check the paper rolls, the cables, the power points and the network connection for each one in its real place. A terminal that will not connect on the first busy night stops service far more effectively than any software problem.

Guests may notice the change before staff expect them to: a booking confirmation that looks different, a new booking page, a different receipt. Check every message guests will receive from the new system, and make sure the venue's name, address, times and policies are right.

If the booking page address changes, update it everywhere it appears: the website, social media profiles, listings and the email signature. A guest who clicks an old link and finds nothing may simply book elsewhere.

Decide in advance what would make you go back to the old system, and how. A problem that stops payments or orders reaching the kitchen during a service may justify switching back for that service; a slow screen or a menu mistake does not.

Write the rollback plan down: who decides, how the old system is switched back on and what happens to orders taken on the new one. Most venues never use it, but knowing it exists makes the first night calmer.

Choose a quiet day for the switch: a weekday lunch or an early-week evening, not a Friday or a festive weekend. Fewer covers mean fewer chances for problems and more time to fix them.

Tell the team the date well in advance, and make sure the people who know the new system best are on shift that day.

On the first service, have someone who knows the new system on the floor, not in the office, ready to help. Expect small problems: a dish set up wrongly, a printer that does not print, a server who forgets a step. Fix them quickly and note them.

Keep the old system available, but do not use it for the service unless something serious goes wrong. Switching back and forth during a service causes more confusion than any problem with the new system.

Keep the old system running, but unused, for a few weeks after the switch. It holds the past bookings, the past sales and the reports the accountant may need, and it is a fallback if something unexpected happens.

Switch it off only once the new system has run smoothly for several weeks, every past booking has been honoured and the reports needed from it have been exported.

The first week after the switch brings a stream of small questions and fixes. Keep a list, fix what you can each day and brief the team on each change at the pre-shift briefing.

Check the reports at the end of each day of the first week. A mistake in the menu setup or the tax settings shows up quickly in the figures, and fixing it in week one is far easier than in month three.

The new system succeeds only if the team uses it properly, and that takes longer than the switch itself. Some staff adapt in a day; others take weeks, and some find workarounds that undo the system's benefits.

Watch how it is being used, not just whether it is. Our guide to software adoption: the team has to use it covers the habits that make a new system stick.

The till is usually the most sensitive system to move, because every sale depends on it. A POS migration needs the most careful setup, the most practice and the quietest switch day.

Our guide to POS migration without losing a Saturday covers the till's move in detail, from the menu setup to the first busy weekend.

Moving the booking system needs particular care with guests, because they have booked through the old one and will receive confirmations and reminders from the new one. Decide when the booking page switches, and make sure no guest receives confusing messages from both.

Check that the booking page, the confirmations and the reminders all show the right details: the venue's name, address, times and any policies. Guests notice mistakes here before staff do.

A kitchen moving from printed tickets to screens, or from one screen system to another, needs practice before the switch. Cooks used to paper tickets read screens differently, and a busy service is not the time to learn.

Run a few services with both the printer and the screen, if possible, so the kitchen can compare and trust the screen before the printer goes.

In a group, rolling out a change across venues works best one venue at a time. Start with the venue whose current system causes the most trouble, learn from its switch and apply the lessons to the next.

A champion from the first venue can help train the second. Each switch should be smoother than the last, and by the third venue the plan is well tested.

Someone should lead the implementation: usually the general manager or the owner, with time set aside for it. They own the plan, the go-live checklist and the decision to switch or to wait.

An implementation without a clear lead drifts, with tasks half done and nobody sure whether the venue is ready. A named lead with a plan keeps it on track.

Use the help the new system's supplier offers: setup guidance, training material, support during the first services. Ask what support is available on the day of the switch and in the first weeks, and how to reach it during service.

Ask other venues that use the system too. Their experience of the switch, and the mistakes they made, is often more useful than any guide.

An invented bistro moves to a new till, booking system and kitchen screens. In week one, the chef checks every dish in the new menu, the manager draws the floor plan and walks the room with it, each member of staff sets up their PIN and the guest list is cleaned and imported. In week two, the team practises in twenty-minute sessions before service, two champions are trained first and three lunch services are run in parallel with the old till.

The switch happens on a Tuesday lunch, with the manager on the floor and the old system available but unused. A dish sent to the wrong station and a printer setting are fixed that afternoon. By the first Friday, the team is confident, and the old system is switched off a month later.

In servearound, the setup happens while you trade. Dishes, categories, prices, photographs, options, allergens, dietary tags and each dish's station are set up in the menu editor, and a menu built at one venue can be copied to others; the floor plan is drawn in the designer to match the room, with each shift's booking rules and each table's own rules. Team members are invited with their roles and sign in on shared screens with their own name and PIN, and tills, host stands and kitchen screens pair with the venue using the short code each one shows.

Guests can be brought across from an Excel or CSV file using servearound's template, and imported guests are not signed up to marketing emails. Past sales from the old system do not come across, so keep its reports. While a venue is being set up, the network dashboard's setup health shows what it still has to finish. To plan a switch, see pricing or get in touch.

About three weeks for a single venue: setup, practice and testing, then the switch.

Yes. The setup happens in the background, and the switch happens on a quiet day.

In week two, in short sessions on the real system, not on the day of the switch.

A quiet one, such as a weekday lunch.

Yes, running but unused, for a few weeks after the switch.

The menu, floor plan, team, future bookings and usually the guest list. Past sales usually stay behind.

Using both systems side by side for a few services to check the new one gives the right results.

Move the date. A short delay costs far less than a bad switch.

A software implementation in a working venue succeeds with a plan: set up the menu, floor plan, team and devices in the background in week one; train the team and test the system alongside real services in week two; switch on a quiet day in week three, with support on the floor and the old system kept to hand. A go-live checklist decides whether the venue is ready, and a delayed switch is always better than a bad one.

Plan the data migration, protect future bookings, check the reports before the first month end and watch software adoption in the weeks after. Treat a POS migration with the most care, and when rolling out a change across a group, move one venue at a time and let each switch teach the next.