Rate Plan Edits in Trip.com eBooking: A Field-by-Field Order

Editing a rate plan is not one change. It is a short sequence, and doing the steps out of order is how a rate ends up correct in one field and stale in the next.

Last updated: October 2, 2026

A rate plan looks like a single setting. It isn't. It's a small bundle of fields that have to agree with each other, and editing it is a short sequence. Change those fields out of order and you get the classic result: the number you meant to change is right, and the field beside it still carries last week's value. This is a field-by-field order for editing a rate plan on Trip.com, and the reasoning behind each step.

Key Takeaways

• A rate plan is a bundle, not a number. It carries a scope, a value and a set of conditions, and they have to agree.
• Set the scope first. Know which nights and rooms the change touches before you touch the price.
• Then the value, then the conditions. Change the rate and its rules in that order so the plan stays internally consistent.
• Check each field on its own. A plan isn't verified until every field you meant to move has actually moved.
• Leave it alone once it's set. A second edit on top of an unsettled change is how you lose track of what's live.

What a rate plan is actually made of

It helps to see a rate plan as three layers stacked on top of each other. The first layer is scope: which nights the plan covers, which room type it sells, and whether it's the default or a special one. The second layer is the value itself: the nightly figure a guest sees for those nights. The third layer is the conditions attached to that value, such as how long a guest has to stay or what the rate includes.

None of those layers works alone. A value with no scope applies to nothing. A scope with a stale value sells the wrong price. Conditions that don't match the value create a plan that reads as an obvious mistake to a guest. When a host says "I changed the rate and it didn't work," the field that didn't work is usually one of the other two layers, still holding the old state.

The layers are easy to see once you name them, and that naming is most of the work. A host who thinks in fields doesn't forget one, because the list is right there. A host who thinks in a single number tends to fix that number and leave the rest untouched, then wonder why the plan still reads wrong.

That's why a rate plan edit is best treated as a sequence rather than a single action. Each layer depends on the one before it, and the order in which you touch them decides whether the plan ends up consistent or half-updated. The numbers matter. The order matters just as much, and it's the part that's easy to skip.

The fields to change first, and why order matters

Start with scope. Before you change any price, confirm which nights the plan covers and which room it sells. If the scope is wrong, everything you do afterward applies to the wrong window, and the plan will look correct while selling the wrong nights. Scope first is the rule that stops the rest of the edit from being wasted.

Then set the value. With the scope settled, the nightly figure has a defined place to land. Change it once, plainly, and don't stack a second value change on the same pass. If you find yourself adjusting the number twice while the scope is still open, stop and close the scope first.

Then adjust the conditions. Minimum stay, the nights the plan applies to, and what the rate includes come after the value, because they describe how that value behaves. Set them against the value you've just entered, not against the one you replaced. Doing conditions first sounds harmless, but it means you're writing rules for a price you haven't committed to yet.

Finish the pass in that order — scope, value, conditions — and the plan has a chance to be internally consistent when you leave it. Do it in any other order and you'll spend the same time repairing a plan you built backwards.

Checking the change landed where you think it did

A rate plan isn't verified by the fact that you edited it. It's verified field by field, after the fact.

Read each field back against what you intended. Does the scope cover the nights you meant? Is the value the figure you entered, with no leftover from the previous one? Do the conditions describe the rate you just set? A plan can pass one check and fail the next, and the failure won't announce itself. It just sits there, wrong, until a guest sees it.

Cross-checking against a second view is the habit that catches the rest. On LOCALSBNB, the calendar shows the source rate and source status that came from each connected channel, so you can compare what the calendar reports for Trip.com against what you just set. If the two disagree, you know which value to trust and which to fix. The whole point of the check is to find the stale field before a guest does, and a side-by-side view is the quickest way to spot it.

Keep the check narrow. You're confirming the fields you touched, not re-auditing the whole plan. A five-field read-back is quick. If the two views agree, you're done, and you can stop looking. If they don't, fix the one that's wrong before you do anything else. A mismatched field left in place is a booking waiting to happen at a rate you didn't choose. Skipping the check can cost you a booking at a rate you didn't mean to publish.

What to leave alone until the new rate has settled

Once the plan is set and checked, the useful move is to stop. A new rate needs a settled period before the next change, or you lose track of which version is live.

Don't stack a second edit on top of the first. If you change the value, then change the conditions minutes later, and then change the value again, you end up with a plan nobody can reconstruct. If something still looks wrong, undo the last change rather than layering another one on top of it.

Don't rework two plans at once. Editing one plan is a short sequence. Editing two in the same pass makes it hard to say which edit caused a later problem, and it doubles the chance of leaving one half-finished. Finish one, check it, then start the next.

And leave the value alone while the earlier layers settle. If you've just changed the scope, give the plan a beat before you touch the price again, so you're reading a stable plan rather than one still in motion. You can see the calendar and the per-channel source rates side by side at localsbnb.com, which is where this check is easiest to run.

There's a reason the settle period feels unnatural. Editing is a form of control, and stopping feels like the opposite. But a plan you keep touching isn't more accurate, it's just harder to read. The calm version is the one that works.

A settled rate plan is a boring one. That's the goal. You want a plan you set once, confirmed once, and don't have to think about until the next real change. The order is what makes boring possible.

FAQ

Why does the field order matter if I'm changing one rate?

Because a rate plan is several fields that depend on each other. Set the scope before the value and you apply the price to the right nights. Do it the other way and a correct number can still land in the wrong window.

How do I know the change actually took?

Read each field back against what you intended, then cross-check it against a second view. On LOCALSBNB the calendar shows the source rate and source status from each connected channel, so a mismatch is visible rather than hidden.

Should I fix a second field in the same pass?

Usually no. Finish the fields you set out to change, then stop. Stacking a second edit on an unsettled plan is how you lose track of which version is actually live.

A rate plan rewards the host who edits it as a sequence and not as a single tap. Set the scope, then the value, then the conditions; check each field; and let the plan settle before you touch it again. To compare what you set against what the calendar reports for each connected channel, start at localsbnb.com.

---

This article is general guidance for hosts and isn't legal or tax advice. Channel terms, market conditions and local rules differ by place and change over time; check current product details and the terms that apply where your property sits.