November 11, 2026

Planning a sales kickoff: the agenda, the travel, and the spreadsheet you can drop

A sales kickoff is the one company event where the agenda and the travel are the same problem. The agenda says the whole revenue org is in one room at nine on Tuesday. The travel decides whether they are. Most SKO plans treat these as two workstreams, hand the second one to a spreadsheet, and discover the gap on the first morning.

Start with the agenda, because it sets the travel window

Write the agenda before you book anything, and write it with hours. Not "Tuesday: strategy", but "Tuesday 09:00 — number, Tuesday 10:30 — segment plans". You need the hours for one reason: the first session everybody must attend is what fixes the arrival deadline, and the last session that matters is what fixes the departure one.

A workable shape, three days:

  • Day one, afternoon and evening. Arrivals, then the number and the strategy — the part that justifies the flights. Put nothing load-bearing before mid-afternoon, because that is the earliest an honest arrival window delivers a full room.
  • Day two, full day. The working day: segment and territory plans, pricing and packaging changes, the competitive picture, enablement. This is where the content that needs everybody present belongs.
  • Day three, morning. Commitments and the first-quarter plan, finishing before the first departures. Then a leave-after time so the closing hour is not conducted to an emptying room.

Two things to resist. Do not schedule the most important session at nine on the first morning — it is the slot with the highest chance of a missing audience. And do not schedule a session that depends on one external speaker without knowing their travel: a guest's cancelled connection is the one risk you cannot absorb by reshuffling the room.

Then the travel window, in exact terms

From the agenda: the earliest and latest arrival date, the hour people must be there by, the earliest and latest departure date, and the hour they may leave after. Then one decision about bookings that fall outside it — flag them, require approval, or block them.

For an SKO specifically, approval is usually the right setting. A kickoff has a long tail of legitimate exceptions — the regional lead combining the trip with customer visits, the person flying in from a different continent who needs the extra night — and a hard block turns each of them into a conversation with you anyway, only later and with a change fee attached. Flagging alone, on a group of a hundred, means nobody reads the flags.

Set the cabin class cap in the same sitting, and name the arrival airports if the city has more than one. An unnamed second airport is how a quarter of the group lands ninety minutes from the hotel.

What the spreadsheet is actually doing, and what replaces it

The SKO spreadsheet usually holds five things. Worth naming them, because each one is replaceable by something that updates itself:

  1. Who is coming. Replaced by invitation status with dates: invited, accepted, declined. The difference matters — a spreadsheet records that you sent an invitation, not that anyone answered.
  2. Where they are coming from. Departure city per person, which explains why two people on the same trip cost different money and which flights can be grouped.
  3. What they booked. The event's own booking list: order number, traveller, services, dates, status, amount, and a filter for bookings outside the window. This is the column that is always stale in a sheet, because it is maintained by forwarded confirmation emails.
  4. What it costs. Four numbers that move on their own: budget, booked and spent, paid, remaining — plus the split by cost center and department, captured when the booking is made rather than reconstructed in January.
  5. Who is in which room. Room assignments against the block, which is only possible once "who is coming" is a fact rather than an estimate.

The spreadsheet is not the problem; the manual synchronisation is. Every one of those five columns is a copy of something that already exists in a booking system, an inbox or someone's head, and the copy is what goes wrong.

The room block, and the date that governs the schedule

For a kickoff the group is usually in one hotel, which means a room block: dates including the night before for the long-haul arrivals, rooms counted by type, a budget per night, and a date you need offers by. Compare offers on the total rather than the nightly rate, on the cancellation terms, on the release terms — how many rooms you can give back without a penalty — and on how long the offer stands.

Then the dependency that governs your whole timeline: the RSVP deadline has to fall before the block's release date. Get that order wrong and you are paying for rooms you could not fill because you had not yet asked people whether they were coming.

Guests, because a kickoff always has them

An SKO has outside people in it: a customer telling the story the field needs to hear, a partner, a facilitator, an analyst. They are not employees, so they are not in the travel tool, so somebody books them by hand and expenses it later — and their costs land outside the event budget they belong to.

Invite them to the event by email instead. They book inside the same rules, their spend lands in the same budget, and their access closes by itself when the event is over, which is the part that matters to whoever owns your access reviews.

Closing it out, in the week after

The kickoff ends and the reporting starts, and the questions are predictable enough to prepare for. Finance will ask what it cost by cost center and legal entity. The CRO will ask the cost per participant. Whoever owns access will ask whether the guests still have accounts. And you will want one number nobody asks for: how many bookings landed outside the window, because that is the measure of whether the window you set was realistic or merely strict.

Collect all four while the event is still open. A cost-center split is cheap to read from bookings and expensive to reconstruct from a total, and a guest account is easy to close on a schedule and easy to forget on a to-do list.

How this works in Travel Code

Create the event with the type "Sales kickoff", then name, dates, city, expected participants and the budget with its currency. It stays a draft until you invite people. Set the travel window — arrival and departure ranges, arrive-by and leave-after times, shown on a timeline against the event days — and choose what an out-of-window booking does: flag, approve or block. Approvals go to the event owner and to co-organizers who hold the approval right.

Add the revenue org from the company directory, invite the external speakers by email. Participants open the search from the event with the city and dates already filled in, under a banner that says the booking is for the event; one click switches to a normal search for anything personal attached to the trip. Every event booking appears in one list with the outside-window filter, the room block is requested and compared inside the event, and the budget shows booked, paid, spent and remaining with the splits finance will ask for.

The short version. Write the agenda with hours first; the first mandatory session is the arrival deadline. Require approval rather than blocking for a group this size. Put the RSVP deadline before the room block release date. Invite the guests properly instead of booking them by hand. And drop the spreadsheet column by column, starting with the one about who has actually accepted.

More on running company events

The product these articles describe is Company Events in Travel Code: one workspace for the people, the travel rules, the room blocks and the budget of a company trip.

Latest news

Your best journey starts right now!

Travel Code will process your personal data for setting up and managing your account, providing you with the requested travel management services, and as otherwise stated in our Standard Contractual Clauses for Controller/Processor. Travel Code may also process your data as a data controller in accordance with our Data Retention Policy and Cookie Policy.