How AI tools are priced: seats, usage and what drives the bill

AI tools are priced in four units: seats (people with access), conversations or sessions, outcomes such as a resolved request, and tokens, the small pieces of text a model reads and writes. Most bills mix a fixed fee with a usage part, so the same work can cost very different amounts depending on setup.

Two vendors quote the same guest-messaging assistant. One charges per person with access, the other per conversation. In a quiet month the first looks cheaper, in a busy one the second does, and neither quote says which month you are buying. AI pricing models differ from the software subscriptions most hotel budgets are built on, because part of the bill can move with the work itself. After reading this, you will be able to name the unit behind any quote, translate it into your hotel's own work, and hold the bill steady.

What are the four ways AI tools are priced?#

Almost every AI quote reduces to one of four units: a seat, a conversation, an outcome or a token, and each one counts something different about the work.

A seat counts named people with access. It is flat, easy to budget and blind to use: a receptionist who asks the assistant fifty questions a day and a manager who logs in once a month cost the same.

A conversation or session counts an exchange, or a window of time in which exchanges happen. The definition matters more than the number. Does a follow-up question the next morning start a new conversation? Does a thread handed to a person still count?

An outcome, sometimes called a resolution, counts a request closed without a person finishing it. This unit moves risk to the vendor, so the contract has to say who decides that a request was resolved.

A token is a small piece of text, roughly a word fragment, that a model reads or writes. Input tokens are what the hotel sends, including any attached document. Output tokens are what the model writes. They are counted separately and usually priced differently.

Most real bills are hybrid: a platform fee, a volume included in it, and an overage rate above that volume. Read the quote to find all three parts, because the headline figure is rarely the whole bill. No unit is inherently fairer. Each one shifts risk to a different side, and the right choice depends on whether the hotel's work is steady or seasonal.

How do you translate a pricing unit into hotel work?#

You translate by counting one real month of hotel work in the vendor's unit, then checking which unit grows faster than the work itself.

Start with a guest conversation: one thread from the guest's first question to the last answer. A thread with six messages may count as one conversation or as six, depending on the definition, so write down which one you are counting.

A drafted reply is one output. If the assistant offers three alternative drafts and a person picks one, that is three outputs of work even though only one message is sent.

A morning report set is a scheduled job. It runs whether or not anyone reads it, which makes scheduled work the quietest line on a usage bill. A back-office request, such as a summary of night-audit exceptions or a translation of a rate sheet, is one instruction with a long input. Count it separately from guest messaging, because the two behave differently.

Count the same unit across three weeks: a normal week, a peak week and a closed or near-empty week. The unit that stays flat is a seat-style cost; the unit that swings with occupancy is a usage cost. Back-office work is usually the easier place to start counting, because the volume is set by the hotel's own calendar rather than by guests. If you have not chosen a first workflow yet, where to start with AI in a hotel argues for back office before guests.

What drives the usage part of the bill?#

Usage grows from what the hotel sends with each request, how often it retries, and how much it asks the model to write back.

Long attachments sent with every question are the first driver. If the tool resends a full rate sheet or a long contract with each question, the input volume multiplies. Fetching only the relevant paragraphs, a setup usually called retrieval, keeps the input small.

Carried conversation history is the second. Keeping the whole thread in context means every new question re-sends the earlier ones, so a long thread costs more per message than a short one. Retries and failures are the third: a request that fails and is sent again may be billed twice. Ask how failed requests are counted before you sign, not after the first bad month.

Bulk jobs are the ones that turn a normal month into an unusual one. Reprocessing last year's guest messages, translating an entire rate sheet or summarizing every review is one instruction with a large volume behind it. Output length matters too: asking for a short answer with a reason costs less than asking for a full report, and output is usually the more expensive side of the count, so the format of the request is a cost decision.

Model tier and scheduling complete the picture. Sending simple tasks to a smaller, cheaper model and hard ones to a larger one changes the bill without changing the workflow; this is a routing decision the hotel can ask for. Scheduled jobs that run on a timer rather than on demand, including jobs nobody reads, keep spending whether or not anyone is looking.

How do you keep the bill predictable?#

Put a cap on the account, an alert below the cap, and one named person who reads the usage line every month.

Decide between a hard cap and a soft cap per workflow. A hard cap stops work when it is reached, which may mean guest messages go unanswered. A soft cap only alerts. Guest-facing work usually needs the soft version with a person watching it.

Set the alert well below the cap, so there is time to act. An alert at the cap tells you after the work has already stopped or the overage has already started. Name an owner: the person who sees the monthly usage is usually the person who can change behavior, whether that is shortening attachments or moving a bulk job to a quiet week.

Separate allowances per workflow where the vendor allows it, so one bulk translation cannot consume the guest-messaging budget. Test the cap deliberately in a trial account: run a large job and watch what the account does. A cap that has never been tested is a hope, not a control. Record every cap change with the reason. A rising cap with no note is how a predictable bill becomes an unexplained one.

Once the tool is live, a routine helps: a weekly review checklist for a hotel AI assistant after go-live includes the usage line as one of its checks.

Which contract questions keep the bill predictable?#

Ask what the unit means, when the price can change, and what happens above the included volume, and get the answers in writing.

The definition of the unit comes first, with edge cases named: a follow-up the next day, a conversation handed over to a person, a request the guest abandons halfway. If the unit is a resolution, ask what counts as one, who decides it, and whether a reopened request is counted a second time.

Overage comes next: the rate above the included volume, and whether it is the same rate or a higher one. Some contracts price the first block of overage differently from the rest. Then price changes: the notice period, whether a change can apply mid-term, and whether the definition of the unit can change at the same time. A redefined unit can raise a bill without any price change at all.

Failed, duplicate and retried requests should be covered too: billed or not, and how the hotel can see them in the usage report. Data terms on exit matter for the long run: what happens to the hotel's text and transcripts, and in what format they can be exported. Pilot terms matter for the short run: what the pilot counts, what it does not, and what volume the price assumes once the pilot ends. For a fuller list, see questions to ask an AI vendor before buying for your hotel.

How do you compare two quotes on the same sample month?#

Take one real month of the hotel's work, count it in each vendor's unit, and compare the totals and the shape of the bill rather than the headline.

Freeze the month and the counts first: number of guest conversation threads, drafted replies, scheduled report runs and back-office requests. Use the hotel's own records, not the vendor's estimate. Convert the same month into each vendor's unit, and write down every judgement the definition forced. Those notes are where the two quotes usually diverge.

Run the comparison on three months: a normal one, a peak one and a closed one. A quote that looks similar in a normal month can separate sharply in a peak month. Compare the shape: how much of each quote is fixed and how much moves with volume. A bill that is mostly fixed is easier to budget and harder to shrink in a quiet month.

Ask both vendors to state the assumptions behind their figure in writing, then check whether those assumptions match the counts you froze. Never compare a per-seat quote with a per-token quote directly. Convert both to the same month before any number is discussed. The counts below are illustrative only.

If the comparison is part of a trial, running an AI pilot in a hotel covers scope, baseline and a clear stop rule.

What to do next#

Pick one workflow, count a real month of it in the vendor's unit, and take that count into the contract conversation. The four units, the usage drivers and the contract questions fit together as one habit: know what is being counted, know what moves the count, and know who is watching it. That habit is what turns an AI quote into a budget line you can defend to an owner or a finance committee.