An event CRM should help your team answer questions about a customer's purchases, attendance and communications. That requires more than an email address: the record needs to distinguish who paid, who is attending and which transaction changed.
If a customer buys three workshop tickets, attends one session and asks for a refund on another, staff need to find the relevant purchase without rebuilding the history during a support call. Purchase, attendance and refund records answer different parts of that question; none can stand in for the other two.
Start with the entities, not the dashboard
| Record | Why it exists | Common mistake |
|---|---|---|
| Contact | Identifies a person and how they can be contacted | Assuming matching names always identify the same person |
| Buyer | Owns the commercial transaction | Assuming the buyer always attends |
| Attendee | Is admitted to or participates in an experience | Sending buyer-only financial messages to every attendee |
| Consent | Records communication choices and source | Treating a purchase as unlimited marketing permission |
| Order and payment | Explains what was purchased, paid, changed, or refunded | Overwriting history when a ticket is moved |
| Attendance | Shows what actually happened | Treating ticket sale as proof of attendance |
| Membership or entitlement | Explains current access | Confusing past purchase history with active rights |
This model matters when one person buys for a group, a customer changes their name, a guest attends under a buyer’s order, or someone withdraws consent. If a vendor cannot explain these distinctions, segmentation and automation will be unreliable later.
The minimum useful customer record
For most recurring experience businesses, staff need only the fields required to deliver the experience and respect the relationship:
- stable identity and practical contact details;
- the source and state of marketing or service consent;
- order, payment, refund, and transfer history;
- attendee or attendance history where relevant;
- current memberships, packs, credits, or booking rights;
- limited operational form information that the team genuinely needs;
- a record of important customer-service decisions.
Define field ownership and retention before importing anything. “We might use it one day” is not a good reason to collect or preserve sensitive information.
Where customer records need more than an email address
One person can have two contact records
A customer using a work address for one purchase and a personal address for another can have two contact records. Gomry deduplicates by email within the organization: creating a record again with the same email reuses the profile. Matching names alone do not establish that two different email addresses belong to the same person.
The practical consequence is that staff cannot assume the record under one address contains everything the customer bought. A merge must not erase a legitimate history or turn an opt-out into an opt-in.
A group purchase has one buyer and several attendees
When one customer buys three tickets, the payment belongs to the buyer's order while each place has its own attendee record. A name change affects the person attending; a refund affects the associated payment; a check-in records attendance. Keeping these actions distinct prevents a change to one guest from being mistaken for a change to the whole purchase.
The buyer and attendees can also need different communications. A payment question belongs with the purchaser, while arrival information needs to reach the people attending. Their contact details and consent should not be treated as interchangeable.
Communication choices can change after a purchase
A customer can remain part of the purchase history while opting out of marketing. Removing them from a promotional audience should not erase the order staff need to support. The system should distinguish service communications from marketing according to your organization's policy and applicable law. Get specialist advice for your jurisdiction when configuring those rules.
A saved list is not an automatic audience rule
An audience such as “attended twice in the last 90 days but has no active membership” depends on attendance dates and current access, not just an email address. A list feature does not by itself establish that those conditions can be combined in one filter. If the available filters cannot apply them together, staff need to review the audience before sending a message.
CRM is not just email automation
Email is one output. The harder value is operational context. A front-desk teammate may need to see valid access and an accessibility note, while finance needs payment state and a marketer needs consent and source. Give each role only the information and actions it needs.
This reduces both service mistakes and privacy risk. It also prevents the frequent problem where a team sends an irrelevant “come back” offer to someone whose most recent experience was canceled or refunded.
Exports are a procurement requirement
An operational export needs usable identifiers connecting contacts, orders, attendees, consent, attendance, membership state, payments and refunds. Without those relationships, finance may see a refunded purchase while the admission team sees an apparently valid attendee record. Corrections and deletions also need to remain distinguishable from missing data.
An email-list export may be enough to move a newsletter. Moving customer operations also requires the identifiers connecting purchases, attendees and payments.
Integration: name the source of truth
Many businesses need a dedicated sales CRM, email platform, accounting system or data warehouse alongside ticketing. Each record needs a clear owner: otherwise a corrected email address or opt-out in one system can be overwritten by an older value from another. A typical division of responsibility looks like this:
| Data | Source of truth | What can update it? |
|---|---|---|
| Customer contact and consent | Named system | Defined customer or staff actions only |
| Event and ticket status | Ticketing system | Current event operations |
| Attendance | Check-in system or event platform | Documented admission process |
| Accounting records | Accounting system | Approved finance workflow |
| Marketing audience | CRM or email platform | Consent-aware sync from the source |
Gomry's API provides organization-scoped records, including events, attendees and payments. Its webhook subscriptions deliver checkout registrations and submitted or updated form responses. Gomry's Zapier instant triggers use the same subscription mechanism. These deliveries carry HMAC-SHA256 signatures and allow 10 seconds for a successful response. Timeouts, network errors, HTTP 429 and server errors can trigger up to three additional attempts; other client errors are not retried. Registration notifications arrive per ticket, including registrations awaiting approval, but exclude manually added guests and RSVP responses.
Existing organization webhook URLs use a separate legacy route for successful one-time payments, subscription creation or deletion, and form-response changes. That route remains unsigned, has a five-second timeout and makes no delivery retries. A payment or subscription event on this route should not be assumed to exist in the API/Zapier subscription event list.
An integration still needs reconciliation and duplicate protection. For subscriptions, verify signatures and use the stable event ID to recognize repeated delivery. For legacy notifications, confirm sensitive payment details against the API and recover missed changes. Neither route supplies a complete customer history by itself. The API and webhook guide explains the delivery conditions and receiving workflow.
Customer records in Gomry
Gomry’s Contacts deduplicates by email within the organization. The timeline includes registrations, waitlist activity, requests and refusals, declined payments, form submissions and communications. Email metrics in the CRM are distinct from ticket-transfer notifications, which do not show open or click badges. Keep the buyer's payment record separate from each participant's registration when one person buys for a group.
For invitations, select contacts using their purchase and attendance records, then add them to a saved list. You manage list membership manually rather than relying on automatic rules for dates, unused credits or membership status.
The MCP catalog documents contact and list tools under the user's permissions. An external CRM connection needs the supported trigger or API operation mapped to the destination’s fields. A custom webhook receiver also needs an HTTPS endpoint. Gomry's Zapier instant triggers cover new attendees and new or updated form responses; they do not expose every operation available through MCP or the API. The API and webhook guide explains those integration boundaries.
Keep a sales CRM where you need account pipelines and forecasts. Decide which system owns contact updates before connecting it to event operations.
Frequently asked questions
Is an email list a CRM?
No. An email list stores contactable addresses. A CRM adds relationship and operational context such as identity, consent, purchases, attendance, service history, and current access.
Should buyer and attendee be separate records?
Yes when one purchaser can buy for other people. Their permissions, communication needs, and event-day identities can differ.
What should be exportable?
Identity and identifiers, consent, source, orders, payment and refund state, attendees, attendance, active entitlements, and only the form data legitimately needed for continuity of service.
Can ticketing software replace a sales CRM?
It can cover operational customer history. A complex sales organization may still need a dedicated CRM. Decide which system owns each record and how changes are synchronized.
What is the biggest CRM risk for an organizer?
Using data you cannot explain: duplicate identities, unclear consent, over-collected form answers, and segments built from unreliable event records.
Use Contacts to find a customer’s registrations and communications. Open the associated payment record for a refund, and save the contacts you select for the next invitation in a list.