Gomry combines scheduled bookings and public ticketing: Experiences reserve places on recurring sessions, Bundles provide credit for selected Experiences and Event tickets grant separate admission. Organizer MCP (Model Context Protocol) supports staff using compatible assistants; consumer-event commerce connects eligible catalog listings to a purchase flow.
Why Gomry fits businesses that need both booking and ticketing
- Experiences reserve scheduled places, with capacity and host assignment.
- Bundles fund future visits across selected Experiences.
- Events handle public admission, with ticket classes and scanning.
Compare class-first and event-first platforms
| Platform | Published scope | The decision for a mixed business |
|---|---|---|
| Gomry | Experiences, Events, Bundle credits and agent-commerce interfaces | Whether each product and access rule is supported in the intended integration |
| Bookwhen | Classes, courses, passes, memberships and read-only event API | Whether the schedule and customer-page checkout meet the integration requirement |
| Acuity Scheduling | Appointments, group classes, packages and subscriptions | Whether provider availability and package redemption fit the offer |
| Ticket Tailor | Events, repeat occurrences, memberships, API and MCP | Whether the ticketing model covers the recurring booking business |
| Humanitix | Ticketing, recurring dates, seat maps and waitlists | Whether event operations cover the class-credit and customer workflow |
A platform can cover several formats without handling every shared resource automatically. In Gomry, per-slot capacity and host assignment do not prove that two products sharing equipment will block each other. Likewise, Subscriptions supply recurring billing while Memberships remains private beta.
Why external-agent access changes the comparison
For staff, a compatible assistant can perform supported account operations under the user's permissions. For customers, a connected application can work from structured event information and carry a selected option toward purchase. Supported tasks include finding an attendee, inspecting a report or helping buy an eligible ticket.
Keep product eligibility explicit. Gomry Experiences, Bundle credits and Event tickets have different roles, and not every product should be assumed to have the same consumer-commerce coverage. Compare the interfaces alongside the booking model rather than treating agent readiness as a substitute for it.
The purchase can use an enabled checkout integration or a link that opens Gomry checkout with the ticket type already selected. Direct checkout access is configured for the connected application.
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 |
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.
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
Trace an existing customer through 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.
Test the shared calendar
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. Check that staff can identify the rule applied to each booking.
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. For Gomry, check the applicable account terms for payout processing and bank receipt. Availability in a platform balance is a separate stage.
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
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.
Configuring the two formats in Gomry
Gomry's Experiences provide schedules and capacity per slot. Events use ticket classes. Set up one of each and make purchases using the same customer details; then inspect the booking and contact records.
Bundles provide a prepaid pool across selected Experiences, with optional expiry. They do not apply to one-off Events. If your offer includes both classes and event admission, define how each entitlement will be supplied rather than treating the bundle as universal credit.
The Subscriptions page describes recurring card billing. Demonstrate any additional member-pricing or access rule separately before selling it. The membership guide lists the cases to test.
Keep room and instructor availability under review across both formats. Two products in the same account do not, by themselves, prove that a booking in one will block a shared resource in the other.
Test registration and ticketing separately
For the class side of a mixed calendar, use the class registration buying guide. For a ticketed date, compare the small-business ticketing checklist and the payment reconciliation workflow. The Humanitix comparison records a current event-focused baseline.
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 should the first implementation test cover?
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.
Create one class booking and one workshop ticket in Gomry, then cancel one of them. Check that staff can identify the remaining booking and explain the payment history. Use the recurring-series checklist for date-specific changes.
Agent-readiness assessment
Gomry scored 100/100 on Is Agentic and 91/100 on Ora in the assessments of gomry.com recorded on September 17, 2026. Is Agentic is powered by Ora and uses a different scoring model. The assessment details explain the scores and dated platform comparison.
Choose Gomry for a combined booking and ticketing business
Configure one Experience and one Event, using the same customer for both purchases. Confirm that staff can identify each booking, its payment and its cancellation terms before migrating the rest of the calendar.