What a meeting programme actually is
A conference meeting programme is not a list of appointments. It is a small, temporary operation with its own supply and demand.
The supply is finite and known in advance: a set of experts who are on site for specific hours, a set of rooms with capacities, and a fixed number of days. The demand is uncertain and arrives late: meeting requests from attendees, targets from sales, executive asks that appear the week before.
Almost every difficulty in running these programmes comes from that mismatch. Supply is fixed early; demand shows up late and changes constantly.
Treating it as an operations problem — with capacity, rules, and a booking process — rather than as an admin task is the single biggest determinant of how the week goes.
Eight weeks out: the decisions
The decisions made here determine how much firefighting happens later. None of them require the schedule to exist yet.
Who is going, and for what. Not just names — the capability each person brings. A solutions architect, a security specialist, and two product managers is a very different programme from four account executives. Record what each person can speak to.
What meeting types you will offer. Most programmes need three or four, no more. A common set is: a 30-minute introduction, a 45-minute technical deep dive, a 60-minute executive briefing, and a short booth demo. Each type gets its own duration, room requirement, and approval rule.
What space you have. Room count, capacity, location, and equipment. If you are renting a suite, this is the moment to decide how many meeting rooms it will be divided into — that number caps your entire throughput.
Your capacity ceiling. Multiply available expert hours by realistic utilisation (about 70%, not 100%), divide by average meeting length. That number is how many meetings the programme can actually hold. Knowing it early prevents the awkward conversation where sales has promised more meetings than the week can contain.
What requires approval. Executive time almost always should. Decide who approves, and how fast they will commit to responding — an approval step with no response-time commitment is a bottleneck with extra steps.
Four weeks out: opening requests
Now you open the programme to demand, from two directions at once.
Inbound is attendees asking for time with you. Give them a booking page that collects the substance of the request — the topic, what they are evaluating, who is coming — not just a name and an email. Publish it wherever attendees will encounter it: the event's own platform, your campaign emails, your booth materials.
Outbound is your team asking for time with specific accounts. Sales and customer success should be able to submit target accounts through the same queue, so both types of demand land in one place and compete for the same capacity fairly.
Two rules make this phase work:
- One queue. The moment inbound requests live in one system and outbound targets in another, you have lost the ability to see true demand.
- Route on expertise as requests arrive, not in a batch the week before. A request that sits unassigned for three weeks is a request that gets assigned badly under time pressure.
Expect the shape of demand to surprise you. If two-thirds of requests turn out to be about a topic you staffed one person for, you want to know that at week four, while you can still change who flies.
The week before: locking the schedule
This is where unmanaged programmes fall apart, because everything arrives at once: late requests, travel changes, executive additions, and a general desire to squeeze in more.
Three practices keep it under control.
Freeze the structure, not the schedule. Room allocation, meeting types, and approval rules stop changing. Individual bookings continue to move — they always will — but the framework they move within is stable.
Confirm everything explicitly. Every attendee should have received a confirmation with the time, the room, who they are meeting, and what was requested. Anything unconfirmed at this point is a probable no-show.
Run a conflict check. Walk the schedule looking specifically for: back-to-back meetings in distant rooms, anyone scheduled beyond their daily cap, rooms with no turnaround time, and meetings whose assigned expert is not actually on site that day. Each of these is invisible in a list view and obvious in a calendar view.
If your tooling validates people, rooms, and time together at booking, most of this check is unnecessary. If it does not, it is essential.
On site: running the day
The plan meets reality. Some things to have decided in advance:
Who owns the schedule during the event. One named person, with the authority to move things. Distributed authority produces conflicts within an hour.
How changes get communicated. When a meeting moves, the attendee, the expert, and the room need to know — automatically if possible. Manual notification is where the day breaks down, because the person making the change is also the busiest person in the building.
What happens to a no-show. Decide the wait time (ten minutes is standard) and what the freed slot becomes. A released slot should immediately be available to someone else rather than sitting empty because nobody knew.
How outcomes get captured. The best moment to record what came out of a meeting is in the two minutes after it ends. Make that as close to frictionless as you can — a short prompt on a phone beats a form somebody will fill in next week, which is to say never.
After the event: closing the loop
Within a few days, you should be able to state plainly:
- How many meetings were booked, held, rescheduled, and missed
- Which accounts and segments you actually spent time with
- What topics came up most, and which you were under-staffed for
- What the agreed next step was for each meeting, and who owns it
- How hard each room and each expert worked
The first four matter for the business. The fifth matters for the next event — it tells you whether to book more space, bring more people, or bring different people.
Getting this out quickly matters more than getting it perfect. A summary circulated three days after the event shapes follow-up while it is still warm. The same summary six weeks later is a historical document.
Common mistakes
Optimising for meeting count. More meetings with the wrong people is a worse outcome than fewer with the right ones, and considerably more expensive.
Scheduling back-to-back. It looks efficient and produces a cascade of late starts from mid-morning onward.
Assigning on availability alone. The meeting where nobody could answer the question is the one the customer will remember.
Treating the room as an afterthought. Book space in the same transaction as the person, or expect to be relocating meetings on the day.
Losing the record. If the outcome of each conversation lives only in individual memories, the programme cannot be evaluated and the next one cannot be improved.
No single owner on site. Someone has to be able to make a decision in thirty seconds. Committee scheduling does not survive a conference floor.
CallShark is being built to run programmes of this shape — one queue for inbound and outbound requests, expert matching, room reservation, and post-event reporting. The product is temporarily down.