Meetings Data and Reporting

Most meetings programmes fail at data not because the wrong fields were chosen, but because the same field was filled in differently by six people over eighteen months. The design question is less “what should we capture” than “what will still be captured consistently”.

This page covers the mechanics. Why it matters is on meetings spend visibility; the reports at the other end are on event spend reporting.

Start from the questions, not the fields

Design the dataset backwards. Write down the questions the programme exists to answer, then capture what answers them.

How much are we committing, and how is that distributed across departments?
Which suppliers and venues do we use repeatedly, and at what total value?
How far ahead do requirements reach us, and what does that do to what we can negotiate?
What proportion of activity goes through the agreed route?
What are we losing to cancellation, postponement and attrition, and what is already committed for the next twelve months?

What to capture, and when

Quality depends on capturing each field when it is naturally known. Delegate numbers at briefing are a guess; at contracting, the contracted figure; after delivery, the actual. Three fields, not one updated three times.

A workable core dataset by lifecycle stage

Request / brief

Fields to capture: Requester, department, cost centre, event type, business purpose, dates, estimated attendees, indicative budget, date brief received
Why it matters: Records demand at source and starts the lead-time clock — the only point where intent is recorded, not inferred.
Provided by: Requesting department

Sourcing

Fields to capture: Venues approached, proposals received, rates quoted, preferred supplier used or not, reason for selection
Why it matters: Evidences competition. Without it, “we negotiated” is an assertion.
Provided by: Sourcing team or agency

Contracting

Fields to capture: Supplier, contracted value, deposit schedule, payment terms, attrition, cancellation schedule, contract date
Why it matters: Converts activity into a commitment with a known liability profile.
Provided by: Sourcing team, reviewed by procurement

Changes before delivery

Fields to capture: Date changes, attendee revisions, scope additions, cancellation or postponement and the reason
Why it matters: Change is where budgets are lost. The reason makes the pattern visible.
Provided by: Booking manager

Delivery

Fields to capture: Actual attendees, actual dates, on-site additions, supplier performance notes
Why it matters: Closes the gap between contracted and actual.
Provided by: Event owner

Reconciliation

Fields to capture: Final invoiced value, variance to contract, variance reason, invoice date
Why it matters: Produces the actual figure and explains the difference. The variance reason is the field most often skipped and most needed.
Provided by: Finance with the event owner

Post-event

Fields to capture: Objective met or not, feedback summary, would we use the venue again
Why it matters: Feeds supplier review and the measures on meetings and events KPIs.
Provided by: Event owner

Lifecycle stage	Fields to capture	Why it matters	Provided by
Request / brief	Requester, department, cost centre, event type, business purpose, dates, estimated attendees, indicative budget, date brief received	Records demand at source and starts the lead-time clock — the only point where intent is recorded, not inferred.	Requesting department
Sourcing	Venues approached, proposals received, rates quoted, preferred supplier used or not, reason for selection	Evidences competition. Without it, “we negotiated” is an assertion.	Sourcing team or agency
Contracting	Supplier, contracted value, deposit schedule, payment terms, attrition, cancellation schedule, contract date	Converts activity into a commitment with a known liability profile.	Sourcing team, reviewed by procurement
Changes before delivery	Date changes, attendee revisions, scope additions, cancellation or postponement and the reason	Change is where budgets are lost. The reason makes the pattern visible.	Booking manager
Delivery	Actual attendees, actual dates, on-site additions, supplier performance notes	Closes the gap between contracted and actual.	Event owner
Reconciliation	Final invoiced value, variance to contract, variance reason, invoice date	Produces the actual figure and explains the difference. The variance reason is the field most often skipped and most needed.	Finance with the event owner
Post-event	Objective met or not, feedback summary, would we use the venue again	Feeds supplier review and the measures on meetings and events KPIs.	Event owner

That is roughly thirty fields, which sounds heavy until you note that most are entered once, by one person, at a point they already have the information.

Data quality is a definitions problem

Nearly every data-quality failure traces back to an undefined term rather than a careless person. “Attendees” means the contracted number to one person and the number who turned up to another. “Cost” means the venue invoice to one and the fully loaded figure to another. These are definition errors, and they compound until someone compares two years.

The remedy is unglamorous. A one-page data dictionary does more for reporting quality than any amount of analysis applied afterwards.

Fix the value lists. Event types, departments, suppliers and cost centres are chosen, never typed.
Name suppliers canonically. One venue entered four ways is four suppliers, and your meetings procurement consolidation argument disappears.
Date everything. Brief received, contract signed, event delivered, invoice received.
Record reasons, not just outcomes. A cancellation with no reason says money was lost. With one, it says whether it was avoidable.
Keep estimate, contracted and actual separate. Overwriting one destroys the variance information that makes reporting useful.

Who owns the data

Ownership fails in a characteristic way: everyone contributes, nobody is accountable, and the dataset degrades until it is abandoned. Three roles need naming.

The data owner is accountable for the dataset being complete and correct — usually whoever owns the programme. The contributors are whoever touches a requirement; where sourcing sits with an external partner under an outsourced meetings management arrangement, capture at sourcing and contracting belongs in their scope.

The consumers are procurement, finance and budget holders. A consumer who never challenges a report has stopped reading it.

From requirement to report

Captured at the brief

Requesting department
Purpose of the meeting
Delegate numbers
Dates and lead time
Indicative budget

Captured at sourcing

Venues approached
Rates quoted
Negotiated position
Venue selected
Preferred supplier used or not

Captured at contract

Contracted value
Cancellation terms
Attrition and minimum spend
Payment terms
Signatory and approval

Captured after the event

Final value against contracted
Changes and cancellations
Attendance against forecast
Supplier performance notes

Which makes these answerable

Spend by department
Spend by venue and supplier
Preferred supplier adoption
Average lead time
Cancellation exposure
Negotiated value achieved

None of this requires a new technology platform to begin with. It requires the information to be captured in the same way each time, by whoever handles the brief.

Each stage adds fields rather than replacing them. Reporting is assembly, not collection — an unanswerable question means the failure happened upstream.

The reporting cycle

Cadence should follow the decisions it supports. Most programmes settle on a monthly operational view, a quarterly commercial review and an annual category review — detail on event spend reporting.

Fix the cycle before the first report, because irregular reporting trains recipients to ignore it. Expect the first cycles to surface data problems rather than commercial findings.

How far a spreadsheet gets you

We do not operate a proprietary real-time technology platform, and we will not imply a programme needs one to start. It does not.

A single well-structured spreadsheet — one row per event, the fields above as columns, fixed value lists, one accountable owner — comfortably supports a programme handling dozens of events a year. It produces supplier concentration, departmental distribution, lead-time analysis, variance and a forward commitment view: the outputs that change commercial decisions.

Its limits are real: concurrent entry, version control, audit trail, enforced rather than recorded approvals, and volumes past the point where manual entry stays reliable. Organisations across multiple offices hit concurrency first.

Enterprise programmes frequently do involve technology, and that is legitimate. It is a separate decision, taken once you know what you are measuring — buying a platform to find that out is an expensive route to an answer a spreadsheet would have given.

Frequently asked questions

01How many data fields should we capture?

Typically around thirty across the lifecycle, captured at seven or eight distinct moments. The failure mode is not under-collection but collecting so much that nothing is collected reliably.

02Can we run a meetings programme on a spreadsheet?

Yes, and many should, at least initially. With fixed value lists and one accountable owner it produces most of what changes a commercial decision. Reach a constraint — concurrency, audit trail, enforced approvals, volume — and the case for technology becomes concrete rather than theoretical.

03Do you provide a technology platform?

No. We do not operate a proprietary real-time platform or dashboard product, and we would rather say so than let it be assumed. What we provide is sourcing, supplier and programme capability, with a capture and reporting discipline that works alongside your existing systems.

04How do we handle inconsistent historical data?

Draw a line. Clean enough for a rough baseline using how to measure meetings spend, accept it is imprecise, then apply the new definitions from a start date.

05Who should enter the data?

Whoever already has the information at that point. Asking one central person to chase it all makes data entry a full-time job nobody has been given.