Infor HMS: 9 Hotel PMS Checks from Reservation to Checkout

Infor HMS is a hotel property management system that supports reservation and property operations. Hotels assessing it need to look beyond the front-desk screen and follow the whole guest stay. This article explains nine checks for booking, room readiness, charges, interfaces, and the final financial record.

You will also find a demo plan, migration priorities, and questions for a current proposal. The focus is on whether Infor HMS software fits your hotel’s working process, rather than assuming that every hospitality function belongs in one package.

What does Infor HMS cover?

Infor’s hotel property management product page positions HMS as a platform for hotels, resorts, and casino resorts, with property operations and guest data at its core. Establish the precise scope for your property type and region before comparing features.

The HMS solution overview describes shared data for roles such as reservation agents, front-desk staff, managers, and finance users. It also discusses packages and interfaces. Use those documented features as a starting point, then test the setup you plan to buy.

A PMS is the operational record for the stay, but hotels also use distribution, revenue, point-of-sale, payment, and other systems. Some features may sit in connected products. Therefore, ask which functions are native, integrated, optional, or outside the planned scope.

This hotel management software checklist helps establish those boundaries before a demo. A clear system map prevents a promising feature in the wider vendor portfolio from becoming an assumed HMS inclusion.

1. Follow a reservation through a real change

Start with a booking that reflects your usual business. Include the room type, dates, guest details, rate, and payment conditions. Then ask the presenter to change the dates and inspect the resulting price and availability.

Next, modify the room type and add a second guest. These actions should leave a record staff can understand. Check which details carry forward and which need review when a booking changes.

Also test a cancellation and a reinstatement if your operation uses that process. Ask how the system handles the status, financial consequences, and room inventory. Your team should know which actions require authorization.

Finally, examine the source of the reservation. A direct booking, an agency booking, and a group booking may carry different terms. The PMS workflow should make those differences visible at the point where staff need them.

2. Check guest profiles without creating a duplicate record problem

A useful guest profile gives staff relevant context for service. However, repeated bookings can create several records for the same person. Test how staff search, identify a likely match, and handle a duplicate.

Use fictional profiles with similar names and different contact details. Then ask a reservation agent to choose the correct person. This reveals whether the search supports a safe decision under time pressure.

Also distinguish useful preferences from sensitive or unnecessary notes. A room preference may help service, while an unrestricted free-text field can collect data with little operational purpose. Agree on what staff should record and who may see it.

Next, test a guest who stays at more than one property if that matters to your business. Confirm the scope of shared data and any local access restrictions. A multi-property claim should translate into a clear working rule.

3. Make room readiness visible to the front desk

A vacant room is not necessarily ready for a guest. Housekeeping, maintenance, and the front desk need an agreed set of states and handoffs. First, map the path from departure to cleaned, inspected, and ready.

During the demo, check a guest out and follow the room through the housekeeping process. Next, report a maintenance issue that makes the room unavailable. Inspect what the front desk can see at each stage.

For example, a fictional hotel has a room that housekeeping has cleaned but a supervisor has not inspected. If staff treat that room as ready, the process may fail even when the software records both facts. Decide which state permits assignment and check-in.

Also test priority changes during a busy arrival period. Staff need a practical way to identify the next key room without relying on a parallel chat thread for every update. Record any required manual steps.

4. Test packages and charges with finance

A package may combine room revenue with meals, activities, or other items. The guest sees one offer, but the hotel may need separate operational and financial treatment. Include those details in the demo rather than testing only a simple room rate.

Use a package that your property actually sells. Ask how the setup applies included items, extra consumption, and changes to the stay. Then inspect the folio, which is the guest’s record of charges and payments.

Next, test a charge correction and a disputed item. The process should preserve a clear reason and the right authorization. A supervisor should understand the adjustment without relying on an undocumented conversation.

Also ask finance to review tax handling and revenue allocation under your local requirements. Product capability does not establish the correct setup for every jurisdiction. Test real bills with the people who approve the financial design.

5. Verify payments and settlement separately

A charge on a folio and money settled to a bank are different events. Hotels may also handle deposits, authorizations, refunds, and third-party payments. List the scenarios your property uses before assessing payment integration.

For a test stay, follow a deposit through to the final bill and settlement record. Next, process a partial refund in the approved test environment. Check how the PMS and payment system identify the same transaction.

Also test a payment response that arrives late or fails. Staff should know whether to retry, wait, or escalate. An unclear retry process can create duplicate collection or leave a payment unrecorded.

Finally, agree on daily reconciliation. Name the reports and outside statements finance will compare. A smooth checkout is valuable, but it should also leave a financial record the team can close with confidence.

6. Prove the interfaces around the stay

List every system that sends data to or receives data from the PMS. Include distribution, point-of-sale, locks, payments, accounting, and other tools relevant to the property. Then identify the owner and support contact for each connection.

Infor’s hospitality solutions overview presents PMS, revenue management, sales and catering, and other offerings as distinct solution areas. Use that distinction when checking the proposal. A broader portfolio page is not a complete list of functions in your HMS contract.

Ask for a successful transaction and a failed transaction on each key interface. For example, inspect a restaurant charge that reaches the correct room and a charge that cannot match a guest. You need a defined route for the unmatched item.

Also confirm what happens when a booking changes after another system has received it. Does the update flow through, require a manual action, or follow a different rule? Record the answer as part of the operating procedure.

If you need a separate guest relationship workflow, first check supported setup and connectors. Consider custom crm development only for a defined gap, with clear ownership of guest data and synchronization.

7. Review end-of-day and management reporting

The hotel’s end-of-day process links operational work to financial reporting. Ask the team to demonstrate the sequence, required checks, and handling of unresolved items. Include finance and night staff in this review.

Next, choose a few measures managers actually use, such as occupancy, room revenue, and outstanding balances. Agree on the definitions and reporting dates before comparing totals. Different filters can produce different valid answers to apparently similar questions.

For a fictional example, a hotel may have complimentary rooms and rooms unavailable for maintenance. Managers need to know how the chosen occupancy report treats each category. The number alone does not explain its meaning.

Also inspect corrections after the reporting period. Who can make them, how do they appear, and what should finance review? A clear adjustment trail helps prevent an old report from becoming impossible to reconcile.

8. Plan data migration around future stays

Future reservations deserve special attention because guests will depend on them immediately after launch. Check dates, room types, rates, packages, deposits, and special terms. A correct guest name is not enough to prove a booking migrated correctly.

Use a sample with a group reservation, a prepaid stay, a changed booking, and a returning guest. Then compare the migrated records with the originals. Include the teams who will act on the data at check-in and checkout.

The data migration framework helps structure mapping, trial imports, and reconciliation. For a hotel, add a clear plan for data changes between the rehearsal and the final cutover.

Also decide what history must remain searchable and what can stay in a readable archive. Moving every old field may add effort without improving service. However, keep the records your organization must retain and can justify using.

9. Price the rollout and train by role

Ask for a current quote that lists property scope, required modules, interfaces, rollout, migration, training, and support. Confirm the offered deployment and responsibilities. Do not use documentation about possible options as proof that every option remains available in your proposal.

Train staff around tasks they perform. A reservation agent needs booking changes, while a housekeeper needs room updates and a finance user needs reconciliation. Each role should also know when to stop and ask for help.

Rehearse a busy shift with a late arrival, a room problem, a disputed charge, and an interface failure. This test reveals coordination issues that separate feature demos may miss. Name a support lead for the first live shifts.

Finally, define success before launch. Use outcomes such as correct future bookings, explainable settlement, and clear room status. Avoid claiming that software alone will increase occupancy or guest loyalty without evidence from your own operation.

Use one complete guest stay as the acceptance test

Keep a short issue log during the test. Separate setup errors, missing training, and unavailable functions so each gets the right response. Then repeat only the affected scenario after a fix.

Check the support handoff before go-live

Give front-desk and night staff a short contact list for urgent problems. For each major issue, state who can decide the next step and which details support will need. Include a booking that cannot check in and a payment whose status is unclear.

Then rehearse one support call without using live guest data. Staff should be able to describe the issue, identify the affected record, and follow the approved temporary process. This exercise can reveal gaps that a normal product demo leaves hidden.

Choose around the full guest journey

A useful Infor HMS review connects reservations, room operations, charges, and financial close. Test that complete chain with your staff and your interface requirements. Choose the scope that the hotel can operate, reconcile, and support every day.