Event Without Mobile Internet in 2026: Connectivity Plan

An operating plan without mobile internet: backup registration, command center communications, local materials, a switchover scenario and a pre-launch check.

An event without mobile internet can run without stopping entry or losing control. To make that happen, we separate critical processes from the external network in advance. We store the guest list locally, connect registration desks using a proven scheme, move the command center to radio communication, and pass programme changes along a short protocol.

The main mistake is not the lack of signal. What is more dangerous is dependence on a single channel, which the team only notices when the doors open. If invitations are available only in email, the participant list exists only in a cloud service, coordinators communicate only via messenger, and speakers receive updates through the mobile network, then a single restriction affects the entire project at once.

At Aventura, we treat the internet as a working resource with known limitations. During preparation we determine which operations must continue autonomously, who makes the switchover decision, and how the team returns to normal mode. This approach is needed for conferences, forums, client days, corporate events and projects in areas with challenging coverage.

If you are preparing an event at a venue with unstable connectivity, request a technical assessment of the project. We will check registration, command center channels, guest communications and backup scenarios before the day of the event.

What should keep working without a mobile network?

Guest check-in, team management, programme updates, urgent announcements and incident logging must continue without a mobile network. Other functions can be temporarily slowed down, postponed or switched off. We start preparation with a list of processes and the acceptable downtime. Right next to it we record the solution owner and the action the team will take once that time has elapsed.

We divide functions into three groups.

1. Critical functions cannot be stopped. These usually include guest verification, issuing access passes, communication between the command centre and security and the venue, calling the person in charge, queue management, announcing a hall change and relaying an emergency message.
2. Important functions can operate in a simplified form. For example, you can temporarily give up printing personalised badges, online polling, instant statistics export or emailing materials.
3. Additional functions can be postponed. Posts, photo uploads, report synchronisation and some marketing activities should not compete for the team's attention during an outage.

For each critical function we define the primary method, the backup and the waiting limit. If the coordinator has not received confirmation via the primary channel, they do not keep refreshing the screen endlessly. They move to a pre-assigned action.

It is useful to check dependencies along the chain. An e-ticket depends not only on the guest's phone. Verifying it may require internet at the desk, access to an external database, scanner power, staff authorisation and a working printer. The backup must cover the entire chain.

At business events we separately flag the processes the schedule depends on: registration, speaker readiness, transitions between halls, presentation of materials and communication between the moderator and the command centre. For a conference we link this map to the programme and the running of the sessions. This approach is also useful when preparing a conference, forum or seminar on your own.

Resilience is built on several levels

A working scheme combines an independent channel, local infrastructure and manual procedures. An additional SIM card is only useful where another network is available and there is no shared restriction. If the problem affects mobile data transmission in the area or at the venue, multiple phones do not create independent resilience.

We use four levels of resilience:

This table does not mean that every event needs a full set of equipment. The scale of resilience should match the risk and the venue layout. In one hall, a local list and a few radios are enough. At a forum with multiple sessions, separate communication groups, a backup registration point and a formal change log will be needed.

Wired internet can be the primary or backup channel if the venue confirms its scheme and the organiser's access. We clarify where the connection point is, who manages the equipment, which area depends on the building systems and what will happen in a power outage. Having a socket in the wall does not yet prove the channel is ready.

Before signing a contract, it is useful to conduct a technical audit of the venue. During the inspection, we check communication in the registration area, command centre, halls, technical rooms and team routes. A separate test is needed in areas with thick walls, on underground floors, in remote pavilions and in open areas.

How to prepare offline guest check-in?

Offline check-in relies on a local list, a clear identification rule and a separate change log. Staff must be able to find a participant, confirm their status and mark entry without contacting an external server. Once connectivity is restored, the data can be reconciled and synchronised.

First, we trim the data set down to what is needed. For entry, a surname, first name, company or access category and an internal identifier are often enough. There is no need to give every desk the participant's full profile. Article 5 of Federal Law No. 152-FZ stipulates that the scope of personal data processed must match the stated purposes and must not be excessive.

We prepare the offline list step by step.

1. We set the point at which the version is frozen. After that, new registrations and changes go into a separate log.
2. We export the data into a format that opens on work devices without the internet and without additional authorisation.
3. We remove fields that the front-desk staff do not need.
4. We check sorting, surname spelling variants, company search and handling of people with the same surname.
5. We split access categories into clear statuses, colours or codes that do not require decoding via a cloud system.
6. We secure the devices and files and restrict access to the designated staff.
7. We create a backup copy for the check-in supervisor and define how it is issued.
8. We run a test check-in for several guests, including a participant without a QR code and a person whose data has changed.

If several desks are handling entry, local lists may diverge. The same person can be marked on two devices, and a new status will not appear at the neighbouring desk. That is why you need a synchronisation scheme within the venue or a manual split of the flow. For example, desks work by surname ranges, companies, ticket types or pre-assigned entrances.

A local network within the venue can connect workstations without internet access. But it also has to be set up, secured and tested against the real configuration. We check the server or main computer, switches, access points, power, device addresses and what happens if one node fails. If the team cannot restore such a network, the manual scheme must remain available.

A QR code is useful if it contains an internal identifier that the local system can verify without contacting the outside world. A solution where the scanner opens a web page after every code cannot be considered offline. Before the event, we enable offline mode and run the entire path from scanning to badge printing.

We covered the detailed logic of statuses, queues and exception desks in the article on event participant check-in. When mobile internet is limited, a manual resolution desk is especially important. It handles guests who are not in the main copy, participants with a substitute representative, speakers with an updated status and people without an accessible invitation.

How does the entrance area work in offline mode?

The transition must be the same for all check-in desks. The registration supervisor announces the mode, records the time and tells the team which list becomes the working one. Staff stop retrying to log into the cloud system and follow a single instruction. A separate desk handles non-standard cases so that the main flow keeps moving.

We use the following procedure:

1. An employee reports a sign of failure to the supervisor: data won't open, search isn't responding or authorization is unavailable.
2. The supervisor checks the problem on a backup device and contacts the command center.
3. The command center decides whether to continue a short wait or switch to offline mode.
4. All desks receive the same command and switchover time.
5. Registration staff open the local version and start marking check-ins according to the agreed rule.
6. Non-standard cases go to a separate desk so as not to hold up the main flow.
7. New decisions are recorded in the log: time, participant, action, person responsible.
8. After the network is restored, the supervisor schedules a reconciliation, but does not switch desks on their own during a peak check-in.

For the guest, the procedure should remain calm. There is no need to explain technical details to every person. A short phrase is enough: "We'll now check your registration against the backup list." If confirmation takes time, the employee directs the guest to a clear waiting area and states the next step.

We manage the queue separately from the database. One coordinator watches how the entrance area fills up, opens additional positions and passes an assessment of the situation to the command center. If search has become slower, you can temporarily simplify issuance: use pre-made badges, skip printing some data or separate verification from collecting materials.

The printed list remains the last reserve, but it must be handled carefully. It contains personal data, quickly becomes outdated and is poorly suited to simultaneous work by several desks. We number the copies, issue them to designated employees, do not leave them on an open table and collect them after check-in is complete. The procedure for storage and destruction is determined by the personal data operator, taking into account their own policy and legal requirements.

Command centre and radio replace the work messenger

When mobile internet is unavailable, control shifts to the command centre, the radio network and short face-to-face briefings. Every message must have a recipient, an acknowledgement and a clear outcome. A radio will not replace all the functions of a chat, but it will let you send urgent commands without an external network.

We build the network around roles. Typically, dedicated communications are needed by the command centre, registration, stage and programme, technical, security, venue, logistics and guest services. A small event allows several roles to be combined. At a multi-hall forum the common channel quickly becomes overloaded, so groups are split, and department heads communicate with the command centre.

We determine in advance:

• channels and a backup channel;
• call signs without long names and job titles;
• the list of people who have radios;
• the issue and return point;
• charging, batteries and the person responsible for spares;
• data that must not be transmitted over the open air;
• the priority procedure for an urgent message;
• the time of regular briefings;
• the way to communicate with staff who have no radio;
• actions in case of a lost device or interference.

The conversation must be short. First we call the recipient, wait for acknowledgement, then pass on the fact and the required action. The recipient repeats the key part of the command if an error could affect the guest flow or the programme. Long discussions are moved to the command centre or a separate channel.

We do not transmit full personal data, medical details, commercial information or other sensitive information over the open air. For identification we use a stand number, an internal situation code or a request to switch to a private conversation. Radio discipline is needed not only for order, but also to limit unnecessary data dissemination.

The NIST continuity guidance recommends determining priorities, backup channels, alternative equipment and manual ways of performing critical processes in advance. The Ministry of Emergency Situations advises keeping important contacts outside cloud services, conserving device charge and having backup power. We adapt these principles for the venue: the command centre must have local instructions, a paper contact card, radio communications and designated face-to-face briefing points.

The full scheme of roles, call signs, channels and the decision log is in the material on the event command centre and radio communications. If the project requires equipment, we select sound equipment and communications after inspecting the venue and taking the number of staff into account.

We publish reviews of how the command centre, the venue and the technical team work in the Aventura Telegram channel. The channel is useful during the preparation stage, but on site the work instructions must still be accessible without a mobile network.

Guests need offline routes and a single message

A guest should not have to rely on a mobile site to find the entrance, hall, cloakroom, help desk or a section that has moved. We duplicate the main route with physical signage and staff at decision points. The more complex the venue, the more important prominent signs and a single language for announcements become.

Before the event, it is useful to send the participant at least the details they can save in advance: address, entry time, name of the entrance group, hall number or name, organiser's contact and admission rules. The wording "all information will be in the app" creates unnecessary dependency. We ask guests to save their ticket or code on their device, but we keep the option of finding a person on a local list.

At the venue we use several methods:

1. Printed signs at the entrance and at turning points.
2. Screens with locally loaded slides that do not pull content from an external network.
3. An information desk with a current printed programme.
4. Coordinators at lifts, stairs, passages between buildings and section entrances.
5. Announcements by the host or venue using pre-agreed wording.
6. An accessible format of information for guests who have difficulty reading small signage or hearing announcements.

Programme changes are issued by a single owner. They approve a short message, and the control centre distributes it across channels: screen, host, coordinators, information desk. If every staff member retells the decision in their own words, guests end up with different versions.

The message must answer four questions: what has changed, who it affects, where to go and when the new arrangement starts. The reason can be stated briefly if the guest needs it to make a decision. Technical details must not obscure the action.

For example: "The sales section will start at 12:20 in hall 3. Participants should follow the blue signage to the second floor. A coordinator is waiting by the stairs." This message is more useful than a notice about a temporary service outage.

Presentations, streaming and materials also need a local copy

The programme can stall even with a fully functioning stage if the presentation only lives in the cloud, the video opens via a link, the font loads from the network, and a remote speaker connects without a backup scenario. That is why we collect all materials needed for the on-site part locally and test them on the equipment that will actually run in the venue.

For each talk we prepare a working package:

• the final presentation file;
• an export in an additional format in case the original programme fails to open;
• local video and audio files;
• the fonts used, or a version with embedded elements;
• the name and contact of the speaker's representative;
• duration and running order;
• a note on what to do if the remote connection is unavailable.

We store the files on the main show computer and on a separate backup drive. Another copy is held by the technical director or in the control room. File names should show the venue, time, speaker and version. A folder called "final new 2" does not help anyone work out which material has been approved.

If the event includes an online audience, we decide in advance what matters most when the channel is constrained: keeping the stream, the recording or the on-site programme. Sometimes it makes sense to continue the talk for the room and record it locally, postponing publication. In another project the remote participants are the main audience, so a confirmed wired channel, technical backup and a different venue scenario will be required.

When preparing an online event or stream, we separate the production internet, the guest network and internal communications. We do not treat guest Wi-Fi as a broadcast backup. Any additional channel is tested at the right point, on the right device and under the load that can be safely reproduced before the event.

We agree the remote connection backup with the speaker. This could be a pre-recorded talk, handing the key points to the moderator, moving the slot or switching the format to an on-site discussion. The decision must take into account the rights to the materials and the audience's expectations. It is not worth promising viewers a seamless continuation if the plan has not been rehearsed.

When and how do you switch the entire project?

The switch is announced by a single manager based on predefined triggers. Without this, different areas start acting at their own discretion: registration opens a local list, the tech team keeps waiting for the network, and coordinators try to restore the chat. A breakdown in management is more dangerous than the outage itself.

We include three types of triggers in the plan:

1. Technical trigger. A critical system does not respond on two tested devices, or a verified channel is unavailable.
2. Operational trigger. The delay already affects the queue, the program, safety or decision handover.
3. Time-based trigger. Recovery is not confirmed by the point at which waiting causes more damage than the backup mode.

The exact intervals are set by the team of each specific project. For guest check-in, the acceptable wait is usually shorter than for photo publishing. For calling a safety officer, there may be no wait at all. You should not set a single universal timer for all functions.

The switch card fits on one page and answers the questions:

• who makes the decision;
• which triggers they check;
• whom they notify first;
• which process is activated at registration;
• which channel the command center switches to;
• who updates the guests;
• where new decisions are recorded;
• what remains disabled after partial recovery;
• who authorizes the return to normal mode.

The return also requires a command. A brief appearance of a signal does not mean that all services are stable and the data has had time to sync. First the technical team checks the channel, then the process owners assess the state of the records. After that, the command center chooses a convenient moment. During a busy check-in, it is sometimes safer to finish registration in offline mode and reconcile later.

We record all deviations in a log. The entry includes the time, the fact, the decision made, the person responsible and the result. Such a log helps avoid disputes about the sequence of events and conduct a debrief after the project.

We described the general procedure for assigning owners, response levels and recovery in the event crisis plan. The communication and offline registration plan becomes a separate appendix to it.

A rehearsal without network reveals real gaps

A backup is considered ready only after testing in an artificially created offline mode. The team disconnects the external network on test devices and runs through the key scenario. If an employee knows that the internet is currently available on a nearby phone, the test quickly turns into a demonstration of the primary system.

We conduct the rehearsal following the sequence of the guest day.

1. We open local instructions and contacts.
2. We register a test participant by QR code and by last name.
3. We process a person who is not in the primary version.
4. We pass a message about the queue to the command center.
5. We change the hall of one block and deliver the new text to the coordinators.
6. We launch a local presentation and video.
7. We check communication with a remote zone or second hall.
8. We simulate the loss of one radio and the failure of the main registration computer.
9. We record decisions in the log.
10. We restore the network and reconcile data without duplicates or losses.

During the test, we measure more than just the technical result. We look at whether employees understand the command, know the location of files, can find the person in charge, do not transmit unnecessary data over the radio, and do not create a queue through their actions.

NIST considers planning, recovery priorities, backup channels, alternative equipment, and manual methods as parts of information process resilience. EMERCOM recommendations add a practical layer for communication: important contacts should be stored separately from cloud services, device charge should be conserved, and backup power should be prepared in advance. We test these principles during the rehearsal together with people, devices, and the actual guest route.

Based on the results of the rehearsal, we compile a list of issues. Each has an owner and a deadline. The wording "check the internet" is too broad. A working entry looks like this: "At desk 4, the local database does not open without re-authorization. Responsible: registration manager. Before the technical rehearsal, prepare an offline profile and repeat the test."

One day before the event, we repeat a short check after the final setup. The position of desks, screens, partitions, equipment, and people change the actual coverage picture. Radio communication that worked in an empty hall must be checked from the assembled command center, registration area, stage, service corridor, and remote points.

What to check before opening the doors

Before the start, we check that people and devices are ready to execute the backup scenario. Department heads confirm the status of their units to the command center. Each unit must have a working primary method, a tested backup, and an employee authorized to declare the switch. If even one link is not ready, the team closes the gap before guest entry begins.

Registration

• the local list matches the locked version;
• new participants and changes are recorded in a separate log;
• search works without an external network;
• the QR code is verified offline or there is a search by guest data;
• the exceptions desk is assigned and marked;
• backup badges, lists and consumables are in place;
• staff know the phrase to use with guests and the escalation procedure;
• access to personal data is restricted.

Communication and command center

• radios are issued according to the list;
• channels, call signs and the backup channel are confirmed;
• batteries are charged, and spares are held by the responsible person;
• a landline or another independent way to reach the venue has been tested, if one is provided;
• the decision log is open;
• employees without radios know the reporting points;
• the text of the urgent announcement is available locally.

Program and equipment

• presentations, videos and music are loaded locally;
• a backup computer or drive can open the files;
• remote activations have an agreed backup scenario;
• navigation screens work without external content;
• the technical team knows the priorities when the channel is limited;
• communication between the stage and the command center has been tested.

Guest route

• the address, entrance and time were sent to participants in advance;
• signs are in place at every decision point;
• coordinators know the current schedule;
• the information desk has received a paper or local version of the program;
• changes are issued by a single owner;
• announcements are clear without access to the app or website.

Switching and recovery

• the shift supervisor has the authority to declare autonomous mode;
• the triggers for switching are recorded;
• all departments know whom to confirm the switch with;
• the data reconciliation procedure is defined;
• partial network recovery does not trigger an unauthorized return;
• a debrief and log collection are scheduled after the event.

Digital tools need a local fallback, and the team needs a clear manual procedure. We protect entry, communication and the program first, then test the entire scenario without an external network.

If you need a registration and communication plan for a specific venue, submit a request via the form. At Aventura, we will analyse the project's dependencies, prepare backup processes and run a test together with the team before the doors open.

Sources

• Ministry of Digital Development of Russia: how services operate under mobile internet restrictions
• EMERCOM of Russia: communications, key contacts and food supplies during disruptions
• EMERCOM of Russia: purpose and rules for using the 112 system
• Federal Law No. 152-FZ “On Personal Data”
• NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems
• NIST SP 800-153: Guidelines for Securing Wireless Local Area Networks
• MDN: Using Service Workers for offline-first interfaces
• MDN: Using IndexedDB for local persistent data
• MDN: Background Synchronization API
• DENSO WAVE: QR Code scanning and local processing
• GS1: Digital Link Quick Start Guide
• OWASP: HTML5 Security Cheat Sheet