Choosing an AI chat tool for hotel staff: a business account checklist

A business account is a company-managed subscription where the hotel, not the employee, holds the contract and can add or remove people. Before approving any AI chat tool, verify six things in the provider's own documents: account ownership, admin controls, retention and improvement settings, sharing, admin-readable logs, and written terms naming where data is processed.

A front desk supervisor pastes a guest complaint into a free chat account on her phone to draft a reply, and it works well. Nobody at the hotel knows it happened, nobody can delete it, and when she leaves, the conversation stays behind in an account the hotel never controlled. This article is the AI tool business account checklist for preventing that situation: what to verify in the provider's own documents, in what order, and what to write down before you say yes.

What changes when staff use a personal account instead of a business account?#

Almost everything that matters to the hotel changes, because the account belongs to the employee. The hotel has no administrative relationship with the provider, so it cannot add, remove, configure or inspect anything.

The contract is the employee's, so the hotel cannot close the account or move it when that person leaves. Offboarding means asking the employee to delete their own history, which you cannot verify. Retention, whether conversations are used to improve the service, and sharing are set by the individual, not by a policy you wrote. The employee accepts consumer terms on their own behalf; the hotel never sees or agrees to them. And because there is no admin console, there is no record of who used the tool, when, or with what content.

One more thing is worth saying plainly: if the only approved route is slow or unclear, staff will use personal accounts anyway. The fix is a workable approved route, not a stricter ban.

Which admin controls must exist before you approve a tool?#

Four controls are non-negotiable: a company-managed account list, roles that separate ordinary users from admins, a shared workspace the hotel owns, and a one-step removal for a leaver.

Single sign-on, in plain words: staff sign in with their work identity, so access ends when the work account ends, not when someone remembers to act. Domain claiming lets the hotel prove it owns its email domain, so accounts created with work addresses can be brought under the company account instead of living outside it. Roles should have at least two levels, so the person who can change retention settings is not the same person who uses the tool all day.

Prompts, templates and approved use cases belong in a shared workspace the hotel owns and can hand over, not in individual histories. Write down the exact steps to remove a leaver and time them; if the answer is more than a few minutes, the control is not real. Finally, one person, by role, is accountable for the account, the settings and the review date.

This checklist sits inside a broader staff policy; our article on what staff may share with AI chat tools covers the content side of that policy.

What do the data settings actually decide?#

They decide three separate things that are easy to confuse: how long a conversation is kept, whether it may be used to improve the service, and what deletion removes.

For retention, ask for the default period, whether the hotel can shorten it, and whether the setting applies to existing conversations or only to new ones. For improvement, ask plainly whether conversations can be reviewed or used to improve the product, whether that is on or off by default, and how the hotel turns it off. For deletion, ask whether deleting a conversation removes it from backups and logs too, and on what timeline; "removed from your view" is not the same as deleted.

Ask whether people at the provider can read a conversation, under what conditions, and whether that is logged. Ask whether the hotel can export its own workspace data, in what format, and whether that survives the end of the contract. Then write the answers down with the date and the document you read them in, because defaults change and your note is the only record of what you approved.

For the Turkish legal context around guest data, see our article on KVKK questions to put to your adviser about AI and guest data.

Where is the data processed, and what do the written terms say?#

The only acceptable source is the provider's own written terms and its list of subcontractors; anything else is a guess, and the transfer question belongs to your legal adviser.

Ask for the data processing agreement, the terms of service and the current list of subcontractors that handle data, and check the date on each document. Ask which countries the provider states it processes and stores data in, and whether the hotel can choose a region. Do not accept a sales page or a blog post as the answer; ask for the clause and read the clause.

Under KVKK (kişisel verilerin korunması kanunu, Türkiye's personal data protection law), the hotel is the data controller for guest and staff data; the tool is a processor acting on the hotel's instructions, and the written terms should say so. Transfer and notice questions, and what must appear in your privacy notice, go to your legal adviser with the documents in hand; this article does not decide them. Record the version of the terms you approved, so a later change can be spotted rather than assumed.

Our article on questions to ask an AI vendor before buying gives the wider vendor questionnaire this section belongs to.

What can an admin actually read in the logs?#

Usually less than managers expect: membership and settings changes are commonly visible, while the content of conversations often is not, and that difference should be a deliberate choice rather than a surprise.

Separate two kinds of log: account events, meaning who was added, removed, promoted, which settings changed and when; and content, meaning what was typed. Ask which of the two the tool records, how long each is kept, and whether an admin can search them. Decide your position before rollout: content visibility can be useful after an incident and corrosive as a default; say which you chose and why.

Check that the log can be exported, because an incident review usually happens away from the tool. Test the log once with a harmless change, so you know what a real entry looks like before you need it. Write the incident route now: who is told, who reads the log, who contacts the provider, and where the record is kept. For the fuller routine, see an incident routine for when the AI gets it wrong with a guest.

How do you roll it out without turning the policy into a poster?#

Roll it out as one package: the approved tool and account, the settings you verified, a one-page policy, a short training session and a review date with a named owner.

Publish an approved-tools list with the account type and the sign-in route, so the answer to "what may I use" is one line, not a conversation. Train on cases, not features: what may go into a prompt, what never does, and what to do when a guest's message contains more than it should. Give staff a fast route to ask before pasting something doubtful; a question channel prevents more incidents than a rule does.

Re-check the settings and the terms on the review date, and after any notice of a provider change, because defaults and clauses move. Keep the record: the checklist you completed, the documents you read, the date, and who signed off. Treat a near miss as information, not a disciplinary case, or staff will stop reporting them. One training case worth including is prompt injection, covered in when a message tries to give orders to your AI.

What to do next#

Take the checklist to the next tool you are asked to approve and answer every line from the provider's own documents, writing down the date and the clause. The pieces fit together in one order: account ownership makes the controls possible, the controls make the settings meaningful, the settings and the terms are what your adviser can actually review, and the logs and the review date keep all of it true a year later.