PMS training for hotel staff: a plan by role before and after go-live

PMS training teaches each hotel role to finish its own daily tasks in the property management system. Plan it by role, train key users first, practice on the hotel's own test data, give each role a one-page sheet, staff a support rota for the first two weeks, and check each person before they work alone.

For example, a hotel goes live on a Tuesday. By Saturday the front desk has a paper list beside the screen, because the person on shift learned the software in a single demo and cannot remember how to move a restaurant charge onto a room bill. Nothing about the software has failed. The training has. This guide gives you a working plan for PMS training by role: what to practice before go-live, who owns what, and how to check that each person can actually work alone.

Why is a demo not training?#

A demo shows what the software can do; training builds the ability to complete a specific task under pressure, on the hotel's own data, with nobody standing behind you. The difference matters because hotels can pay for the first and believe they bought the second.

A demo is a performance by the person who knows the system best. The learner watches, recognizes the screen, and forgets it by the next shift. Recognition is not recall: knowing that you have seen a screen before is not the same as finding it at two in the morning with a guest waiting.

Demos also show the happy path. Real shifts are made of exceptions: a prepaid booking that must not be charged twice, a guest who wants a minibar charge moved to the room, a no-show that has to be handled before the room is resold. None of these appear in a demo, and all of them appear in your first week.

Nothing is at stake in a demo, so the cost of a mistake is never felt. People remember that a financial record is corrected by voiding and reversing it, never by deleting it, after they have done it once on test data. Reading it does not produce the same memory.

Finally, a demo has no owner and no end condition. Training has a named person in each department who is accountable for whether the team can work, and it ends with a check that the person can do the job alone. The practical test: ask the person to repeat the task the next morning, unassisted. If they cannot, they were shown, not trained.

Who should be the key user in each department?#

One named person per department, chosen for patience and standing among colleagues, trained deeper and earlier than everyone else, and given the authority to stop a process that is wrong. The key user is the structure that turns a training event into ongoing support.

Choose for temperament and credibility, not seniority alone. The key user is usually the person colleagues already ask when a printer jams or a booking looks strange. That person exists in every department, and everyone already knows who it is.

Name a back-up from the start. Key users take days off, and the first week after go-live is exactly when they will. A key user structure with no back-up collapses on its first holiday.

Train key users first, on the same test data everyone else will use, and let them write the one-page sheet for their own department. People defend a sheet they wrote; they tolerate a sheet handed to them. Give them three jobs: first call for questions, owner of the question log, and the person who signs the skills check for their team.

Give them a separate route to the project lead for anything that is a software defect rather than a question. Mixing the two buries the defects under the questions, and defects need fixing while questions need answering. Protect their normal workload during the first two weeks: a key user who is also covering a full shift cannot answer anything.

What should each role practice before go-live?#

Each role should practice the tasks it performs daily, end to end, on the hotel's own test data, until the sequence is boring. Boredom is the goal: it means the hands know the path and the mind is free for the guest.

Build the practice list from the job, not from the software menu. Ask each department to write down what it does in a normal day, then map each item to a screen. Anything that maps to nothing is either a gap to resolve before go-live or a task that stops on the night you switch systems.

Front desk staff practice check-in with and without a reservation, a room move, posting a charge, splitting a bill, check-out, and a key card that fails while the guest is standing there. Reservations staff practice a new booking, a group block and the rooms picked up from it, an amendment, a cancellation, and the visible difference between a booking that arrived from an agency and one taken by phone.

Housekeeping practices room status changes, maintenance reports, and what to do when a room is marked clean but the guest has not checked out. Night audit walks the order of the close, what blocks it, and who to call at that hour; walk it once with the person who will actually run it, using the same sequence as our night audit checklist for closing the business day in order. Accounting practices the day's takings, corrections by void and reversal, and the review step an e-invoice passes through before it is sent. Managers practice the two or three reports they actually read each morning, not the full report list.

Practice the mistakes deliberately, on test data, because the mistakes are the part of the job the demo never showed. If you are still setting up room types, rate codes and users, our guide to setting up a new PMS in the right order covers the configuration this practice depends on.

What goes on a one-page sheet per role?#

The handful of tasks the person does every day, in the order they do them, in the hotel's own words, with the name of who to call when it goes wrong. That is the whole content of the sheet, and it fits on one page if you let it.

One page, one role. If it needs two pages it is a manual, and nobody reads a manual at the desk with a guest waiting. Use the hotel's own vocabulary: its room type names, its rate codes, its outlets. A generic sheet trains people in someone else's hotel.

Write the exception next to the task, not in a separate section. If the guest has already paid, do this. If the agency booking has no rate attached, call this person. Exceptions live beside the tasks they belong to, or they are never found.

Add a short never-do list: never delete a financial record, because corrections are voided and reversed; never send an e-invoice without the review step. Print the sheet and keep it at the workstation, because a file in a shared folder is not available at two in the morning. The key user drafts it, the department manager signs it, and it is revised in the first month whenever reality disagrees with it.

What should the first two weeks after go-live look like?#

Cover the shifts where mistakes cost most, keep one question log, and change nothing that is not blocking a guest. The first two weeks are a support operation, not a training course that ended.

Publish a support rota that covers the early check-out rush, the evening check-in peak and the night audit, not just office hours. The person on the rota is reachable and named on the sheet. Mistakes cluster where the pressure is, and the pressure is not between ten and four.

Keep one question log with one owner and a date on every entry. The rule that makes a log useful: an entry closes only when the answer is written where the next person will look for it. Hold a short daily stand-up with the key users: what broke, what was asked twice, what the sheet got wrong.

Triage everything into three buckets, agreed in advance. Fix today what blocks a guest or a legal step. Log what slows people down. Defer what is cosmetic until the second month. Freeze non-essential configuration changes for the first weeks, so people are learning one system rather than a moving one.

Watch for the silent workaround: a paper list beside the screen, a spreadsheet of bookings kept in parallel. That is a training gap, not a discipline problem. Find the task the workaround replaces, teach it, and the workaround disappears on its own. If you have not reached go-live yet, pair this with a PMS cutover checklist for the night you switch systems.

How do you check that someone can work alone?#

Watch them do their own daily tasks, end to end, without prompting, and record the result as can do alone, can do with the sheet, or needs help. The check is observed, not a quiz: a person can pass a quiz and still freeze when a guest is waiting.

Run it on test data or in a quiet hour, on the tasks from the role list, in the order they occur in a real day. Three outcomes, not a score. Can do with the sheet is an acceptable result for a task performed once a week; it is not acceptable for check-in.

The key user and the department manager both sign, which stops the check from becoming a formality. Recheck after a month, and again whenever the software changes a task that person performs.

Nobody works a solo shift on a task they have not been checked on. Cover it with a colleague, or with the sheet and a phone number, until the check is done.

How do you train seasonal staff who join later?#

Give them the sheet, a buddy for their first shifts, a short session on the few tasks their role needs, and the same check before they work alone. The second intake gets the same standard as the first, through a shorter path.

Keep the test data and the practice logins alive after go-live. The second wave needs the same practice ground as the first, and a test environment that was switched off after launch forces you to train on live guests. The short path: read the sheet, watch the buddy do it once, do it once with the buddy watching, then the check.

Cut the curriculum to the season's tasks. A seasonal front desk recruit may never touch a group block, and teaching it wastes the only hour you have. The buddy is a named person, not whoever happens to be on shift, and is not the key user, who is already carrying the questions.

Record what the seasonal joiners ask. The same three questions every season are a gap in the sheet, not in the people. Keep the role list current: a sheet untouched since the first season describes a system that no longer exists. For a fuller structure, see our seasonal staff onboarding checklist by department.

Where to start on Monday#

Start with the role list, not the calendar. Ask each department manager for the tasks their team performs in a normal day, and build the sessions, the one-page sheets and the skills checks from that list. The rest of the plan follows from it: the cutover night, the migration checks and the seasonal intake all fit around the same list, and every later question has a place to be answered.