What you should never settle with a majority vote

A vote is a way to choose between acceptable options. It is not a mechanism for removing someone’s access requirements, spending boundary or consent. Establish the conditions every option must meet before asking which one people prefer.

In this guide: Treat accessibility, safety, dietary needs and personal spending limits as constraints.

1. Write down the constraints

Ask for practical needs: step-free access, a workable food arrangement, a maximum personal contribution or a safe transport plan. People do not have to publish private reasons to have a requirement respected.

2. Filter unsuitable options out

An option that fails a required condition should not remain on the shortlist because it is popular. If no option fits, change the scope, date or subgroup rather than treating the constraint as a veto to overcome.

3. Vote on real trade-offs

Once options are viable, the crew can choose between atmosphere, location, optional upgrades or pace. Keep consent to participate and consent to pay explicit even when the group has selected its favourite.

Worked example: what this looks like

Fictional scenario—not a real customer story or executed AI result.

A fictional cabin wins most preferences but has no confirmed accessible entrance for a traveller who requires one. The organiser does not ask that person to ‘go with the vote’. The cabin is paused while access is verified; if unsuitable, the shortlist changes. Preference scores cannot turn an inaccessible booking into a usable one.

Make the decision bookable, not merely popular

A proposal needs a stable meaning from the moment people read it to the moment someone acts on it. Keep the dates, people, total-cost basis and important conditions together. If those facts change, explain the new version instead of silently editing the commitment beneath an earlier response.

Do not confuse three separate stages: an idea is worth considering, the group supports a specific proposal, and the affected people have authorised the booking and their contribution. A ballot helps with the middle stage. It does not verify supplier availability or move money.

Before closing the discussion, write the next action as a sentence with an owner: “Jordan will confirm the exact room arrangement by Thursday, then ask the crew to approve the current booking total.” That is more useful than “sorted”.

A message or brief you can copy

Replace the bracketed fields with your own details. Read the complete text before sending it; copying it here does not send a message or perform an action.

Every option must meet [requirements]. These are not up for majority approval. We’ll vote between the options that pass those checks. If none do, we’ll change [scope / destination / dates] before asking anyone to commit.

Before you call it settled

• The proposal means the same thing to everyone reading it.
• Hard constraints are handled before preferences are compared.
• Each person chooses their own response; silence is not a payment instruction.
• The actual ballot result and settings are understood.
• A named person owns the next supplier or booking check.

The strongest group decisions leave room for individual boundaries. Shared enthusiasm is worth much more when nobody has been pressured into it.

Put the decision somewhere useful

Keep the proposal, current terms and next action with the trip in Limbo. Use the relevant help guide below for the actual workflow; the examples above do not create a booking or determine your configured ballot outcome.

Sources and further reading

• Limbo: current voting guidance

Product guidance was reviewed against the local Limbo help content and voting implementation on 19 September 2026. The suggested group process is separate from the actual configured ballot rules.

Keep planning

• Build an AI trip plan you can actually use
• Group-trip planning guide