Some businesses sell time. Others sell admission. Experience businesses commonly sell both sometimes to the same customer in the same month. A studio may sell weekly booked slots, a ticketed workshop, a private group booking with a deposit, and a membership that changes access to all three.
The case for one system is not “fewer apps.” It is one reliable record when a person moves between formats, and fewer manual decisions when something changes.
Booking and ticketing are different inventory models
| Booking question | Ticketing question | Where a mixed business gets stuck |
|---|---|---|
| Which staff member, room, or resource is available at this time? | How many admissions can be sold in each class or tier? | One capacity rule is incorrectly used for a room, a seat, and a staff member |
| Is the slot included in a pack, subscription, or membership? | Is the buyer eligible for a presale, concession, or member price? | Staff apply access rules manually at checkout |
| Is money due now, at the appointment, or as a balance? | What is the ticket price, fee, tax treatment, and refund rule? | Finance cannot explain what a payment refers to |
| Who is expected at this time? | Who may be admitted to this event? | The door team cannot see whether a booking is valid |
| Should the customer rebook? | Should the attendee return to another event? | Marketing sees several anonymous lists instead of a customer relationship |
The difference is not academic. A ceramics studio’s open session may be limited by wheels and staff. Its weekend workshop is sold by seat. Its private event starts as an enquiry and becomes a quote, deposit, balance, guest count, and room plan. A member may have a different rule in each situation.
When an integrated system earns its place
Use one platform when the same people, payments, or operating records repeatedly cross from one format to another. These are strong signs:
- ticket buyers often become members or book later;
- memberships change eligibility, price, booking limits, or cancellation rules;
- staff need one view of attendance, booking state, and payment state;
- private bookings share rooms, people, or capacity with public events;
- finance currently joins several exports to reconcile revenue and refunds;
- the website must present a single, coherent calendar instead of separate purchase paths.
Do not force an all-in-one model just because it sounds elegant. A solo practitioner with appointments only, or a promoter with a single annual show, may be better served by a narrower system with a simple, well-tested handoff to the rest of the business.
Map the customer journey before a demo
Take a real customer, not an ideal one, and trace the journey below. For each step, define who changes the record and what must be visible to the next person.
- Discovery. The customer finds a public page, receives the correct information, and understands the price and policy.
- Purchase or reservation. They select a time, class, ticket, or package and complete checkout.
- Confirmation. They receive a usable confirmation, change or cancellation route, and any access instructions.
- Preparation. Staff see capacity, requirements, customer notes, outstanding payment, and any exception.
- Arrival. The team can confirm the customer’s entitlement without searching multiple products.
- Change. A cancellation, refund, transfer, no-show, late payment, or schedule change is recorded once and communicated correctly.
- Return. The customer receives an appropriate next offer without staff rebuilding their history by hand.
If a vendor only demonstrates the second step, you have not seen the product you are buying.
The seven capabilities worth testing
Flexible inventory
Ask exactly what capacity attaches to: an event, ticket class, date, room, instructor, machine, or all of the above. Then test a mixed case: a workshop shares a room with open booking slots and a staff member is unavailable for one session. A single global capacity number does not survive this operation.
Recurrence with exceptions
Build a series and change one date. Substitute a host, close one resource, adjust capacity, and cancel a date after sales have begun. Ask what the buyer sees and which staff member receives the update. Reusable schedules matter; so does the ability to safely break the pattern.
Entitlements and access rules
Create a member, a pack holder, a regular buyer, and a lapsed member. Test price, booking limit, cancellation, waitlist, and restoration of an entitlement. You are looking for explicit rules and an audit trail, not a proliferation of one-off discount codes.
Private bookings
Model enquiry, quote, deposit, balance, guest count, requirements, and final confirmation. If email stays part of the sales conversation, that is normal. The risk is allowing email to become the only database for financial and operational commitments.
Payment and settlement
Run a purchase, refund, partial refund, failed payment, and cancellation. Review what appears to the buyer, the team, and finance. In Gomry’s public business terms, payout requests are generally processed within one to two business days unless there is a separate written arrangement, while actual receipt can vary with the payment method and banking system. Read the current terms rather than promising a generic payout speed.
Customer records and consent
Find one person who has a ticket, booking, membership, refund, and support request. Confirm that staff see only what they need, exports are usable, and consent is retained appropriately. Customer ownership includes being able to explain why you have a record and how it is used.
Integration boundaries
Integrations should be examined as data flows, not as logo badges. Gomry’s public API documentation describes organisation-scoped API keys and resources including events, attendees, and ticket classes. Review the current API introduction. It does not prove that every booking, membership, accounting, or CRM flow is available: validate endpoints, permissions, events, and failure handling against the workflow you need.
A practical total-cost model
The subscription price is only one cost. Use your own assumptions in a simple scenario:
| Cost category | Question to price |
|---|---|
| Direct charges | What platform, processing, payment-plan, add-on, or custom-domain charges apply? |
| Cash flow | When can money be used, and what happens after refunds, disputes, or reserves? |
| Staff time | How many hours go to re-entry, reconciliation, support, and exception handling each week? |
| Revenue leakage | How often do missed follow-ups, wrong access, no-shows, or broken handoffs lose a sale? |
| Migration | What must be cleaned, imported, retained, or left as a historical archive? |
| Risk | What does one wrong price, overbooking, privacy mistake, or failed event-day process cost? |
For example, if the team currently spends three hours each week reconciling separate booking and ticketing exports, multiply three by its actual loaded hourly cost and annualise it. State that it is an assumption. The arithmetic is useful because it turns “integration pain” into something a small business can compare with product cost.
Where Gomry fits, and the questions to ask
Gomry’s public site describes ticketing, bookings, payments, memberships, distribution, and mobile operations. In practical terms, it is a credible fit when the same customer needs to move between a timed booking and event admission without the team rebuilding identity, access, and payment context in separate tools. That is a more specific proposition than “all-in-one software.”
That should be the beginning of diligence, not the end. Ask Gomry to demonstrate your actual capacity model, payment policy, staff permissions, current country and payment availability, and integration requirements. Do not infer a feature from a headline, a sales category, or an unpublished roadmap.
Frequently asked questions
What is the difference between a booking and a ticket?
A booking generally reserves time, a person, or a resource. A ticket generally grants admission or an allocation to an event. Some experiences need both concepts, even if the customer sees one simple checkout.
Can one platform replace a CRM?
It may cover operational customer history. A business with complex sales, lifecycle marketing, or service workflows may still need a dedicated CRM. Define which system is the source of truth for each record.
Should memberships live with ticketing and bookings?
They should when membership changes access, price, limits, cancellation terms, or reporting. Otherwise staff will keep reconciling entitlements manually.
Do I need a website builder inside the platform?
Not necessarily. You need a reliable, mobile-friendly public journey, clear ownership of pages and analytics, and a checkout that can be tested in the way customers use it.
What is the best implementation test?
Run one real operating week: a member booking, a public ticket, a private deposit, a schedule change, a refund, and a staff handoff. Fix the exceptions before expanding the rollout.