Software adoption: the team has to use it

The new system went in smoothly. The menu was set up, the devices worked, the first service passed without a problem. Three months later, the manager looks at the reports and finds that half the allergies are written on paper rather than recorded on the order, comps are rung as voids because nobody learned the difference, and two servers still share one login because it is quicker. The system works; the team simply does not use it the way it was meant to be used.

This is how most new systems fail in restaurants: not on the day they go in, but slowly, on the floor, as the team finds its own ways around them. The office sees a successful implementation. The floor sees a system that gets in the way, and quietly works around it.

This guide covers why adoption fails, the four habits that make a new system stick and how to tell whether the team is really using it. Every venue and figure in it is an example.

Software adoption is the team actually using a system as intended, every day, so that its benefits arrive. A till that records every allergy, every comp with a reason and every sale under the right person's name has been adopted. A till that is used for payments while everything else happens on paper has only been installed.

Adoption is the difference between a system's promise and its results. The reports, the safety and the time saved all depend on it.

Adoption fails on the floor because that is where the system meets the pressure of service. A step that takes ten seconds in training takes too long when three tables are waiting. A screen that seemed clear in the office is confusing in a dim, busy room. A feature nobody explained is ignored.

Staff are not being difficult when they work around a system. They are protecting the service in the only way they know. The fix is to make the system the easiest way to do the job, not to tell them to try harder.

Research on how people take up new ideas, known as the diffusion of innovations, finds that a few people adopt early, most follow once they see it working for others, and a few resist until the end. Restaurant teams follow the same pattern.

Use it. Find the early adopters and let them show the rest. Make the system's benefits visible. And give the last few the time and help they need, rather than treating their caution as refusal.

The first habit is to start with what the new system fixes for the team, not for the owner. Servers care about fewer trips to the kitchen, fewer mistakes on bills and an easier end of night. The kitchen cares about clear tickets in the right order. Hosts care about a diary that is always up to date.

Explain the new system in those terms. A team that sees how it makes their own shift easier adopts it far faster than one told it will improve the reports.

The second habit is champions: a confident, respected person on each team who learns the system first and helps 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.

Choose champions for their standing with the team, not their job title. A respected senior server persuades colleagues far better than a manager does.

The third habit is practice on real tasks, in short sessions, before and after the switch. Opening a table, adding a dish with an allergy, splitting a bill, moving a party to another table: each practised a few times becomes automatic.

Long demonstrations do little. Twenty minutes of practice on the tasks people will actually do, repeated over several days, builds the confidence that makes the system the natural way to work.

The fourth habit is to retire the old way completely once the new one is ready. If paper tickets, the old diary or the old till are still available, people under pressure will use them, and the new system will never become the only way.

Remove the old tools on a set date, after the team has practised. Keep a fallback for genuine emergencies, kept by the manager, but make it clear that the new system is now how the venue works.

The till is the system most people use most, so POS training deserves the most care. Every member of the floor team should be able to sign in, open a table, add dishes with options and allergies, send to the kitchen, split and move bills, and take payment, without help.

Train in the order people need things: the basics first, the rarer tasks later. A server who can take an order confidently on their first night will learn splits and transfers easily in their second week.

Adoption is not finished when the switch is over. Every new starter has to adopt the system too, and they learn it from whoever trains them, including that person's shortcuts and bad habits.

Build the system into the staff training checklist for new starters, with each task shown, practised and signed off. Our guide to a training checklist for the first four weeks covers how.

Training on a new system has to fit around service, because the venue cannot close for it. Short sessions before service, quiet afternoons and practice on a test table all work.

Our guide to staff training that fits around service covers how to train without losing a service, whether for a new system or anything else.

Listen to what the team says about the new system, especially in the first weeks. Complaints often point to real problems: a menu set up in an awkward order, a step that could be removed, a device in the wrong place.

Fix what can be fixed, quickly, and tell the team what changed. A team that sees its complaints acted on believes the system is being made to work for them, and adopts it more readily.

Watch how the system is used, not just whether it is. Are allergies recorded on orders or written on paper? Are comps given reasons? Does everyone sign in as themselves? Are bookings entered as they come in, or later from memory?

The reports often show this. Comps with no reasons, sales under one person's name all night, bookings entered in bursts after service: each is a sign that a habit has not taken hold.

Workarounds are signals, not just bad habits. If servers share a login, signing in is probably too slow. If allergies go on paper, recording them on the order is probably too awkward. If the old diary is still in use, the new booking screen may be hard to read at the host stand.

Ask why each workaround exists before banning it. Often the answer points to a setup change that removes the reason for it.

The first week after the switch decides many habits. If staff find a workaround in the first week and nobody notices, it becomes the way things are done. If problems are fixed quickly and the right way is shown again at each briefing, good habits settle instead.

Be on the floor in the first week, watching how the system is used and helping with each problem as it arises. A manager who is visibly there to help builds far more confidence than one who reads the reports a month later.

Speed decides adoption more than any feature. If the new system is slower than the old way for a task staff do many times a night, they will find a way around it, however good its other features are.

Time the most common tasks on the new system: opening a table, adding a round of drinks, taking a payment. If any is slower than before, look for a setup change that speeds it up, such as a better menu layout or a shortcut for common items.

Shared logins are the most common adoption failure, and one of the most damaging. When several people use one login, every action is recorded against it, and the system's records of who did what mean nothing.

Make signing in quick, with short personal PINs and screens that lock when left. When signing in as yourself is easy, people do it. Our guide to staff logins: one till, eleven people covers how.

A small card by each till, listing the less common tasks, helps more than any manual. How to split a bill, how to move a table, how to record a comp with a reason, how to fix a mistake after sending: the things staff do rarely enough to forget.

Keep the card short, with the steps for each task in a few words. Update it when the setup changes, and remove it once the team no longer needs it.

Ask the team for feedback on the system each week for the first month: what slows them down, what confuses them, what they have found that works well. A short question at the briefing is enough.

Write down what they say and act on it. The team sees things in service that the manager setting up the system never sees, and their suggestions often make the biggest difference to adoption.

A new system asks a lot of the team: learning while working, putting up with small problems, changing habits that took years to form. Thank them for it, specifically and in public, once the system has settled.

A team that feels its effort was noticed approaches the next change more willingly. A team that felt the change was simply imposed on them remembers that too.

The deepest principle of adoption is to make the right way the easiest way. If recording an allergy on the order is quicker than writing it on paper, servers will do it. If the booking screen is faster than the old diary, hosts will use it.

Look at each step the team skips and ask how it could be made quicker. Often a small change in the setup, such as a common note saved as a quick option or a device moved closer to where it is used, solves what no amount of instruction could.

People take to new systems at different speeds, and the differences rarely follow age or job title. Some experienced staff adapt in a day; some younger ones struggle with a system that works differently from the apps they know.

Avoid assumptions. Offer extra practice to anyone who wants it, without making them feel singled out, and let the quickest learners help the others. A team that helps each other adopts a system far faster than one where people struggle alone.

Managers set the example. A manager who records every comp with a reason, signs in as themselves and uses the system for every booking shows the team that the system is how the venue works. A manager who takes shortcuts teaches everyone that shortcuts are fine.

Ask managers to use the system exactly as the team should, especially in the first months. Their habits become the venue's habits.

Adoption can be measured with a few simple figures. The share of comps and voids with a reason. Whether sales are spread across the people who worked, or recorded under one login. Whether allergies appear on orders. Whether bookings are entered as they come in.

Check these monthly for the first few months, and share the results with the team. A rising share of comps with reasons is a sign the system is being used properly, and worth thanking the team for.

Rolling out a change to a system already in use needs the same habits as introducing a new one. A new menu layout, a new step in the payment process or a new report all need explaining, practising and checking.

Announce each change at the briefing, show it on the real system and check a week later that it has taken hold. Changes that arrive unannounced, on a busy night, are the ones that create workarounds.

In a group, adoption varies between venues, often because of the manager. One venue uses the system fully; another uses half of it. The reports show the difference: one venue's figures are complete and trustworthy, another's full of gaps.

Share what works between venues. A champion from a venue that has adopted the system well can help another that has not, and the comparison often reveals simple setup differences that explain the gap.

Software implementation gets a system working; adoption gets it used. Both matter, and the second takes longer. A good implementation plan includes adoption from the start: champions chosen early, practice before the switch, the old way retired on a set date and usage watched in the months after.

Our guide to software implementation in a working venue covers the plan for getting a system in without interrupting service.

Adoption takes longer than most owners expect. The switch is done in a day; the habits take weeks or months to settle. Expect the first month to bring workarounds, the second to bring most of them back into line and the third to show the system's real benefits in the reports.

Keep watching beyond that. Habits drift, new starters arrive and features go unused. A short review of how the system is being used, every few months, keeps adoption from slipping.

An invented brasserie installs a new till and kitchen screens. Three months later, allergies are still written on paper tickets, servers share two logins and comps are rung as voids. The manager asks the team why. Signing in takes too long, the allergy note is buried in a menu and nobody was shown the difference between a void and a comp.

The manager sets short personal PINs, saves common allergies as quick options, shows the team the comp button at a briefing and asks two senior servers to act as champions. The paper tickets are removed from the pass. Within a month, every allergy is recorded on the order, everyone signs in as themselves and the comp report shows real reasons for the first time.

In servearound, the same screens are used in training and in service, so practice is on the real thing, and each person signs in with their own name and PIN, set themselves under Account, then Security. A screen locks when its user locks it, when the next person signs in, or after two minutes untouched on a till or ten on a host stand, so signing in as yourself stays quick, and each role shows only the parts of the app that person's job needs.

The everyday steps are short to learn: open a table on the floor plan, add dishes and their options, add an allergy so it appears at the head of the kitchen ticket and send. Comps and voids each carry an optional reason, and payment analytics show them by member of staff, so the reports show how the till is really being used. See point of sale and kitchen.

The team using a system as intended, every day, so its benefits arrive.

Because the team works around them under the pressure of service.

Start with what it fixes for the team, use champions, practise on real tasks and retire the old way.

A respected, confident member of each team, chosen for their standing rather than their title.

Only for genuine emergencies, kept by the manager, not as an everyday option.

Usually that a step is too slow or awkward. Ask why before banning them.

Usually two to three months for habits to settle.

Watch the reports: comps with reasons, sales under each person's name, allergies on orders.

Software adoption decides whether a new system delivers anything, and it fails on the floor rather than in the office, as the team works around steps that slow them down. Four habits make a system stick: start with what it fixes for the team, put champions on every team, practise on real tasks in short sessions and retire the old way once the new one is ready.

Treat POS training and staff training for new starters as part of adoption, listen to complaints, read workarounds as signals and make the right way the easiest way. Use the same care when rolling out a change to a system already in use, follow a proper software implementation plan, and review how the system is used every few months so the habits do not drift.