How to make a conference app optional for attendees

You've told attendees that downloading the conference app is optional. Then workshop booking opens inside it, the room changes go out as push notifications, and the moderator asks everyone to submit questions through the app. Someone who took you at your word now has to install it to get through the day.

Making a conference app optional means giving people another reliable way to receive what their ticket includes. They need to find the programme, secure any bookable places, hear about changes and participate without installing the app. Your team also needs a way to keep those routes accurate without maintaining several competing versions of the conference.

You don't have to reproduce every app feature on paper. A personal schedule, a saved exhibitor list or an optional game can remain useful reasons to download it. But when a feature controls access to something you sold, the alternative needs to do the actual job. A printed workshop description doesn't replace a way to book that workshop.

For a paid conference, this is a service decision with a budget attached. You may need staff to handle assisted bookings, someone to update signs, and a programme page that works well in a browser. Those costs deserve a proper place in the event plan. So does the cost of repeatedly helping attendees through a download they never wanted.

Here's how to decide what must work without the app, organise the information and bookings, and test the experience before your attendees discover the gaps.

Start with what the attendee bought

The first thing you want to do is read your ticket page as someone who has never seen the app. What have you promised? Access to presentations, a workshop place, networking introductions, downloadable materials, a hosted buyer meeting? Each promise needs a route that an eligible attendee can actually use.

Write down the tasks behind those promises. "Networking" is too broad to plan. "Request a meeting with a participating exhibitor, see whether they accept and receive a time and location if it is confirmed" tells you what the service must deliver. "Find out where the next session is" is different from "receive a warning that the next session has moved". One involves looking up information. The other requires you to reach someone before they act on old information.

Separate information that anyone can read from information that belongs to a particular attendee. Session descriptions can often be public. A private meeting itinerary, a booking confirmation or a message from another delegate needs an appropriate access check. Making the app optional doesn't mean publishing everyone's personal schedule on an open webpage.

Now decide which app extras can remain extras. An attendee may choose to use a searchable directory instead of asking a host for introductions. They may prefer bookmarking sessions instead of writing their choices down. Different interfaces are fine when the person can still receive the important benefit and understands the conditions.

The harder cases involve paid entitlements. If a premium pass includes an arranged meeting service, "you can always talk to people at lunch" isn't a replacement. If workshop reservations open in advance, sending nonusers to a help desk on the morning of the event gives them a later and potentially worse chance of getting a place.

I would make that distinction before asking the app provider for a feature list. Start with the service you owe attendees, then check which tools and staff can deliver it. Otherwise you can spend a meeting comparing software options while leaving the booking disadvantage untouched.

An app can still be worth promoting. Our guide to getting attendees to use your conference app explains how to give them a useful first task. Here, the decision is what happens for someone who declines that invitation, cannot complete it or changes their mind during the event.

Give the programme a dependable home outside the app

For most conferences, I would start with a readable browser programme and a clearly signposted help point. The programme gives attendees somewhere to check details independently. The help point covers questions, access needs and situations that a webpage cannot resolve. Neither should require an app account just to find out when registration opens.

Keep the address stable as the event approaches. Link to it from the ticket information, arrival email and venue signs. Give people a short written address as well as a QR code. Someone reading an email on their phone should be able to open its link directly. At the venue, the written address also gives staff a destination they can explain, while printed information and help remain available for someone whose phone has run out of battery.

A useful programme entry explains the session title, day, local time, room, intended audience and any entry condition. State whether a session is open to eligible pass holders, requires a separate booking or has an additional charge. Use the same room names on the page, inside the app and on the venue doors.

Be especially clear about personal choices. "Added to my schedule" may mean a bookmark. "Booking confirmed" should mean that a place has actually been allocated under your rules. Don't let a browser calendar export imply a reservation when it only saves a reminder. If the app and the browser use different words, explain the difference before attendees make choices.

You also need an approved programme that your staff update first. Ideally, the app and website can display the same underlying information. Verify that with the provider, including what happens when an update fails. If someone must copy changes between systems, name that person, the check and the expected completion time. A promise that everything stays in sync is only useful when you've tested the actual setup.

Show when programme information was last updated. For printed copies, include an edition time and tell attendees where changes are announced. Treat a printout or downloaded file as a snapshot. It can help someone plan without a connection, but it cannot tell them about a change made after they saved it.

Avoid making an elaborate brochure your only alternative. The W3C's accessible events checklist recommends accessible materials, advance access and asking participants about their requirements. It also warns against relying only on formats people cannot readily adapt. Apply that advice to the programme your attendees will use throughout the day.

Keep essential information easy to read on a small screen and usable with assistive technology. A large image of a timetable may look tidy but make it hard to find a room or enlarge a particular session. Offer the programme as structured text, then provide other useful formats according to your audience's needs. Paper helps some people; it doesn't meet every access requirement.

Open scarce bookings on fair terms

The most serious gap usually appears when something can sell out. You can make a timetable available everywhere and still make the app effectively compulsory if it has the only route to limited workshop places.

Set the booking rules before choosing the alternative. Who is eligible, when do requests open, how are places allocated, and when does a request become confirmed? Decide what happens to waiting lists, cancellations and late arrivals. These rules should apply across the app, browser and staff-assisted routes.

Consider a fictional conference with a workshop that has 40 bookable places. Twenty-eight are already confirmed through the app and eight through staff-assisted requests. That leaves four places, because both routes use the same total of 40. It doesn't leave 12 places in the app plus another allowance for the help desk.

The useful arrangement is one booking system that records every confirmed place, whichever route the attendee used. If your tools support that, have staff enter assisted requests there. Check that the attendee receives a confirmation and that a cancellation releases the correct place. Verify the provider's behaviour rather than assuming that separate screens share availability.

If staff cannot enter bookings into the same system, you need a controlled allocation process. That may mean a single person confirming requests against a maintained record, or a deliberately split allocation with clear rules for releasing unused places. Both take work. Neither is safe to improvise while the remaining places disappear from a second, independently maintained list.

Be honest about timing. A browser booking route that opens alongside the app can provide a comparable opportunity. An email inbox checked later may not. If you offer assisted booking, explain its opening time and how requests are ordered, and make sure staff can process the expected rush. Don't advertise first come, first served unless you can apply that rule coherently across the routes you accept.

A lottery or a request window can sometimes be easier to administer fairly than a race to click first. Attendees submit by the stated deadline, then you allocate under published criteria. That's an option to consider when demand is likely to exceed places and assisted requests cannot be processed instantly. It is a change to the booking model, so explain it before opening requests.

You don't need to reserve a separate block of workshop seats for nonusers automatically. That could leave people waiting while another allocation sits unused. If you do split places, decide who can move unused capacity, when they do it and how they notify the waiting list. The goal is to fulfil the booking promise, rather than make each channel look busy.

Give assisted bookings the same practical detail as app bookings. The attendee needs the session, time, room, confirmation status and cancellation route. Staff at the workshop door need a reliable way to recognise the booking. A handwritten note saying "spoken to reception" is a weak substitute for a confirmed place.

For longer appointments, the same principle extends to both people's availability. Our conference one-to-one meeting guide covers requests, mutual acceptance and scheduling. An optional app route still needs to respect those rules. A host can help arrange a meeting, but should never present an unanswered request as an accepted appointment.

Send important changes through routes people can receive

A programme page answers a question when someone looks at it. An update needs to reach them in time. That's why "the website was correct" doesn't settle a complaint from an attendee who followed the printed programme to the wrong room.

Decide which changes require an active message and which can wait for the next programme check. A corrected speaker biography is different from a session moving across the venue shortly before it starts. Consider the consequence and how soon someone must act, then choose the channels and staff response.

Imagine a workshop scheduled for 14:00 in Cedar moving to Maple at 13:20. The programme lead approves the move and checks that Maple is suitable for the booked audience. The information owner updates the programme and app. A steward places a notice at Cedar, another checks the route, and the help desk receives the new room information.

Affected attendees receive the agreed direct update where you have a suitable contact route. The team also checks the old room, because some people will already be walking towards it. The message names the session, unchanged start time and new room. If the route has access implications, explain the appropriate route and arrange assistance where needed.

That is an operating example, not a universal response timetable. Your building, programme and staffing determine what can happen quickly enough. If you can't complete the communication and movement safely before the start, delaying the session may be the better decision. The app should never be the reason you assume everybody already knows.

Agree who checks that the update reached each staff position. A message in the team chat does not prove the room steward saw it while managing a queue. Give staff a way to acknowledge a change and report a problem. If a sign cannot be replaced or the alternate room is locked, someone needs to know immediately.

Keep safety communications within the venue's emergency plan. Great Britain's HSE guidance on incidents and emergencies covers clear responsibilities, public communication and testing communication equipment. Work with the venue and appropriate specialists on the arrangements for your event. App alerts and email can support communication, but they should not be your only means of giving urgent instructions.

For routine changes, write the procedure into your event communication plan. Include who approves the decision, which audiences need it, where it is published and who checks the old location. This is easier to follow than expecting someone to remember every channel while the programme is already running late.

Make participation possible without a download

An alternative programme solves only part of the day. Follow what the attendee is asked to do inside sessions and during breaks. This is where an optional app can quietly become a requirement again.

Start with questions and polls. If a moderator takes questions through the app, offer another practical route and explain it at the beginning. That might be a roving microphone, a written question passed to a room assistant or an accessible browser form. Choose methods that fit the room, audience and moderation process.

The important part is how submissions reach the moderator. A paper question isn't useful if it stays on a table until the speaker leaves. Assign someone to collect it, and agree how the moderator considers questions across channels. Avoid routinely answering the app queue first and treating everyone else as a spare-minute exception.

Polls need similar thought. If a poll is a teaching aid, a show of hands or another accessible response method may provide the needed participation. If the result determines an award or another consequential decision, you need consistent eligibility and counting rules. Don't merge app votes and raised hands casually and describe the result as a reliable ballot.

Networking needs a clear promise too. A voluntary directory can remain an app convenience when the conference offers other useful ways to meet. Hosts can make introductions, themed tables can organise conversations, and an appointment desk can help with accepted meetings. Pick the approach that supports the event you sold, and fund the staff it needs.

If curated introductions are part of the paid package, plan how nonusers express their interests before the event. Waiting until lunch to ask what they wanted means the relevant people may already be booked. A short pre-event request and an agreed confirmation process can work, provided someone actually manages the requests and respects both parties' choices.

Don't promise identical results from different routes. A host introduction and a searchable directory operate differently. Explain what assistance you offer, when it is available and whether meetings depend on another person's acceptance. Attendees can make an informed choice when the service is described plainly.

Review sponsor commitments at the same time. An app banner is an app banner; a desk introduction is a different activity. If you've sold guaranteed exposure that assumes universal app use, making the app optional changes the assumptions behind the package. Discuss delivery honestly before signing or changing the arrangement. Don't solve the gap by sharing attendee details without an appropriate basis.

Design support around the person who needs it

Some people won't want the app. Others will want it but be unable to use it at a particular moment. You need a useful response in both cases, without turning the help desk into an argument about whether downloading would be easier.

The UK government's introduction to assisted digital support recognises that people can need help because of access, skills, confidence or trust, and describes phone and in-person support. That guidance concerns government services. The useful planning lesson for your conference is to identify what prevents the task and provide appropriate help, rather than assume every problem is solved by another installation instruction.

Ask about functional needs without demanding a justification for declining the app. "Would you like help checking your workshop bookings?" gives staff something to do. "Why don't you have a smartphone?" asks the attendee to defend a personal choice that may have nothing to do with the task.

Make the help point easy to locate and publish its opening hours. Include a contact route for people who need assistance before arriving. A desk that opens after advance bookings have closed cannot be the whole alternative for a pre-event task.

Test the browser route with people who use relevant assistive technology. The W3C's web accessibility design tips cover contrast, navigation, labels and layouts that adapt to different screen sizes. Use those as starting requirements for the supplier and your team, alongside proper accessibility testing. Replacing an app with a difficult website hasn't resolved the access problem.

Don't assume that offering paper removes the need for accessible digital information, or that a good webpage removes every need for staff assistance. An attendee may need a particular format, support navigating the building or a way to receive changes they cannot hear over the public address system. Ask early, agree the arrangement and confirm who delivers it.

Staff should know how to help without taking over someone's private account. Use the organiser's supported booking and access tools. If a problem requires the provider to change an account, follow that process. Requesting a personal password or signing everyone into a shared attendee account creates a different problem while trying to solve the first one.

Put the alternative into the budget

Making the app optional isn't automatically a saving, and it isn't automatically expensive. The answer depends on what you already provide, what the app handles well and how much support your audience needs. Count the work before deciding which arrangement is affordable.

Here is a fictional one-day conference with 300 paying attendees. All amounts are USD assumptions for this example, not supplier quotes or industry benchmarks. The base event budget already includes the app, ordinary registration staffing and other event delivery costs. It does not yet include the extra work needed to support the proposed non-app service.

The organiser prices that additional work as follows. Preparing and checking the browser information takes 10 hours at a fully costed $30 per hour, or $300. Two additional support staff each work eight paid hours at $25 per hour, costing $400 together. Programme printing and replacement signs cost $150. Three hours of update coordination at $30 cost $90, with a further $60 reserved for unexpected support costs. Together, coordination and that contingency allowance add $150.

That adds $1,000 to the budget. At the assumed 300 paid attendees, it is $3.33 per attendee when rounded to the nearest cent. The amount is not a recommended fee to add at checkout. It's a way to understand the support cost within the whole ticketed event.

Suppose the base budget forecasts $8,000 profit before this addition, after all its existing budgeted costs. With revenue and other costs unchanged, the revised budgeted profit is $7,000, assuming the full support allowance is spent, including the $60 contingency. If that reserve is unused and everything else matches the budget, the result would be $7,060. Those figures are before financing costs and business income tax. The added support costs include assumed employment costs and unrecoverable transaction taxes; a real budget must use its actual treatment.

You can now compare alternatives honestly. Perhaps a provider offers a suitable browser programme and assisted booking tools within the app contract, reducing setup work. Perhaps your team already staffs an information desk with spare capacity. Confirm that capacity at peak periods before counting it as free. Staff who are fully occupied checking tickets cannot also handle a workshop booking rush without affecting something.

If the organiser expects each additional ticket sold to leave $80 after its associated variable costs, recovering the added $1,000 would require 13 additional ticket sales. Twelve would contribute $960 and leave $40 uncovered; 13 would contribute $1,040. That only helps if there is capacity and real demand. Nothing in this example predicts that making the app optional will generate those sales.

You may decide the support is necessary to deliver the ticket promise, regardless of whether it can be linked to extra sales. In that case, include it before setting the ticket price or committing to costs. Don't build a budget that works only if attendees accept a service condition you have advertised as optional.

Review the assumed hours as well as the money. The two support staff must cover arrival, programme changes and breaks through a workable rota. The example does not establish that two people are sufficient for your event. Test the tasks and expected demand, then adjust the number of staff, their hours and the budget together.

If the app remains part of the plan, its contract cost remains too. Removing a requirement to download it does not create a software saving. Only subtract a cost when the revised supplier agreement actually removes it. This matters when a proposal looks attractive because it counts both the app's benefits and a cancellation saving that hasn't happened.

Decide what happens when booking tools go offline

A printed list can tell staff who was confirmed when it was produced. It cannot tell them what another team has booked since. That distinction matters if the connection fails while attendees are still reserving workshops through the app.

Agree with the provider how to pause or restrict booking during an outage. Staff should not start confirming extra places from a snapshot while another route keeps selling or allocating the same remaining places. If you cannot establish current availability, explain that the request is pending and give the attendee a realistic next update. Don't issue a confirmation just to end an uncomfortable conversation.

A controlled offline arrangement may be possible when one authorised person takes responsibility for all remaining allocations and the other routes are paused. It needs a current starting record, a way to record each change and a check before normal booking resumes. Confirm that your tools support the arrangement. An emergency spreadsheet created by whichever teammate has a laptop is unlikely to establish those conditions on its own.

When access returns, reconcile pending requests, cancellations and any authorised offline confirmations before reopening ordinary bookings. Tell affected attendees the result through the agreed contact route. Staff at the workshop door need the reconciled record too, including any change to an earlier confirmation.

This also gives you a useful test of the budget. If the fallback depends on a coordinator who is already running the stage, change the rota or simplify the booking offer. A procedure is only usable when the people named in it are available to carry it out.

Give staff a procedure they can follow during a busy day

A support promise needs more detail than "ask reception". Decide what the desk can resolve, what needs approval and who covers it when the main contact is away. People asking for help should not have to explain the same problem to several teams.

For programme questions, staff should use the approved current programme. For a confirmed reservation, they should use the booking record. For a meeting request, they should check its actual status. Those may be separate systems, but the staff briefing should say which one answers which question.

Give the help team enough permission to complete authorised tasks, without giving everyone unrestricted access to attendee data. A person answering room questions doesn't need to read private networking messages. A booking assistant may need to see eligibility and availability but shouldn't alter the overall workshop capacity without approval.

Write a short task guide in the language staff will hear. "I can't find my workshop confirmation." "My colleague bought my ticket." "I don't use the app and want to ask the speaker a question." Each entry should explain what staff check, what they can do and where they send the issue if it remains unresolved.

Include how to finish the interaction. After making an assisted booking, confirm the result to the attendee and check that it appears where the room team will look. After giving directions to a changed room, verify that the new location is the approved one. A helpful conversation can still leave the underlying task incomplete.

Also agree who handles a failure to deliver a paid benefit. If a confirmed workshop place disappears, the desk should check the record and contact someone authorised to resolve it. Don't dismiss the problem because the attendee chose the non-app route, or invent a replacement benefit without checking whether it meets the commitment. Record what was promised and what happened, then apply the event terms and the requirements relevant to the purchase. Staff need a prompt escalation route even when they cannot decide the remedy themselves.

Plan the handover between shifts. Staff coming on duty need current changes, outstanding requests and any temporary workaround. Keep this information in an authorised staff location, with only the personal details needed to finish the work. Leaving an open notebook of attendee problems on a public desk is avoidable.

The programme owner also needs cover. If one person holds all the editing permissions and spends the afternoon introducing speakers, updates will stall. Nominate a trained deputy and test their access before the event. The person approving a programme decision and the person publishing it can be different, as long as the responsibility is clear.

A short booking entry can help the next staff member finish the job. Use fields such as these, adapted to your actual tools:

• Attendee reference and the eligibility check completed.

• Requested session and the time the request arrived under your allocation rules.

• Current status, such as pending, confirmed or waiting list.

• Confirmation reference and where the attendee received it.

• Any unresolved action, the responsible colleague and the next promised update.

Keep this inside the controlled booking process. The purpose is to record what happened, not create another list that competes with the system allocating places. If your existing tool already records these details, use it instead of copying them into a second document.

Keep installation help available for people who want it. Just don't make it the only answer. A staff member should be able to say, "I can show you the app, or I can help you book here," when both are supported routes. That makes the choice practical instead of making the attendee negotiate for it.

Keep private information out of the public alternative

An app often combines a public programme with private accounts and messages. When you create alternatives, separate those functions deliberately. Publishing the programme on the web does not justify publishing the delegate directory, access requirements or individual booking details beside it.

For events subject to UK data protection rules, the ICO's data minimisation guidance says personal data should be sufficient, relevant and limited to what is necessary for the purpose. The page currently notes that its guidance is under review following legislative changes. Have the responsible person check the requirements that apply to your event and the specific information each support route needs.

For a workshop booking, staff may need an attendee identifier, eligibility and the requested session. They don't automatically need an explanation of why the attendee avoids the app. For a networking introduction, they need enough information to make the request appropriately, plus a way for the other participant to accept or decline.

Explain what will happen to that information. Someone asking a host for an introduction should understand whether the host will send their name and stated interests to the proposed contact. Keep direct contact sharing within the agreed process. A private introduction request should not quietly become a new marketing list.

Printed records require the same care in practice. Keep booking lists under staff control, avoid placing private itineraries where a queue can read them, and collect materials when their operational use ends. Agree retention and disposal with the person responsible for event data rather than inventing a deadline at the desk.

You should also check what happens after a ticket transfer. The incoming attendee needs the correct access and bookings under your rules, while the previous attendee should not retain access to someone else's information. Follow the ticketing and app providers' supported processes and verify the result across the tools you actually use.

Making the app optional should reduce the work an attendee must do to receive the service. It shouldn't force them to explain a disability, surrender a personal contact list or accept unrelated marketing just to find their workshop.

Rehearse the day without installing the app

The best check is to ask someone unfamiliar with the setup to attend through the alternative route. Give them the real ticket information and messages, then ask them to complete the tasks an attendee will face. Let them try before a team member explains what you meant.

Start before arrival. Can they find the programme, understand booking conditions and request a scarce place at the advertised opening time? Do they know whether the request succeeded? Can they change it through a supported route? If a colleague bought the ticket, can the actual attendee receive the necessary information?

Then walk the venue. Ask the tester to find registration, identify their next room and locate assistance without scanning a code. Check the written address on signs, the room names and the help-desk position. Do this in the areas attendees will use, with the venue's permission and suitable arrangements.

Try a room change during the rehearsal. Update the approved programme, notify the relevant staff and replace the old-room notice. Ask the tester where they would go next and how they learned about the move. Record where the information failed instead of assuming the tester should have checked more often.

Test a booking conflict as well. Have the app and assisted route attempt to allocate the last place using test data in the provider's supported environment. You need to see that only one confirmation is issued. If testing reveals two independent lists, fix the allocation process before taking real requests.

Include a question during a presentation and a networking request. A route that looks complete in the operations plan may fail because nobody collects the written questions or the host doesn't know how to confirm an introduction. These are delivery problems, even when every website link works.

Test relevant accessibility needs with participants and appropriate expertise. Don't ask a colleague to pretend to be a screen-reader user and call that accessibility testing. Use their unfamiliarity to find general confusion, then involve people who can assess the access requirements your service must meet.

Finally, turn off the assumed connection. Which tasks still work, which can wait and which need a staffed response? A browser alternative still needs internet access unless it has tested offline capability. An app may have its own offline limits. Check both and prepare the event's proportionate contingency rather than promising that either route always works.

Tell attendees how the choice works

Once the routes are tested, write the invitation around the attendee's choices. Explain the useful reason to use the app, then state where the programme, bookings and help are available without it. Keep the alternative visible in the same communications people use to prepare.

A suitable message might explain that the app offers a personal agenda and optional networking directory, while the browser programme is available at the linked address. It should separately explain how workshop reservations work, when they open and where to request assistance. Use your actual arrangements; don't copy a generic promise that your team cannot fulfil.

If you're using Loopyah, our attendee email tools can send event updates to ticket holders. Use those messages to explain the programme address, arrival details and the support route you've arranged. The programme, scarce-place allocation and assisted bookings still need their own confirmed tools and owners. An email send is also not evidence that an attendee read a last-minute change.

Keep late buyers and replacement attendees in the plan. They need the current instructions, rather than an old app invitation forwarded by someone else. Before each pre-event send, check the live programme address, booking dates and support contact. Remove instructions that no longer apply.

Continue the choice after the conference when you've promised resources. Provide an appropriate route to authorised slides or recordings without a fresh app installation requirement. Confirm the access period and any authentication needed for paid materials. Respect speaker permissions and explain delays instead of leaving empty links.

Ask nonusers about the actual tasks when reviewing the event. Could they reserve the workshop they wanted? Did they hear about changes? Could they participate and find their materials? Pair those answers with support demand and staff hours. A low download figure may coexist with a well delivered conference; a high figure can coexist with people missing what they paid for.

Before your next ticket launch, have the programme and operations leads complete the non-app route together. If they cannot book a place, receive a change and take part under the terms you plan to advertise, resolve that gap or describe the requirement honestly before selling. Give the team time to correct the booking process and rehearse it again before you publish those instructions.