Naming Rate Plans So the Folio Stays Readable for You and the Guest

A rate plan name is not decoration. It's what turns up on the confirmation, on the folio, and on the statement you reconcile three months later.

Last updated: September 26, 2026

A rate plan name is an operational label, not marketing copy. Type it badly and it resurfaces months later on a statement you can't reconcile, or on a confirmation a guest can't read. This article sets out where the name comes back to you, the habits that break a folio, a structure that holds across four channels and two languages, and how to rename a plan that's already selling.

Key Takeaways

• The folio is the judge. A plan name gets judged months later on a statement, not on the day you type it.
• Clever labels age badly. Nicknames and invented abbreviations make sense to the person who coined them and to nobody else.
• Name the basis, not the mood. Unit, occupancy basis and condition belong in the name; seasons and campaigns don't.
• One shape across channels. The same plan should read the same way wherever you sell it.
• Renaming is a migration. Changing a name that's in use is a data task with an order to it, not a text edit.

Where a rate plan name resurfaces long after you typed it

You type a plan name in a setup screen in five seconds, and then it travels. It goes out to the channels you distribute on, it prints on the guest's confirmation, it appears on the folio you hand over at checkout, and it comes back on the statement you reconcile at the end of the season. Four audiences, one string of text, no second chance.

The guest meets it first. "Weekend Special A" on a confirmation tells a guest nothing about what they bought. "Deluxe double, two guests, breakfast included" tells them everything. The plan name is the only part of the booking most guests read without being asked to.

Then you meet it, in a context you didn't plan for. Your calendar carries rate rows across Airbnb, Booking.com, Agoda and Trip.com, and each row brings the plan name from the channel side with it. When two plans are named almost the same way, the row you're looking at stops telling you which one it is, and you open the booking to find out what you sold.

Months later, it's the statement. A payout line reads "STD-RM-2" and you have to work out which room, which occupancy basis, which condition, and which season. If that takes more than a glance, the name has already failed.

The naming habits that make a folio impossible to reconcile

Most bad names come from five habits, and all five feel reasonable in the moment.

• Abbreviations you invented. "DLX2B" made sense for about a week, and only to you.
• Dates and seasons in the name. "Summer26" becomes a plan you duplicate every year, and a folio that mixes two summers.
• Campaign names. "Meta push 3" describes where the traffic came from, not what the guest bought.
• Numbers with no key. "Plan 4" only works while the key stays somewhere you can find it.
• Near-duplicates. "Standard" and "Standard 2" differ by one character, and that's the difference you'll be squinting at.

The cost isn't cosmetic. Reconciliation works by matching a line to a booking, and a line you can't place gets set aside. Set-aside lines accumulate. By the time you sit down with a statement, the work isn't checking the numbers, it's working out what the numbers are.

There's a second cost on the channel side. Where a plan maps to a channel's own rate, an ambiguous name makes that mapping harder to verify. Channel terms differ on how plans and rates are represented and on what a mapping has to carry, so check the platform's current terms rather than assuming a pattern carries over from one channel to the next.

The fix isn't a naming committee. It's a shape.

A naming structure that survives four channels and two languages

Build the name from three parts in a fixed order: what the unit is, what the rate assumes, and the condition attached. Everything else is noise.

The unit part identifies the room or property type at a level a guest would recognise. The basis part says what the price assumes — how many guests it covers, whether breakfast or a cleaning charge sits inside it, what the minimum stay is. The condition part carries the commercial qualifier: non-refundable, long-stay, member rate.

Two rules keep the shape honest across channels. Keep the separator and the order identical everywhere, so a name read on one channel gets recognised on another. And keep the string short enough that nothing truncates, because a name cut off mid-word reads as a different name entirely.

Two languages is the harder test. If you sell in more than one, decide once whether the plan name gets translated or kept as a stable internal string. Translating it means every channel needs the translation maintained. Keeping it stable means the guest-facing description has to carry the explanation instead. Either works. Switching between the two partway through a season doesn't.

Where a plan sits matters as much as what it's called. Airbnb, Booking.com, Agoda and Trip.com rows live on one calendar at localsbnb.com. Each row shows the source rate and source status it came from, so a plan name stays attached to the channel it belongs to. That's the difference between reading a name and guessing at one.

Renaming plans that are already in use, without orphaning bookings

Renaming a live plan isn't a text edit. Bookings already carry the old name, and if you overwrite it, the historical record loses its link to what was actually sold.

Work in an order. Start by listing every plan in use and marking the ones you're changing. Then settle the new names and check them against each other for collisions before anything moves. After that, walk the channel mapping for every affected plan, because a name change on your side and a mapping on the channel side have to end up pointing at the same rate. Only then rename.

Then leave history alone. Confirmed bookings keep the name they were made under, and new bookings pick up the new one. Check what your own system renders on a folio: if it shows the plan as it's named now rather than as it was named at booking, you've just rewritten your history, and last season's statement won't match it any more.

Retire rather than reuse. When a plan stops selling, keep it present but inactive if you need the history readable, and never recycle its name for a different plan. A reused name is worse than a bad one, because it's a bad name that also lies about the past.

FAQ

Should the plan name match whatever the channel calls it?

Not necessarily, but the two have to sit in a fixed relationship. The channel's own label is set by that platform, and how plans and rates are represented differs between them, so check the platform's current terms. What matters is that you can get from a line on a statement back to a plan you recognise without opening anything.

How short is too short?

If the name needs a key that lives in someone's head, it's too short. A useful test: hand the statement to someone who works with you and see whether they can tell what was sold. If they have to ask, a part is missing.

Can I just fix all the names at the end of the season?

You can, but you'll be reconciling the old ones until then. A batch cleanup also means renaming plans that are actively selling, which is the riskier version of the job. Do it between seasons if you can, and in the order above if you can't.

A rate plan name is small enough to feel like a formality and durable enough to follow you into next season's statements. Name the unit, the basis and the condition, keep the shape identical across every channel you sell on, and rename in an order rather than in a hurry. When your channel rows and their source rates sit on one calendar at localsbnb.com, the label you typed once is one you can still read a year later.

---

This article is general guidance for hosts and isn't platform policy advice; channel terms differ, and the current terms of each platform prevail.