An organiser mobile app should help people do physical work: admit guests, see what is happening, resolve a defined exception, and hand off information without walking back to a laptop. It should not merely compress an administrator dashboard into a phone screen.
Choose the app by testing it while moving, with the devices, network, staff roles, and event conditions you will actually have.
The mobile jobs that matter
| Job | A useful mobile outcome | Test it with |
|---|---|---|
| Check-in | Fast, clear admission decision and exception path | Valid, duplicate, transferred, cancelled, and guest-list entries |
| Capacity | Staff understands remaining places and what the number means | Multiple entrances, holds, walk-ins, and a late capacity change |
| Sales visibility | A supervisor sees current order information without giving broad financial power | Different role permissions and a delayed or failed payment |
| Refund or change | Authorised people can follow policy with an audit trail | Partial refund, cancellation, and wrong-customer scenario |
| Urgent communication | The right person can identify and publish the right update | Venue/time change and staff acknowledgement |
| Incident response | The team can work through loss of network, battery, or device | Planned fallback and a named escalation owner |
An app that does one job extremely well can be right for a simple operation. A broader app earns its place only when it removes real event-day handoffs.
Run the venue test
Create an internal test event and send two staff members to the actual entrance. Use their own roles and devices. Scan a valid ticket, then a duplicate, refund, transfer, guest entry, and walk-in. Change capacity. Turn connectivity off only if the vendor says your configured workflow works offline, then reconnect and inspect the state.
Also test practical details: screen brightness outside, camera scan speed, battery life, accessibility settings, login recovery, and the readability of the exception message. These are not cosmetic issues when a queue is forming.
Separate visibility from authority
Not every staff member should have the same powers. Many people can benefit from seeing a headcount; far fewer should change inventory, issue a refund, view payment data, or send a customer message.
Define individual accounts and role-based permissions before training. Then ask: who can scan; who can override a scan; who can sell a walk-in; who can refund; who can change an event; who reviews the audit record? Shared credentials make support and accountability much harder when something goes wrong.
Offline claims require a demonstration
“Offline mode” can mean a local attendee list, local validation, queued updates, or a later sync. It does not necessarily mean that two disconnected entrances can prevent every duplicate at the same time. Ask what data is stored locally, how long it remains valid, how devices sync, what conflict handling exists, and what the team should do when an action cannot be confirmed.
Your door plan should have a manual fallback regardless: a supervised list lookup, a clear exception lane, and a named person allowed to make the final decision. Technology reduces pressure; it does not remove the need for an event policy.
Alerts should create a decision, not more noise
Useful alerts are tied to an owner and an action: capacity is nearly full, a key guest has arrived, payment needs attention, or an operational request is waiting. Decide who sees each alert, when it is safe to ignore, and how the team records the resolution.
Avoid treating an alert stream as management. If staff cannot tell what matters in the next two minutes, notifications make the event harder to run.
Payments and customer service on a phone
A refund or sales action on mobile is consequential. Test identity, event/date, amount, policy, confirmation, permissions, audit record, and customer communication. Gomry’s public business terms are the relevant source for its payment and payout arrangements; they should be checked for the current account and market before a team makes a cash-flow promise. Read the current terms.
The mobile app should make a permitted action faster without enabling improvised financial decisions under queue pressure.
Where Gomry fits
Gomry’s homepage publicly describes an iOS and Android mobile offering for ticket scanning, guest refunds, event publication, sales/capacity/headcount visibility, alerts, and offline QR check-in with multi-scanner sync. See the current product page. The relevant distinction is that this mobile work is presented as part of the ticketing, booking, payments, and membership operation, not a disconnected scanner. Those are Gomry’s own product claims and should be tested in the specific account, device, connectivity, and staff-permission setup you intend to use.
For a business that only needs a basic static guest list, a smaller scanning tool may be sufficient. Gomry is most relevant when mobile work belongs to the same ticketing, bookings, payments, memberships, and operations system.
Frequently asked questions
Does every staff member need an account?
Use individual, role-based access where possible. It supports security, auditability, and sensible restriction of consequential actions.
Can refunds safely happen on mobile?
Yes when identity, amount, policy, confirmation, permissions, audit trail, and customer communication are clear. The right answer is not “always allow it” but “allow the right people to perform the defined action.”
What should work offline?
Only what the vendor documents and demonstrates for your setup. At minimum, agree a clear admission fallback and a way to reconcile any later conflict.
What should an organiser test first?
The worst five minutes: two entrances, a duplicate ticket, a customer with a changed booking, poor connectivity, and a supervisor who needs to resolve an exception quickly.
What is the main implementation risk?
Giving a moving team power without clear roles, an exception policy, and an event-day reconciliation process.