Back to the overview
In practice

Who calls the caterer when it goes wrong?

An event often has five parties working at once. Without agreement on who decides what, every problem lands with you.

Team MiceBird5 min read
Five supplier bars on one shared timeline with a common moment marked

An average event has a venue, a caterer, a technical company, a photographer and sometimes a decorator. Five parties, five contacts, five schedules of their own.

On paper that works fine. In practice every question arising on the day runs through one person — and that's you, regardless of whether anyone agreed it.

Decide in advance who decides

The question isn't who the supplier is, but who decides when something changes. That's a different list and it's rarely made explicit.

SituationWho decides
Programme overruns by half an hourClient, with the venue
Twenty more guests than notifiedVenue calls caterer, client pays
Technical failure mid-presentationTechnical company, venue informs client
Outdoor element in rainClient decides, by an agreed time

That last point matters most: for a weather-dependent element you agree not only who decides, but when. "We'll see how it goes" means that at five o'clock nobody has decided anything while set-up should have started at four.

One shared run sheet, not five

Every supplier has their own schedule, and at detail level those schedules always contradict each other somewhere. The caterer expects a room empty by four; the technician is building until half past.

So put together one timeline that everyone gets, with all parties in it. Not as an email attachment, but as the version everyone looks at. The conflicts you then see — two parties needing the same space at the same time — are precisely the ones that otherwise surface on the day.

Put every supplier contact's mobile number in the run sheet, and share it with the client too. Half the calls you get are from someone who actually needed somebody else.

The hour before doors

Most problems arise not during the event but in the last hour before it: something wasn't delivered, someone is stuck in traffic, the room isn't ready.

So schedule a fixed moment, say ninety minutes before doors, when everyone gathers briefly. Five minutes, standing. What's ready, what isn't, who needs something.

That quarter of an hour costs nothing and moves problems from "during the event" to "before the event" — where they're still solvable.

Fix one contact per party

At larger suppliers you deal with an account manager at quote stage and with someone you've never met on the day. That's normal, and it goes wrong at one point: the agreements you made lived in the first person's head.

So ask every supplier two things: who is on site on the day, and has that person read the run sheet? The answer to the second is surprisingly often no.

A short email to that person two days ahead, containing only the lines that concern them, solves more than a complete run sheet nobody opens.

Agree who talks to the client

At an event with five suppliers, the client can be told five different things about the same delay. That's how an organiser ends up hearing that the sound is fine from the technician and that it isn't from the caterer's waiter.

So agree one thing: suppliers report to the venue, the venue reports to the client. Not because the client shouldn't know, but so that what they hear is consistent and comes from someone with the full picture.

It also protects your suppliers. A technician explaining a problem directly to a client will be asked to solve something that isn't theirs to solve, and the answer will be a promise nobody can keep.

Record what went wrong

Afterwards everyone is tired and everyone goes home. Yet that's the only moment when you know exactly what didn't run well.

Five lines in the run sheet, straight after. Next time you work with the same suppliers, you start there — and you'll be the only party who remembers what happened last time.

From request to invoice in one platform

Try MiceBird free for fourteen days. Your offering in it, your branding around it — no implementation project.

An event manager arranging an event in MiceBird on her laptop