Skip to content
Eventogy
Post

Your event ended on Thursday. The questions started on Friday.

A three-day event runs without a hitch, then one question lands: who came in on day two? Cem Kocu on why proving an event is now part of the job.

Cem Kocu, Founder and CEO of EventogyCem KocuFounder and CEO, EventogyMore from Cem28 Sep 2026 · 6 min read

A corporate event is coming to a close. Three intense days, run without a hitch, and by every measure a success. But one thing we've learned at Eventogy is that an events manager's job doesn't end when the event does. As the reports are pulled together and sent out to stakeholders, one question lands that sends the team into a panic.

Who actually came in on day two?

Every guest had been scanned on arrival, using QR code badges printed on site. What nobody had quite registered was that it was the ticket being scanned, and not the person holding it. And nobody was scanned on the way out.

For a show of this profile, tickets needed to expire as their owners left, which meant scanning them at the exits. There was no system on the exits to do it. So guests walked out with tickets that were still valid and handed them to colleagues, friends and family, who used them the following day.

With no data to go on, the events team went round every exit asking security guards to recall who had left, working from photographs and descriptions alone. It took an afternoon. They got an answer, and it was incomplete and badly wrong.

The event was a success, and nobody had realised the record of who attended it was wrong. A scan tells you a ticket came in. It doesn't tell you who did.


The guest list view: attendees and the organisations they are attending for, held as fields rather than as a spreadsheet column.

The event is still the job, but proving it has become part of the job too, and that part grows every year. As the event closes, a whole new set of responsibilities opens up, and almost all of them are about data.

The questions used to be how the event went and whether the food was any good. Now the events team faces a different set:

  • Who approved it?
  • Who attended, and which part of the client's business do they work for? Was anyone there who shouldn't have been?
  • What did each guest cost, and did anyone go over the firm's hospitality limit, typically £100 to £250 a head?
  • Where is the evidence?

The catch is that she needs to know these questions are coming before the event starts, because the answers have to be captured while it happens.

Each answer also runs deeper than it looks. Global Bank Limited is one client, but five attendees from Global Bank are five separate records. Which region does each one represent? Which business line? Are they all from the bank itself, or from subsidiaries with rules of their own?

Our own support team knows how hard this is. One of the toughest jobs they face is pulling data together from different places, from our platform and from the other suppliers working on the same event, and then matching it all up. Our events managers do exactly the same job, usually against a deadline.

Even the choice of software is now under scrutiny. Banks have to be able to show why they chose each of their suppliers.


Some years ago, we took a call from a frustrated client. An events manager at a large bank had found a batch of attendee records missing, and the platform was the obvious suspect.

With a claim like that, we put people on it straight away to find the cause, confirm it and fix it. Humans are part of every events operation, and we have made our share of mistakes. This time, it turned out that someone else at the client had emailed our team asking for those records to be deleted, and our team had done it. Nobody had told the events manager.

We found the email eventually, but it took far too long, and it showed us something uncomfortable: a change had been made that nobody could easily see or explain. From that day, we decided nothing should happen on Eventogy without leaving a trace of who did it and when. That decision has settled questions like this for us ever since, whichever way the answer went.

A scan tells you a ticket came in. It doesn't tell you who did.

The events manager is now where we were that day. The difference is that the people asking her are colleagues, stakeholders and sometimes other suppliers. She needs the same thing we built for ourselves.

I keep coming back to the word defensibility. To me it's the perfect description: a quiet line of defence that lets people answer the questions that come from compliance, audit and risk. It's personal, because it goes back to that missing-records call. But it isn't the word our clients use.

Our clients work in some of the most tightly governed industries in the world. Governance is the bread and butter of banking and law. So when I look for the word that describes what I want built into our events platform, governance is the right one. For the events manager, it means exactly what defensibility means to me: being able to stand behind every decision afterwards, without rebuilding it from memory.


Sunday nights are my barometer. For my team, it's whether Sunday evening fills them with dread about the week ahead. I apply the same test to our clients. If any of them resent the thought of opening our product on a Monday morning, I've failed at the one thing it's for.

Eventogy should be a silent partner to the work events teams actually do. Nobody should start a Monday knowing they have hours of wrestling with their events software ahead of them. As the founder, with product ultimately answering to me, that's the test I hold everything to.

That's why governance, done properly, should mean less work, not more. The proof should gather itself while she runs the event. If the sign-off happens in the system, the record already exists. If the guest list already shows who each guest works for and what was spent on them, the hospitality record has already written itself.

The load sits with my team. The record keeping should be invisible to hers and appear only when they need it. At the very least it should be silent, and at best nobody should notice it happening at all.

The person approving an event still has to approve it. Beyond that, nothing we build should slow down the events team's own work.


Over thirteen years, we've kept many of the same clients. One of our earliest mantras was software that is simple, beautiful and secure. All three still sit at the core of Eventogy, and simple still comes first. Keeping things easy and fast isn't up for negotiation.

The habit of recording everything was always there too. What's changed is that the events manager's job now depends on that record, and my job is to put it in front of her the moment she needs it.

The platform has been reimagined around a job that changed. In August I wrote that one-off work for a single client is absorbed as extra effort on our side and never bent into the product. That discipline is why the product stayed clean and consistent enough to be reimagined rather than replaced.

We are not a compliance company, and we never will be. Our job is still to help events teams run brilliant events, with governance built into the way the work gets done.


So if you're a Head of Events with thirty seconds in front of a supplier, you don't need a demo or a feature list. Two questions will do, and you can ask them of anyone, us included.

If a ticket changes hands, does your platform know?

When someone deletes a guest, can you show me who did it, when, and why?

If either answer starts with a pause, you already know how the afternoon after your next event will go.

Whitepaper

Strategic Events for Legal Firms

The longer argument, with the working.

Share
LinkedIn
Written by
Cem Kocu, Founder and CEO of Eventogy

Cem Kocu

Founder and CEO, Eventogy

Founded Eventogy in 2013 and has led it since.

Bring the whole programme onto one record.

Book a demo