HOW TO
·
MAY 2026
·
7 MIN READ
Is it safe to connect this to your PMS?
Read only first. Writes later. Never hand over a password. A checklist that applies to any vendor, including us.
Letting software write into your reservation system is a bigger decision than letting it read from one. A bad read shows a guest the wrong rate, which is embarrassing and fixable. A bad write creates a reservation that does not exist, double books a room, or overwrites a note somebody needed.
This is a checklist for doing it carefully. It is written to apply to any voice agent vendor, and you should hold us to every item on it.
One. Never give anyone your password
If a vendor asks for your login credentials so they can sign in as you, stop there. It means they are not integrating with your system, they are impersonating you inside it. That leaves no audit trail distinguishing their actions from yours, and you cannot revoke their access without changing your own password.
A proper integration asks you to authorise it from inside your own account. You stay signed in as you, the vendor gets its own identity, and every action it takes is attributable.
If you cannot revoke it without changing your own password, it is not an integration.
Two. Grant the narrowest permission that works
Most systems let you scope what an integration can touch. Take the time to actually read those scopes rather than accepting the default bundle. A voice agent answering booking calls needs availability, rates and reservations. It does not need your financial reports, your staff records, or your full guest history going back four years.
If the vendor cannot explain why they need a particular permission in one sentence, ask them to remove it and see whether anything breaks. Usually nothing does.
Three. Run read only for at least a week
This is the single most valuable step and the one most often skipped because everyone is impatient to go live. In read only mode the agent answers calls, quotes availability and rates, and does everything it would normally do, except it cannot create or modify a record. It tells the caller it will confirm shortly, and a human completes the booking.
You are not testing whether it can talk. You are testing whether the numbers it says out loud match the numbers in your system. Read the transcripts. Check three or four quotes a day against what your own screen shows for the same dates.
Four. Test the edges before you test the middle
A simple two night midweek booking will work on day one for any competent system. That tells you nothing. Deliberately throw the awkward cases at it while it is still in read only, and do it yourself by phone rather than waiting for a guest to find the problem.
Try a stay that crosses a rate change. Try dates where only one room type is left. Ask for a room that is genuinely sold out and see whether it invents availability. Ask about a deposit, a group of six, an early arrival, a cancellation, a guest who changes their mind halfway through. Interrupt it. Speak over it. Give a date in a strange format.
What you are looking for is not perfection. It is whether the system fails honestly. Saying it is not sure and offering a person is a good failure. Confidently quoting a rate that does not exist is a disqualifying one.
Five. Turn on writes narrowly, then widen
When you do enable writing, start with the simplest case only. New reservations for standard stays. Leave modifications, cancellations and group bookings on the human path for another fortnight. Each of those has more ways to go wrong and less obvious recovery.
Ask the vendor how a failed write is handled. If your system is unreachable mid call, does the booking vanish, or is it queued and retried with somebody notified. The answer to that question tells you a great deal about how seriously the product was built.
Six. Know where your kill switch is
Before you go live, find the exact place in your own system where you revoke the integration, and confirm that doing so stops it immediately rather than at the end of a billing cycle. Then tell your duty manager where it is. An emergency stop nobody can find is not an emergency stop.
Also agree what happens to your data if you leave. How long recordings and transcripts are kept, whether you can export them, and how deletion is confirmed. Ask before signing, not after.
The short version
Authorise from inside your own account. Grant the least access that works. Read only for a week and actually read the transcripts. Break it on purpose before a guest does. Enable writes for the simple case first. Know how to switch it off. None of this is specific to any one vendor, which is rather the point.
Permission models and revocation flows differ between systems. Check the documentation for the platform you run before assuming any of the above applies exactly.
Start in read only.
Free for 14 days. Writes stay off until you switch them on, and you can revoke access from your own system at any moment.
GET IN TOUCH →
The front desk that never misses a call. Answers, books, and syncs with your PMS, so independent hotels never miss a reservation.
CONTACT
info@afernai.com
© 2026 AFERN AI · ALL RIGHTS RESERVED
PRIVACY
TERMS
ALL SYSTEMS NORMAL