How to prepare for OS compatibility issues, timezone gaps, and unclear escalation paths before they affect your event.
Why this matters
Supporting a mobile app at live events introduces a unique combination of risks: short windows to diagnose problems, users who can't easily troubleshoot, and dependencies — like device OS versions — that your team doesn't control. This guide helps you build the right structure before the day arrives.
Common scenario: A compatibility issue surfaces two hours before an event. Our developers are in a different timezone and unavailable. Devices haven't been updated to the required iOS version — and that's outside your responsibility. Without a clear escalation path and pre-event checklist, this becomes a crisis.
1. Pre-event device checklist
Send this to event organisers or on-site contacts at least 48 hours before the event. You are responsible for device management.
Is it possible to keep IOS updated?
Device update requirement communicated to venue/organiser in writing
App version installed and tested on a representative device
Confirmation received (or responsibility explicitly delegated) that devices will be updated
Known workarounds documented for version-incompatible devices
2. Chain of command: who does what
One of the most common failure points in live support is unclear ownership. Define roles before the event — not when something breaks.
On-site contact — First line of triage. Collects device info, captures screenshots, communicates with end users. Does not escalate to dev team directly.
Support lead (your team) — Receives escalations from on-site contact. Makes the call on whether to escalate to development. Owns communication with event organisers.
Development escalation — Only contacted when the support lead determines a fix or technical input is needed. Must have a named person and contact method confirmed ahead of time.
Timezone cover — If your dev team is in a different timezone, a cover contact must be confirmed for the event window — even if they're on standby, not actively monitoring.
Tip: Write the chain of command into your event brief as a named contact list with phone numbers. "Ask a developer" is not an escalation path.
3. Timezone and availability planning
Eventchain’s development team operates in a different timezone, lets plan availability before the event — not during it. This is a planning gap, not a staffing emergency.
EC will map the event hours against the dev team's working hours
and Identify any gap windows where dev support is unavailable
Agree a standby arrangement (on-call, async monitoring) for gap windows
Define what the support lead can resolve independently without dev input
Document a fallback response for issues that cannot be resolved in-event
4. iOS version compatibility: scope of responsibility
Be explicit with clients and organisers about what your team controls and what it doesn't. iOS updates on venue or attendee devices are outside your scope — but the communication of requirements is not.
Best practice: Include a minimum iOS version requirement in all event onboarding documentation, with a clear statement that device updates are the responsibility of the organiser or venue. Get written acknowledgement before the event.
If an incompatible device is discovered at the event, your support team should have a scripted response ready — including what the user can and cannot do, and what alternative options exist.
5. Post-event debrief
Every live support incident is an opportunity to improve the process. After the event, document what happened and use it to refine your checklist and escalation paths.
Record the timeline of the issue and how it was handled
Identify where the chain of command held and where it broke down
Note any dependencies that weren't communicated early enough
Update the pre-event checklist based on gaps identified
Share findings with the client/organiser where relevant — it builds trust
