Event technology is often bought to solve a visible problem: registration queues, a difficult hybrid audience, poor session attendance data or a sponsor asking for more leads. Those are reasonable reasons to look at it. Trouble starts when the platform, app or gadget becomes the project, rather than serving the conference it was meant to support.

I have seen event teams spend weeks debating features that delegates will barely notice, while leaving basic operational questions unanswered. Who will support the registration desk when a QR code will not scan? What happens if the venue Wi-Fi is overloaded? Can the speaker see the confidence monitor from the lectern? Technology does not remove these questions. It often adds a few more.

The useful approach is to treat it as part of event delivery: a set of tools with owners, dependencies, costs and failure points.

Event technology should begin with an operational problem

A conference app may be useful, but “we need an app” is not a requirement. A requirement might be that delegates need to find parallel sessions quickly, that organisers need reliable attendance information, or that a sponsor needs a sensible way to arrange meetings without harvesting piles of business cards.

The distinction matters. Once the real problem is clear, the choice of technology becomes narrower and more defensible. It may turn out that printed directional signage, a better session chair briefing and two members of staff at a busy junction will do more for delegate flow than a sophisticated app map.

This is not an argument against technology. It is an argument against buying functions before understanding the job. Good event technology makes a process clearer, faster or more reliable. If it creates another process for the team to manage, it needs to earn its place.

For each proposed tool, I would want a straightforward answer to three questions: what decision or task will it improve, who is responsible for it during the event, and what happens when it is unavailable? If the answers are vague, the supplier demonstration may be ahead of the event plan.

The areas where technology earns its keep

Some areas consistently benefit from well-chosen systems, particularly at multi-stream conferences and international events.

Registration and badging are the obvious example. Pre-event data validation, payment status, invitation rules and badge production can reduce errors and shorten queues. But the system only works well when the data is clean and the desk layout reflects real arrival patterns. A beautifully designed self-service kiosk is of limited value if half the delegates arrive with accented names, missing confirmations or last-minute substitutions that the database cannot handle elegantly.

Session management is another strong use case. Digital agendas, room-capacity reporting and scanning can help organisers understand how delegates move around a programme. The data is useful, but should be treated carefully. A scan at the door does not prove that someone stayed for a full presentation, and an empty room may reflect an unfortunate programme clash rather than a weak topic.

For exhibitors and sponsors, lead capture can be worthwhile where the process is transparent and the follow-up is realistic. Collecting a thousand names is not success if the sponsor receives incomplete records, unclear consent information or no context about why a delegate stopped at the stand.

Hybrid and streamed content can extend access beyond the room, but it is a production discipline rather than simply a camera in the back of the hall. Online viewers need clean audio, considered camera positions, slides they can read, a moderator who includes them and a proper plan for questions. The experience does not need to mirror the room exactly. It does need to be deliberately produced.

Integration is usually the hidden cost

Most event systems look convincing in isolation. The difficulty appears when registration data must feed an event app, badge printing, access control, a CRM system, hotel allocation and reporting. Each handover introduces questions about field formats, duplicate records, timing, permissions and ownership.

A supplier may say that a platform integrates with another platform. That can mean anything from a well-tested automatic connection to a spreadsheet export that someone must upload twice a day. Neither is inherently wrong, but the difference affects staffing, risk and budget.

Ask practical questions early. Which system is the source of truth for delegate information? When does data move between systems? Can changes be made on site? Who has permission to make them? What reports are required, by whom, and when?

This is particularly important for European conferences, where delegates may register from different countries, pay in different currencies and have legitimate concerns about how their information is used. Data protection is not a paragraph for the registration page to deal with at the end. It affects what information you collect, why you collect it, where it is stored and how suppliers handle it.

The most useful rule is simple: collect the minimum personal data needed to deliver the event and explain its use plainly. If a feature depends on tracking delegates around a venue, consider whether the benefit genuinely justifies the intrusion and the operational burden.

Do not confuse digital with self-service

Self-service registration, digital wayfinding and automated notifications can improve an event. They can also leave a delegate feeling abandoned, especially after a delayed flight, a last-minute room change or a lost confirmation email.

At the registration desk, technology should give the team better information and more options. It should not prevent them from helping someone standing in front of them. Keep an agreed route for exceptions: name corrections, replacements, missing badges, access requirements and payment queries. The exact arrangement will depend on the event, but it should be designed before doors open, not invented while the queue grows.

The same applies to speaker technology. Presenters vary enormously in their confidence with slide portals, polling systems and remote clickers. A clear pre-event instruction is helpful, but it does not replace a technician or stage manager who can solve a problem calmly during a changeover.

Connectivity is part of the production plan

Venue Wi-Fi is frequently described as available, which is not the same as sufficient. A connection suitable for guests checking email may be wholly inadequate for live polling, webcast uploads, exhibitor demonstrations, production communications and several hundred delegates joining the network at once.

Before relying on connectivity, establish what service is being supplied, where coverage is reliable, what bandwidth is dedicated, how many devices are expected, and whether the production team has a separate connection. Test in the actual rooms where possible, not only in an empty foyer months before the event.

Mobile signal is worth checking as well. It is a useful fallback, but conference venues can be awkward places for it: underground rooms, thick walls and a sudden concentration of people all attempting to use the same network. A backup is only a backup if it has been considered and tested.

Technical production teams are used to asking what happens if a projector, microphone or playback machine fails. Apply the same discipline to platforms and networks. It may mean a paper list at registration, downloadable speaker slides held locally, a manual room-count method, or a clear message to delegates if an app feature is unavailable. The proportionate answer depends on the stakes.

Event technology needs an owner on site

One of the commonest gaps in a technology plan is ownership. A platform may be configured by a supplier, populated by the marketing team and used by the operations team, yet no one is clearly responsible when it behaves unexpectedly during the event.

Name an operational owner who understands the intended use, knows how to contact supplier support and can make sensible decisions on site. That person does not have to be an IT specialist. They do need authority, access and enough briefing to distinguish a minor inconvenience from an issue that affects safety, access, programme delivery or delegate confidence.

Suppliers should also be briefed on the event timetable, not just the technical specification. A support call that is answered in fifteen minutes may be perfectly acceptable at 10am on a quiet day and completely unhelpful five minutes before a keynote begins.

AI is useful, but not a substitute for judgement

AI tools now appear in event platforms, content workflows and delegate communications. They can assist with first drafts, session summaries, translation support, data sorting and routine queries. Used carefully, that can save time.

But AI-generated material still needs a person who understands the event to check facts, tone, names, timings and cultural context. A plausible wrong instruction sent to 800 delegates is still wrong, even if it was produced quickly. For event project managers wanting a more structured view of these practical uses and limits, my resource AI for Event Project Managers covers the subject in greater depth.

The sensible test is not whether a tool looks impressive in a demonstration. It is whether it reduces friction for delegates and crew without creating a fragile new dependency. The best technology at a conference is often the part nobody talks about afterwards, because it quietly allowed the event to run as planned.