What a Grip matchmaking export tells you about meeting demand

The show closed on Thursday. On Monday the commercial director wants to know how much meeting demand there was, because the rate card conversation for next year starts on Friday. Somebody pulls the Grip matchmaking export, opens it, and finds 11,400 rows. By Wednesday three people have produced three different answers, each of them arguable, none of them the same.

That outcome is normal, and the fix is not more analysis. The export is a list of meeting records with participants attached, and every row carries a state. Somebody asked. Somebody agreed or did not. A slot was allocated or was not. Possibly somebody turned up. Flattening those states into a single figure called meetings is where the three answers come from.

What the export actually holds

Grip's own documentation is unusually explicit about the object model underneath, which helps. Data types fall into three categories: participants, who log in to the platform; companies, which link to participants; and items, which link to companies and carry products or other content (Grip, 2026). Meetings hang off participants, so the export inherits that shape, and any grouping you do by company depends on the participant to company link being populated.

The meeting formats are wider than a column headed meeting suggests. Grip's feature list names pre-scheduled meetings, VIP meetings, a startup investor programme, speed networking, roundtables, a financial analyst day and business exchange meetings (Grip, 2026). A roundtable behaves nothing like a one to one appointment. If both sit in the same table and nobody filters, a mean meetings-per-buyer figure quietly averages a twelve-person session with a twenty-minute stand visit. Read the format field before you read anything else.

One structural detail is easy to miss. Grip states that meeting scheduling runs across up to eight consecutive days (Grip, 2026). A three-day show can therefore carry slots on build-up day and on the day after close, configured months earlier by someone who has since left. If your slot grid has more days than your show, the meetings-per-day denominator you were about to use is wrong.

Bundled platforms vary in how far they take this. ExpoPlatform publishes seven distinct meeting formats in its own product listing (ExpoPlatform, 2026), and mapping a bundled export onto your own schema is its own piece of work. The point that carries across vendors is that a meeting is a family of objects rather than one thing.

Which identifier joins the export back to your registration file

Before any of the counting is worth doing, settle what the participant column contains. A matchmaking platform issues its own participant identifier, and that identifier means nothing outside the platform. If your registration system pushed people in and carried a badge number or a registration reference into a custom field, the join is trivial and you should confirm which field holds it. If people self-registered inside the app, or if a hosted buyer was loaded by hand from a spreadsheet, there may be no shared key at all.

The fallback everybody reaches for is email, and it works better here than in most places, because the platform login is usually the email the person actually reads. It still fails on the reliable cases: the buyer whose assistant created the profile, the exhibitor representative who used a personal address because the corporate one bounced invitations, and the delegate registered under a group booking with a shared inbox. Count the failures rather than assuming them. Join the export to the registration file on lowercased email, count the unmatched participants, and put that number at the top of the report. If it is under 3 per cent, carry on. If it is 15 per cent, every company-level and segment-level cut you were about to publish is missing one participant in seven, and the missing ones will not be a random seventh.

Why would a whole exhibitor category be missing from the export?

Grip's knowledge base describes four permission settings held against each data type. One defines "which Data Types can be viewed by this Data Type on the application". A second defines "which Data Types can be recommended to this Data Type". A third defines "which Data Types this Data Type can request to have meetings with". A fourth sets which types can have their badges scanned by that type (Grip, 2026).

Read those four together and the consequence follows. A data type that appears in nobody's recommendation set, and that holds no request rights, produces zero meeting rows by construction. The export is silent about it, and silence reads to a reader as disinterest.

Take a worked case. Your press data type holds 240 profiles. The matchmaking export contains no meeting rows for any of them, and the marketing lead concludes that press do not want meetings and should be dropped from the concierge programme. Open the permission matrix and you find that press was excluded from exhibitor recommendations at set-up, sensibly, to stop journalists filling supplier diaries. The zero was a decision made in March and re-read in October as evidence.

The habit that prevents this costs twenty minutes. Before you interpret a single count, export the permission matrix alongside the meeting rows and mark every requester-to-recipient pair that was never possible. Those cells are not measurements of anything.

Requested, accepted and completed are three different numbers

A meeting request is cheap. It costs a click, and on most platforms the recommendation engine puts the candidate in front of the user, so the marginal effort of asking approaches zero. That makes request volume a decent measure of platform engagement and a poor measure of commercial intent.

An acceptance costs a calendar slot on both sides, which is scarce. It is the first number in the chain that carries real information, and it is also the first number bounded by something other than enthusiasm.

A completed meeting is a third thing entirely, and whether your export can even show it depends on how the meeting was marked as held. Some programmes capture it through a check-in, some through a rating prompt, some not at all. Where the field is absent, say so in the report rather than substituting the accepted count, and leave the booked against held comparison to the analysis that owns it.

Working the funnel on one edition

Illustrative numbers, but the shape is the shape you will find. One edition, 620 exhibitor representatives with request rights, 180 hosted buyers, and 4,300 general visitors who can also book. The export contains 9,840 requests, which split four ways: 5,900 from exhibitor representatives to hosted buyers, 1,610 from exhibitor representatives to general visitors, 1,480 from hosted buyers to exhibitor representatives, and 850 from general visitors to exhibitor representatives.

Acceptances by leg: 1,980 of the 5,900, which is 33.6 per cent; 402 of the 1,610, which is 25.0 per cent; 1,090 of the 1,480, which is 73.6 per cent; and 610 of the 850, which is 71.8 per cent. Total accepted is 4,082 against 9,840 requested, an overall acceptance rate of 41.5 per cent.

Somebody will now write that exhibitors are twice as good at getting meetings when buyers initiate them. That reading survives about ninety seconds of scrutiny.

Is a low acceptance rate a demand problem or a supply problem?

Put the slot grid next to the funnel. Three show days, seven bookable slots a day, gives each hosted buyer 21 slots. With 180 buyers that is 3,780 buyer-side slots for the whole programme.

Requests aimed at hosted buyers totalled 5,900, which is 32.8 requests per buyer against 21 slots. Before anyone expressed a preference, at least 11.8 requests per buyer had to be refused. Meetings involving a hosted buyer that were accepted came to 3,070, which is 17.1 per buyer, filling 81.2 per cent of the grid. A buyer holding 17 appointments across three days, plus travel, lunch and the conference programme, is not idling.

So the 33.6 per cent acceptance rate on exhibitor-initiated requests is mostly a statement about slot supply. The 73.6 per cent rate on buyer-initiated requests is mostly a statement about exhibitor availability, which is far less scarce, because 620 representatives share the other side of the grid. Two rates that looked like a behavioural finding turn out to describe the shape of the calendar.

The number worth putting in the board pack is the excess: 5,900 requests against 3,780 slots means demand for buyer time ran at 156 per cent of capacity. That is a defensible argument for a longer meeting programme, more hosted buyers, or both, and it survives someone asking where the number came from.

Where this stops

The export describes the platform. It does not describe the show floor, and the difference matters most for exactly the events that run the best matchmaking programmes.

Meetings arranged by walking up to a stand never appear. Neither do the ones agreed in the app and then held in the coffee queue an hour early, nor the ones a buyer's colleague attends in their place. On a show where the app is the primary scheduling tool this leakage is small. On a show where half the regulars have each other's mobile numbers, the export can understate real meeting activity by a wide margin, and no amount of care with the states inside it recovers what was never recorded.

There is a second limit that bites in the other direction. Request counts respond to interface changes. Move the recommendation carousel higher, add a push notification, and request volume rises without a single extra buyer wanting a single extra meeting. Year-on-year comparisons of request volume across a platform release are close to worthless, which is an argument for anchoring on accepted meetings per available slot, a ratio that survives most product changes. Getting the same discipline into a second system is where an API pull with its own state model starts, and holding both to one definition is the ordinary work of connecting event systems.

Start this week with one query. Group the last edition's export by requester data type and recipient data type, count rows in each cell, then open the permission matrix and strike out every cell that was never allowed. Divide what remains by the slot capacity on the recipient side. That single ratio is more use than the 11,400 you started with, and it takes an afternoon.