Built-in AI, a separate tool or your own assistant: how a hotel should decide

Build vs buy AI, in a hotel, means choosing between three doors: AI built into the property management system you already run, a separate tool connected to it, or an assistant built for you. Access to live data, a named person who keeps it working, and who owns the instructions decide more cases than the feature list.

A general manager watches a demo of an assistant answering guest questions in three languages and asks the obvious question: why not just build one? The answer depends less on the demo than on where the room list actually lives. After reading this you will be able to sort any AI offer into one of three doors, test whether it can act or only talk, and put the same five questions to every supplier before signing.

What are the three ways to put AI to work in a hotel?#

There are three doors: AI built into the hotel management system you already run, a separate AI tool connected to that system, and an assistant built for you by an agency, a freelancer or a member of staff.

Door one, built-in: the assistant sits inside the system that already holds reservations, rates and guest bills. A manager asks how many rooms are free on Friday and what the rate is, and the answer comes from the same record the front desk uses. Door two, a separate tool: a general assistant or a hotel-specific product that reaches your system through an interface, meaning a documented way for two programs to exchange data. A typical task is drafting replies to guest emails from a copy of the rate sheet. Door three, built for you: someone builds an assistant on top of a general model, for example a chat window on the website that answers questions about the spa and the parking.

The distinction that decides outcomes is not who wrote the code. It is where the data sits, who is accountable when an answer is wrong, and who is still there in month eighteen.

Every demo shows the happy path. Ask what the assistant refuses to do, what it does when it is unsure, and who hands over to a person. Ask for the mechanism, not the word; we cover how to tell a real feature from a new label in a hotel software demo separately.

Why does access to live data decide most cases?#

Because an assistant that cannot see the hotel's current rooms, rates and bills can only talk, while one that can read and act needs every action defined once, with permissions attached.

Talking is cheap, acting is not. Reading a rate sheet is a text problem. Holding a room is a write to the inventory, and it has to know what a hold is, who set it and when it expires.

A separate tool usually works from a copy. Copies drift: every rate change, seasonal closure, new room type and new outlet has to be pushed across, and nothing in the tool tells you when the push failed. The clean way to give any door real access is an action layer: each operation, such as find availability, hold, confirm or post a charge, is defined once and served to every door. Otherwise each door reimplements the same action and they disagree. This is the same idea behind defining each hotel action once so people, partners and assistants share it.

Permissions belong with the action, not with the screen. Decide which actions may run directly, which need one person's confirmation, and which need two. Guest records carry legal duties in Türkiye, including the guest identity notification (KBS, the misafir kimlik bildirimi) and personal data rules under KVKK, the personal data protection law. An assistant that reads them inherits those duties, so ask where the data is processed and who inside the hotel can see it.

The test is simple and takes two minutes: change a rate, wait, then ask the assistant for that rate. If it cannot see a change you made five minutes ago, it is talking, not acting.

Who keeps it working after launch, and who answers when it breaks?#

Someone inside the hotel must own the assistant: read its output, re-run a fixed set of test questions after every change, and be the person the front desk calls first.

The model underneath can be updated or withdrawn by its provider, and behaviour shifts without a line of your code changing. Ask how the supplier notices that and what they do about it. Your own data changes constantly too: a new room type, a new rate plan, a restaurant, a seasonal closure. Each one has to reach the assistant, and each one is a chance for a stale answer.

Build a small regression set: ten to twenty questions with known correct answers, written down, re-run after every change. It is not a benchmark and does not need to be one. Name one owner and one deputy. The owner does not have to be technical; they have to be the person who reads the output and escalates.

Write the handover rule: what the assistant does when it cannot answer, and how quickly a person picks up. Keep the record. If a wrong answer reaches a guest, you need to see what the assistant was told and what it did.

What does it cost over three years that the invoice does not show?#

Three lines: setup, usage, and the staff time spent checking what the assistant produced. The third is the one almost nobody puts in the budget.

Setup covers integration work, cleaning up the data the assistant will read, and writing the instructions that describe how your hotel works. Usage is charged in different ways: per seat, per message, or per unit of text the model processes. Two quotes that look similar can diverge sharply once volume grows; we break down how AI tools are priced by seats and usage in a separate article.

Checking time is real money. Multiply the minutes a person spends reading output each day by the wage and by three years, then ask whether the assistant removes more minutes than it adds. Change cost is the quiet one. Every change to your own systems has to be reflected in the assistant, and the contract should say who pays for that work and for re-testing.

Exit cost belongs in the same sheet: how long it takes to move the instructions and the logs somewhere else, and whether anyone will help you do it. Ask for a three-year total in writing, with the checking time and the change work as separate lines, not as a single monthly figure.

Who owns the instructions, the logs and the data if you leave?#

You should own the written instructions that describe your hotel, the record of what the assistant did, and your own data. If you do not, leaving means starting again from nothing.

The instructions are the asset that takes longest to build: the wording, the rules, the exceptions, the tone. They are also the part most easily locked inside someone else's account. Logs answer the question every owner eventually asks: what exactly did it say, to whom, and when. Check that you can export them, in a readable format, for a stated period.

Data questions are concrete: where is guest data processed, who can see it, how long is it kept, and what happens to it on the day the contract ends. Contract points worth insisting on: export on demand, deletion after an agreed period, and no reuse of your instructions to serve another hotel.

Run the exit test during the trial, before you sign. Ask for an export of the instructions and the last month of logs and see whether it arrives without an argument. A supplier who cannot answer these questions today will not answer them in year two. For a fuller set, see questions to ask an AI vendor before buying for your hotel.

Which door fits your hotel, by size and by task?#

Choose by task first, then by size: the smaller the hotel, the more the answer leans toward the door that already holds the data.

The task test comes first. Does the task need to read or write the hotel's live record? If yes, the assistant needs a real connection to that record. If it only needs fixed text, such as website questions or drafting, any door can work. Size decides maintenance, not ambition. A single hotel with no IT staff cannot keep a custom build alive through model changes and data changes, however good the first version is.

A group with an IT team can build, but only for tasks that repeat across its hotels. A build used by one property carries the same maintenance cost as one used by ten. The relative who builds a working demo is not the problem. The problem is month eighteen, when the model has changed twice and nobody is on call.

For groups, keep one approved list of tools and tasks, one owner and one review date. Individual hotels should not buy their own assistants, because the group then cannot say what guest data left the building. Start with one task that has a clear correct answer and a person who approves the outcome, then widen only after it holds.

For one honest data point from our own side: AI Otel's PMS assistant is built to answer questions about a hotel's own property in plain language, carry out routine actions, and wait for a person to confirm anything sensitive. It is not a trained model, and we have no trained model yet; what exists is the architecture, the decision infrastructure a model would run inside, and a benchmark to choose the model.

What to do next#

Write down the three tasks you would hand over first, then put the same five questions to every door: can it see a rate I changed five minutes ago, who owns it in month eighteen, what does the checking time cost over three years, can I export the instructions and the logs, and who is on call when it breaks. The three doors are not a ranking; they are a fit between a task, a data source and a person. Start with the single task where a wrong answer is cheap and a person approves the result. If you want to see how we handle the permissions and the record, request a briefing at https://ai-otel.com/contact.