Meeting scheduling as an assignment problem your team can inspect

The schedule came out on a Thursday and the complaints started an hour later. An exhibitor's highest scoring buyer, 0.81, had no meeting. A pair scoring 0.41 had a table at 11am on day one. The concierge team asked why, and the honest answer was that the scheduler was a loop with three nested conditions and nobody could reconstruct which one had fired.

A meeting scheduling assignment problem has a name, a standard formulation and seventy years of literature behind it. Writing the formulation down before choosing a solver is what makes the output explainable, and explainability is what the team standing in front of an angry exhibitor actually needs.

What kind of problem is this?

At its simplest, an assignment problem. You have a set of agents, a set of tasks, a score for each pairing, and you want the set of pairings that maximises the total score with each agent taking one task.

Kuhn published a method for solving exactly that in Naval Research Logistics Quarterly in 1955, crediting earlier work by two Hungarian mathematicians in the name he gave it, the Hungarian method. It solves the one-to-one case in polynomial time, and it is the reference point for everything that followed.

Event meeting scheduling is that problem with four complications bolted on. There are multiple time slots, so a pair needs both a match and a moment. Participants have availability windows that differ. The room has a fixed number of tables, so the number of simultaneous meetings is capped. And each participant has a quota, often a minimum as well as a maximum, since a hosted buyer who was promised twelve meetings and got four is a refund conversation.

Each complication is ordinary in operations research and none of them fits the 1955 method directly. Together they turn the problem into an integer programme, which is a well trodden category with off-the-shelf solvers.

Writing the formulation down

The formulation is short enough to fit on one screen, and putting it there is the single highest value hour in this whole area of work.

Define a binary variable for each combination of buyer, exhibitor and slot, set to 1 when that meeting happens then. The objective is to maximise the sum of the match score for each pair over the variables set to 1.

The constraints are these.

• One meeting per participant per slot. For each buyer and each slot, the variables sum to at most 1. Same for each exhibitor, adjusted upwards where an exhibitor has several staff and several tables.
• A pair meets at most once. Summed across slots, each buyer and exhibitor combination is at most 1.
• Table capacity. For each slot, the total number of meetings is at most the number of tables available in that slot.
• Availability. Variables are fixed to 0 where either party is unavailable, which is the cheapest constraint in the model because it removes variables instead of adding rows.
• Quotas. For each buyer, the total across exhibitors and slots is at most their maximum and at least their contracted minimum.

The minimum quota is the constraint that turns a comfortable model into a hard one, because it can make the problem infeasible. A buyer with a twelve meeting minimum, availability for nine slots and no interested exhibitors in three of them cannot be satisfied, and the model will refuse to produce any answer at all rather than tell you which buyer is impossible. Model minimum quotas as a soft term with a penalty and the solver will produce a schedule that misses two of them and names the two, which is what you can act on. Where the line between hard and soft belongs is its own decision and I26 covers it.

Keeping the model small enough to solve

The naive model is enormous and almost all of it is waste.

Take 400 hosted buyers, 300 exhibitors and 16 meeting slots across two days. That is 400 times 300 times 16, which is 1.92 million binary variables, most of them describing pairings nobody would ever propose.

Prune before you build. Keep the top 25 candidate exhibitors per buyer by match score, which leaves 400 times 25, or 10,000 pairs. Multiply by 16 slots and the model has 160,000 variables, a size that any modern solver handles in seconds on a laptop.

Pruning is a modelling decision with a cost, and the cost is that a meeting outside the top 25 can never be scheduled however convenient it would have been. Check the cost directly: run the scheduler at 25 and at 40 candidates per buyer and compare the total scheduled score and the number of filled quotas. If the difference is under a per cent, the pruning is free. If it is large, your score is not separating candidates well and that is a scoring problem showing up in the scheduler.

Which solver, and what the literature actually says

Bofill, Coll, Garcia, Giraldez-Cru, Pesant, Suy and Villaret presented constraint solving approaches to the business-to-business meeting scheduling problem at IJCAI in 2023, as an extended abstract of their journal work. They formulate the problem as scheduling meetings between given pairs of participants while minimising idle time in participants' schedules, subject to availability and accommodation capacity, and they compare constraint programming, mixed integer programming and maximum satisfiability encodings on it.

Two things in that description are worth carrying away. The first is that this exact problem, with these exact constraints, is a recognised benchmark in the constraint solving community, so an organiser writing a bespoke heuristic is competing with a research literature. The second is that the objective in their formulation is idle time, which is a different objective from total match score and produces different schedules. Deciding which one you are optimising is a product decision that changes what buyers experience on the day.

My own view is that a general solver called through a modelling layer is the right first build for any organiser past a few hundred meetings, because the model stays readable and the constraints stay separate from the search. The counter-argument, that a greedy pass is faster to build and gets most of the value, is a serious one and it is what I21 argues.

Whatever solver you use, check its answer with code it did not write. A short independent verifier that reads the produced schedule and re-tests every constraint takes an afternoon: no participant in two places at once, no slot over table capacity, no pair meeting twice, no meeting outside a declared availability window. It catches the class of bug that hurts most, which is a constraint that was written into the model incorrectly and therefore satisfied perfectly. Run the verifier on every schedule before it goes out, log the result, and the first time somebody claims the system double booked them you can answer in a minute.

Making the output inspectable

The formulation gives you something a loop never will, which is a reason for every rejection.

After a run, take every proposed pair that did not get scheduled and classify it by the constraint that bound. Four categories cover almost everything: no common free slot, buyer quota reached, exhibitor quota reached, and no table free in any slot where both were available.

On a run with 3,200 proposals and 2,180 placed, the 1,020 unplaced might split as 640 with no common slot, 220 hitting an exhibitor quota, 160 hitting table capacity across the qualifying slots. Those three numbers point at three different fixes. The 640 is an availability problem, and it is usually solved by collecting arrival and departure times properly. The 220 is a commercial choice about how many meetings a stand can take. The 160 is a hall capacity question, which table allocation in I23 handles in detail.

Publish that breakdown after every run. It converts an unexplainable schedule into a short list of operational decisions, and it gives the concierge team a sentence to say to the exhibitor whose 0.81 buyer never appeared.

Where this stops

An optimal schedule is optimal against the objective you wrote, and the objective is a simplification of what people want. Maximising total match score will happily give one buyer twelve strong meetings and another buyer four, because twelve strong plus four weak beats eight and eight on a sum. Adding fairness to the objective is possible and it changes the answer, and anyone who has watched a hosted buyer compare diaries over dinner knows which version generates complaints.

The second limit is that the input scores carry all the model's judgement. An assignment solver is a machine for taking your score seriously, and it will take a badly calibrated score seriously too, placing a 0.62 above a 0.61 when the difference is noise. Scheduling optimisation on top of an uncalibrated score is precision applied to the wrong quantity.

The third is timing. Everything above assumes a batch run before the show. Real programmes change hourly once the doors open, and a full re-solve at 10am on day one will move meetings people have already planned around. The usual answer is to freeze confirmed meetings as fixed variables and re-solve only the remainder, which keeps the model useful without rearranging somebody's morning.

Start by writing the formulation for your own show on one page: the variable, the objective, and each constraint with the number that goes in it. Count your slots, your tables and your quota rules while you do it. Most teams discover at that point that two of their constraints contradict each other, and finding that on paper is considerably cheaper than finding it in a schedule your matchmaking team has already published.