The event industry has more software than ever.
So why are planners still running important parts of conferences from spreadsheets, PDFs, email chains and text messages?
The problem is not that event technology lacks features. In many cases, the problem is that software handles the system beautifully while making the last mile of actual event work harder than it needs to be.
It is 6:45 a.m.
The conference has a registration platform, speaker portal, mobile app, website CMS, CRM, reporting dashboard and enough integrations to make the implementation diagram look like subway construction.
And the most important document in the building is still an Excel file.
Probably called something like:
FINAL_RunOfShow_v12_USE_THIS_ONE.xlsx
Everyone knows the file.
Three people have slightly different versions of it.
One person knows which one is actually correct.
And somebody printed it at 6:30 because nobody trusts the Wi-Fi enough to make their day dependent on a shared document.
This is not an unusual event technology failure.
It is normal.
That is what makes it interesting.
The event industry has spent years building increasingly sophisticated software platforms capable of managing registration, payments, websites, mobile apps, exhibitors, speakers, sponsors, analytics, CRM integrations, marketing, session selection, check-in and a couple hundred other things.
Yet event professionals still rely heavily on spreadsheets, email, shared drives, PDFs, screenshots, text messages and handwritten notes to manage the things actually happening around them.
The problem is not that all of this software is bad.
A lot of it is very good.
The problem is simpler:
Event technology often solves the system better than it solves the work.
There is a last-mile problem in event technology
Logistics companies talk about the “last mile.”
You can move a package thousands of miles through sophisticated distribution centers, aircraft, trucks and tracking systems.
But the hardest part may still be getting that package from the local distribution center to somebody's front porch.
Event technology has a version of the same problem.
A system may beautifully handle the big pieces of an event.
The attendee is registered.
The speaker exists in the database.
The session has been published.
The dietary request was collected.
The presentation was uploaded.
The information technically exists.
Then somebody asks:
What do I need to deal with right now?
That is where things often get weird.
The registration platform knows that 17 attendees requested accessibility accommodations.
The meeting planner needs to know whether all 17 requests have actually been handled.
The speaker portal knows every speaker has a record.
The education team needs to know which four people still haven't uploaded headshots.
The event website knows the agenda.
The production team needs to know that Ballroom C became Ballroom E fifteen minutes ago and whether that change made it everywhere it needs to go.
The reporting system contains all of the attendance data.
The executive director wants to know:
How many people came to Tuesday lunch?
And somehow that simple question requires exporting three reports and opening Excel.
The data exists.
Operational clarity does not always follow.
Registration is incredibly powerful right up until someone needs a weird report
Modern registration platforms can do remarkable things.
Conditional registration paths.
Promo codes.
Member pricing.
Session capacities.
Payments.
Waitlists.
Guests.
Dietary requirements.
Accessibility questions.
Badges.
APIs.
Automated confirmations.
Multi-event programs.
That is real capability, and organizations with complex programs genuinely need it.
Then the event gets close.
Suddenly the planning team needs a list containing:
- attendee name;
- organization;
- dietary restriction;
- guest name;
- Tuesday dinner status;
- Wednesday tour assignment;
- accessibility notes;
and nothing else.
There are probably 87 other fields in the system.
Nobody wants them.
So someone exports everything to CSV.
Deletes 79 columns.
Reorders the remaining eight.
Adds a yellow highlight.
And that spreadsheet becomes the operational version of reality.
There is nothing inherently wrong with exporting data.
CSV may be one of the most useful technologies in the history of events.
The interesting part is what happens next.
The export is supposed to be a snapshot.
Instead, teams start editing it.
Adding notes.
Correcting exceptions.
Sharing it.
Making another tab.
Then another.
Soon the registration system remains technically authoritative while the spreadsheet contains what the staff actually knows.
That is when the spreadsheet stops being a report.
It becomes middleware.
Speaker intake shows the difference between collecting data and managing work
Speaker management is another great example.
On paper, the problem sounds easy.
Send speakers a form.
Collect the information.
Done.
Except the actual list may include:
- name;
- title;
- organization;
- email;
- phone;
- bio;
- headshot;
- session title;
- description;
- presentation;
- AV requirements;
- travel information;
- disclosures;
- permissions;
- dietary needs;
- accessibility requirements;
- release forms;
- deadline status;
- revised versions of half of the above.
Building the form is not the hard part.
The hard part is knowing:
What is missing, who owes it to me, and what should I chase today?
That is an operational question.
Good speaker technology should make the answer painfully obvious.
Not buried in a report.
Not available after filtering six fields.
Not visible only to the administrator who took the implementation training.
Obvious.
Three headshots missing.
Five presentations overdue.
Two people never opened the request.
One person uploaded a headshot that appears to have been taken with a toaster.
Now the team knows what to do.
That is the difference between software that stores information and software that supports work.
Event websites solved publishing. They did not necessarily solve duplication.
Publishing an event website is easier than it has ever been.
That does not mean maintaining event information is easy.
One conference session might appear in:
- registration;
- the website;
- the mobile app;
- the speaker portal;
- signage;
- a printed program;
- production documents;
- staff schedules.
Then the room changes.
Which system gets updated first?
More importantly:
Which system is the source of truth?
If everyone on the team gives a different answer, the technology stack is not integrated.
It is synchronized by human memory.
And human memory becomes much less reliable around midnight during event week.
The industry talks a lot about integrations.
That's good.
But an API connection is not the same thing as an operational workflow.
The real test is not:
Can System A send data to System B?
It is:
When someone changes the room in System A, does the right information arrive everywhere else, correctly, quickly, and without somebody remembering to fix three other systems manually?
That is a higher bar.
It is also the bar the planner actually cares about.
Sometimes the problem really is just “Where am I sitting?”
This is where event technology occasionally becomes funny.
Imagine a gala.
The guest arrives.
They scan a QR code.
They type their name.
The answer they need is:
Table 27.
Maybe they also want to see where Table 27 is on the floor plan.
That is the entire problem.
It does not necessarily require:
- event registration;
- CRM;
- attendee engagement;
- mobile apps;
- messaging;
- ticketing;
- lead retrieval;
- marketing automation;
- enterprise implementation;
- twelve weeks of onboarding.
Sometimes software gets complicated because the product is solving a much larger problem than the user has.
That does not make the bigger product bad.
It makes it the wrong-sized tool.
This is one of the ideas I have become increasingly interested in:
Sometimes a narrow problem deserves a narrow tool.
The run of show may be the best example of all
Event production teams have been running shows from spreadsheets forever.
There are specialized run-of-show tools.
There are show-calling platforms.
There are collaboration systems.
There are databases.
There are production management platforms.
And there are still a staggering number of Excel and Google Sheets documents controlling very expensive events.
Why?
Because a run of show needs to be incredibly flexible.
It might contain:
- start times;
- durations;
- speakers;
- walk-in music;
- walk-out music;
- microphones;
- lighting cues;
- video rolls;
- stage directions;
- graphics;
- presenter notes;
- playback instructions;
- rehearsal changes;
- production comments;
- things the client added ten minutes ago.
Then someone says:
“Can we move this two minutes earlier?”
The tool needs to accommodate that immediately.
The producer does not want to submit a change request.
They do not want to open three screens.
They do not want to explain the software to a freelancer who arrived this morning.
They need to change the cell.
This is why specialized software loses to spreadsheets when the specialized software is slower.
That isn't planner resistance.
That is entirely rational.
The spreadsheet is winning because it is fast, flexible and forgiving.
If you want teams to replace it, the software has to be better at those things.
Not merely prettier.
Reporting is where all of this becomes almost comic
One of the great promises of event technology is better data.
And we should have better data.
Then someone asks:
“How many people attended the reception?”
Easy.
Except:
Are we counting people who registered for it?
People who checked in?
Guests?
Sponsors?
Staff?
People who changed their selection onsite?
Cancelled registrations?
People who showed up without selecting it?
Suddenly there are three datasets and four definitions of “attended.”
So the team exports the registration report.
Exports the check-in report.
Exports guest data.
Matches email addresses.
Removes duplicate rows.
Adds a formula.
Then proudly reports:
342.
Probably.
The problem is not necessarily reporting technology.
The problem is that events have messy data models because events have messy humans.
And the report someone needs often isn't:
Show me all registrations grouped by object type and status.
It's:
Did we order enough lunches?
Software needs to help answer the second question.
Why does this keep happening?
There are several reasons.
Platforms grow
Most software does not begin bloated.
It becomes bloated successfully.
Customers request features.
Sales teams need competitive checkboxes.
Large accounts have specific requirements.
New markets require different workflows.
Companies acquire other companies.
Modules get added.
The platform serves more organizations.
Every reasonable new requirement adds another option, field, permission, screen or setting.
Eventually, a platform capable of serving a 20,000-person international conference is also being used by someone who just needs to find a sponsor logo.
That creates friction.
Software often thinks in records. Planners think in moments.
A database sees:
Registrant ID 74823.
A planner sees:
The person standing at registration whose badge is wrong and whose boss starts speaking in 15 minutes.
Both views matter.
But the interface designed primarily around the first one may be frustrating when you're dealing with the second.
Event professionals work in moments.
Who is missing?
What changed?
What is late?
What needs approval?
What happens next?
What might break?
Those are operational views.
Events are basically several hundred edge cases wearing name badges
Software likes predictable workflows.
Events are not particularly cooperative.
The speaker brings a guest.
The sponsor uploads the wrong logo.
The attendee changes sessions.
The room gets moved.
The vegetarian meal becomes vegan.
The keynote presentation arrives during rehearsal.
Someone's name badge is spelled correctly in registration but incorrectly in another system because the integration synced three weeks ago.
These aren't unusual exceptions.
This is Tuesday.
Good event technology needs to handle exceptions gracefully because exceptions are the job.
Integration is harder than “Yes, we integrate with them”
APIs are enormously useful.
So are webhooks.
So are middleware tools.
But real integrations require:
- field mapping;
- authentication;
- permissions;
- decisions about which system owns which data;
- transformation;
- error handling;
- monitoring;
- testing;
- maintenance.
When vendors say two platforms “integrate,” that can mean anything from deep bidirectional synchronization to:
You can export a CSV from one and upload it to the other.
Technically integrated.
Bless its heart.
The buyer and the user may be solving different problems
The person selecting the platform may care about:
- SSO;
- security;
- enterprise contracts;
- central reporting;
- CRM integration;
- procurement;
- finance;
- permissions.
All reasonable.
The person onsite cares about:
Where is the keynote speaker?
The best platform for one person's needs may not be the best interface for the other's.
That tension is unavoidable.
But software design can acknowledge it.
The spreadsheet is not the enemy
We should probably stop pretending spreadsheets are embarrassing.
They are incredibly useful.
Excel and Google Sheets survive because they are:
- familiar;
- flexible;
- fast;
- customizable;
- shareable;
- editable;
- printable;
- forgiving.
For plenty of event workflows, a spreadsheet is exactly the right answer.
You do not need software for everything.
If your process happens once, involves six people and has no meaningful security or automation requirements, build the spreadsheet and move on with your life.
The problem starts when the spreadsheet quietly becomes an application.
You know the one.
It has 14 tabs.
Several formulas nobody is allowed to touch.
Color coding that only one employee understands.
An IMPORT tab.
An EXPORT tab.
A tab called LOOKUPS.
Another called OLD DO NOT USE.
Macros.
Links to other spreadsheets.
And if Karen leaves the organization, everyone is in serious trouble.
At that point, congratulations.
You built software.
You just built it in Excel.
A simple way to think about it
A spreadsheet is probably fine when:
- the workflow is temporary;
- the dataset is small;
- only a few people need access;
- permissions don't really matter;
- automation isn't necessary;
- a mistake is easy to fix.
The spreadsheet is getting uncomfortable when:
- the workflow repeats every event;
- multiple people edit simultaneously;
- files need to be attached;
- deadlines matter;
- reminders are manual;
- version control is becoming a problem;
- people regularly ask, “Which one is current?”
The spreadsheet has become accidental software when:
- it holds business-critical information;
- multiple events depend on it;
- permissions matter;
- data is repeatedly imported and exported;
- automations rely on it;
- one person's formulas keep the operation alive;
- errors can affect attendees onsite.
That is usually the point where software should help.
Not because spreadsheets are bad.
Because the workflow has outgrown them.
This changes how I look at Event Tech Atlas
One thing working on Event Tech Atlas has made painfully clear is that there is no shortage of event technology.
There are tools for nearly everything.
The question isn't simply:
Does software exist for this?
It probably does.
The better questions are:
Is it the right size for the problem?
Can the organization realistically implement it?
Does it fit the way the team already works?
Will people actually use it?
Does the integration do what everyone thinks it does?
Does the software remove complexity or just move it somewhere less visible?
Feature comparison is useful.
Fit matters more.
Small software can still be useful software
This has also influenced the way I think about building event tools.
For years, software companies have understandably tried to expand.
More modules.
More use cases.
More customers.
More enterprise capability.
But there may also be room for the opposite approach.
Solve one annoying problem.
Solve it clearly.
Make it affordable.
Make setup easy.
Then stop.
Maybe the tool helps attendees find their seats.
Maybe it tracks speaker files.
Maybe it manages crew call times.
Maybe it keeps a run of show current.
Maybe it tells someone whether the room is actually ready.
Maybe it tracks signage revisions or sponsor deliverables.
None of those problems necessarily requires replacing the organization's primary event platform.
That is an important distinction.
The future may not be one giant event system that does absolutely everything.
It may be a solid core platform surrounded by smaller tools that are particularly good at specific jobs.
The challenge, of course, is making those tools work together cleanly.
Otherwise we have simply invented another integration problem.
AI won't magically fix this either
AI can be genuinely useful in event operations.
It can summarize changes.
Identify missing information.
Classify incoming requests.
Spot inconsistencies.
Draft communications.
Answer questions across structured data.
Help generate reports.
Those are interesting applications.
But AI cannot rescue a workflow nobody understands.
It does not fix bad data.
It does not decide who owns the source of truth.
It does not make a broken integration reliable.
It does not solve unclear processes.
AI on top of a bad workflow is still a bad workflow.
It just writes better status updates.
What should good event software actually do?
I don't think the answer needs to be particularly complicated.
Good event technology should help the team:
- Solve a clear problem.
- See the current status quickly.
- Avoid entering the same information repeatedly.
- Handle exceptions without breaking everything.
- See what is missing.
- Work effectively onsite.
- Get their data back out cleanly.
- Integrate where integration actually matters.
- Learn the tool without needing a certification program.
- Get out of the way once the job is done.
That list will look different for different organizations.
A large association with 50 events and complex member pricing needs something very different from an independent planner producing four galas.
That's fine.
The goal is not simplicity for its own sake.
The goal is appropriate complexity.
The real software demo should happen at 7:15 a.m.
Software demos are lovely.
Every record is complete.
Every speaker uploaded the correct file.
Every attendee followed instructions.
Every integration synced.
Nobody has changed anything five minutes before the session.
Of course the dashboard looks fantastic.
Here is the test I care about:
It is 7:15 a.m. Doors open at 8:00. What does the planner need to know right now?
Which speaker is missing?
Which room isn't ready?
Which file changed overnight?
Which attendee needs help?
Which sponsor still hasn't provided signage?
Which cue changed?
What could derail the next 45 minutes?
If the software can answer those questions quickly, now we have something useful.
That is the environment event technology ultimately has to survive.
Not the demo.
The ballroom.
We probably don't need more software. We need better-fit software.
There will always be a place for large event platforms.
There should be.
Complex organizations have complex needs.
There will also always be a place for spreadsheets.
There should be.
Sometimes a spreadsheet is perfect.
And I think there is an increasingly useful middle ground:
Focused tools that solve narrow operational problems without trying to become the center of the event universe.
The measure shouldn't be how many features a platform has.
It shouldn't be how impressive the dashboard looks.
It shouldn't even be whether it uses AI.
The question is much simpler:
Did the work get easier?
If the answer is yes, keep it.
If the answer is no—and you still need a spreadsheet sitting beside the software to explain what is actually happening—
there may still be some work left to do.