# Customers and customer lists (/en/businesses/customers-and-customer-lists)
Every booking, payment, membership, and credit a customer touches on Thril rolls up into a single customer record, and those records together are your venue's CRM. This is where you understand who your customers are, segment them into lists, and feed those lists straight into [emails](/businesses/emails) and [announcements](/businesses/announcements). Customer data is stored in Thril, so a customer's lifetime value, last visit, and consent status are current. Dynamic list membership is refreshed separately and follows the schedule described below.
This page covers what you can see and do with customers, how to build lists that target the right people, and how to bring existing customer data in from elsewhere.
***
## The customers view [#the-customers-view]
**Customers** in the sidebar shows your customer base with a rich set of columns: name, email, phone, **credits balance**, **lifetime value**, **reservations**, **events attended**, whether they **hold a membership**, whether they have an **active recurring reservation**, language, customer since, customer number, and tags. Several of these are shortcuts: click a customer's credits, reservations, events, or memberships figure to jump straight to that tab in their profile.
By default the view spans your whole company. If a venue is active it pre-filters to that venue, but you can clear the filter to see every customer across all venues. Two filters shape the table:
* **Venue**, to narrow to a single location.
* **Customer list**, to show the members from the list's most recently successful sync. Dynamic lists are refreshed separately from the customer record.
Search matches names as you type and finds an exact email address. A phone number matches from its first digits, in any format: "040 123", "040-123" and "+358 40 123" all find +358 40 1234567.
### Tags [#tags]
Tags are applied automatically from a customer's activity, so they always reflect reality:
* **New customer** for someone with one reservation or none yet.
* **Banned** while a ban is active on the customer. See [Banning a customer](#banning-a-customer).
* **Netvisor customer** when the customer is linked in your Netvisor accounting integration (shown on the customer's profile).
***
## A customer's profile [#a-customers-profile]
Opening a customer reveals their full history across tabs: **Details**, **Reservations**, **Events**, **Credits**, **Memberships**, **Session cards**, **Payments**, **Invoices**, **Receipts**, and **Discount groups**. A few are worth calling out.
### Credits [#credits]
The **Details** tab shows the total **available credits**. When some of those credits carry an expiry date, an itemised list breaks them down by amount and expiry, so you can spot batches running out soon. The **Credits** tab holds the full transaction history and lets you add or subtract credits manually. See [Credits](/businesses/shop/credit-products) for how credits and expiry work. Credits you add here pay for the same things as credits the customer buys, and you can't limit them to one kind of product. See [Limiting what credits pay for](/businesses/shop/credit-products#limiting-what-credits-pay-for).
### Payments [#payments]
The **Payments** tab is the customer's complete payment history across reservations, events, shop products, and more. Each row shows the items, total including tax, payment method, creation time, and status. Filter by creation date, succeeded date, or status to find a specific transaction. For each payment you can:
* **Complete payment** when it is in a *requires-action* state, choosing how it was settled: cash, card, sports benefit, or invoice. Choose **Payment waived** to mark it uncollected without recording a method.
* **Refund** a succeeded payment that has not already been fully refunded.
* **Copy payment ID** for support or reconciliation.
A customer with a payment stuck in *requires-action* cannot make new
reservations or attend activities until it is resolved. Use **Complete
payment** to settle it and unblock them.
### Receipts [#receipts]
The **Receipts** tab lists receipts for the customer's succeeded payments. Each receipt can be downloaded as a PDF by clicking the download button on that row. The receipt includes the payment details, items, and amounts, and is suitable for forwarding to the customer or for bookkeeping purposes.
***
## Emails to your customers [#emails-to-your-customers]
### Which language they arrive in [#which-language-they-arrive-in]
Emails Thril sends to a customer, such as booking confirmations, receipts and reminders, are written in the language of the customer's own Thril account. The **Language** column in the customers view shows it. Your venue has no setting that changes it.
An account gets its language when the customer signs up, and the customer can change it later from **Language** in the app's settings. If a customer wants their emails in English, ask them to switch the language there.
### Apple's "Hide My Email" addresses [#apples-hide-my-email-addresses]
A customer who signed in with Apple and chose **Hide My Email** has a relay address from Apple, ending in `@privaterelay.appleid.com` or, for addresses created from late 2026, `@private.icloud.com`. Apple forwards mail to that address only from senders registered for Thril. Apple forwards Thril's emails, including your [emails](/businesses/emails), to the customer's real inbox for as long as the customer keeps forwarding on. A message you send from your own mailbox to the relay address does not arrive.
To reach the customer from your own mailbox, ask for their real address, or ask them to switch their account to it. [Changing your email address](/consumers/change-email) has the steps.
***
## Chatting with customers [#chatting-with-customers]
Customers can message your venue through Thril chat in the Thril app. On your venue page they tap the chat icon at the top. If your venue also has group chats they can join, they then pick **Customer support**. Each customer has one chat with your venue, so a new message continues the earlier conversation.
Staff read and answer these chats under **Chats**, in the sidebar or the chat icon at the top of the dashboard. The chat belongs to the venue rather than to one person, so anyone on your staff who can open **Chats** sees it and can reply. To start a chat yourself, open the customer and click **Chat**.
### Who can post [#who-can-post]
**Settings → Chat** shows how chat works at your venue. **Customer messages** has one of three values:
* **Everyone can post**: customers can start a chat and write to you.
* **Only staff can post**: customers can't start a new chat or write. Your staff can still start one, and the customer can read it and react.
* **Off**: nobody can post or react. Chats that already have messages stay readable.
The same page shows the setting for event, course, tournament, league and service booking chats. The settings are read-only on the page. Contact Thril to change them.
***
## Banning a customer [#banning-a-customer]
A ban stops a customer from booking or taking part at your venues. It covers your whole company, not just the venue you are in, and it always has an end date.
Open the customer and choose **Ban customer** from the **Actions** menu. If they are already banned, the same item reads **Edit ban**.
### Scopes [#scopes]
Pick at least one scope. Each one has its own end date, so you can ban a customer from reservations for a month and from participation for a year.
* **Ban from reservations** stops the customer from making new court and resource reservations, and from booking services.
* **Ban from participation** stops the customer from joining [events](/businesses/events), [leagues](/businesses/leagues), and [tournaments](/businesses/tournaments).
Set **Ends** with the date picker, or use the **1 month**, **1 year**, or **100 years** shortcut. The date must be in the future. The ban lifts itself when that date passes.
### Reason and notification [#reason-and-notification]
**Reason** is internal only. The customer never sees it.
Tick **Send ban notification to customer** to tell them. They get a notification in the Thril app and an email that names the scopes they are banned from and the date each one ends. The message is sent under your chain name, or under the names of your active venues if you have no chain name. The reason is not included.
Leave the box unticked to apply the ban silently.
### Seeing and lifting a ban [#seeing-and-lifting-a-ban]
While a ban is active the customer carries the **Banned** tag, and the **Details** tab of their profile shows a **Reservations** and a **Participation** row with **Banned until** the end date.
To lift a ban before its end date, open **Edit ban**, clear the scopes you want to release, and click **Save changes**. Clearing both scopes removes the ban entirely.
***
## Adding a customer [#adding-a-customer]
You can create a customer manually with just a first name, last name, and email; a phone number is optional. The record is created for your active venue.
What happens next depends on the email:
* If the email already belongs to a Thril account, the customer is **linked** to that existing account rather than creating a duplicate.
* If not, a new Thril account is created for them.
Creating a customer who already exists at your venue is a safe no-op: Thril will not produce a duplicate. When you edit a customer later, note that core details like name and phone are part of their Thril account and so changes apply platform-wide. The **advanced options** when editing let you set a baseline lifetime value, reservation count, and event count, which is how you carry over history from a previous system so your statistics stay meaningful.
***
## Customer lists: segmenting your base [#customer-lists-segmenting-your-base]
Lists are how you turn a large customer base into targeted audiences. A list can be used as a quick filter on the customers table, exported as a CSV, and selected as the recipients of an email or announcement. The list view shows each list's name, type, venues, size, creation date, and when it last synced.
There are two kinds, and the difference matters:
* **Dynamic.** Defined by filters. Thril refreshes the membership immediately after you create or edit the list, then automatically every 24 hours. Changes to customer data can therefore take up to 24 hours to affect membership.
* **Static.** A fixed snapshot of customers captured at the moment you create it. It does not change afterwards, which is exactly what you want when you need a stable group, for example the attendees of one specific event.
When you create a list you give it a **name** and optional **description**, choose the **type**, and optionally restrict it to **specific venues** (leave this empty to include customers from every venue). A live preview shows who currently matches as you build. The first list membership is calculated before the list is created, so a new dynamic list is ready to use immediately.
You can use **Update now** from a dynamic list's details to request a fresh
membership outside the automatic 24-hour refresh. While a refresh is pending,
the list is marked **Sync pending** and a campaign using it may not include
every matching customer.
### What you can filter on [#what-you-can-filter-on]
Dynamic lists draw on the full picture Thril holds about a customer. The available filter fields are grouped:
* **Activity:** number of payments, number of reservations, number of events attended, last reservation date, last event attended, reservation sport types, whether they hold an active recurring reservation, and what they have taken part in: events, event series, courses, and event sport types.
* **Customership:** name, language, gender, age, customer since, customer imported at, venue credit balance, lifetime value, memberships held, and session cards held.
* **Marketing:** email marketing consent, and whether push notifications are on in the Thril mobile app.
* **Other:** whether they have the Thril mobile app.
Each field offers operators suited to its type:
* **Counts and amounts** (reservations, events attended, payments, lifetime value, venue credits, age) use *greater than*, *greater than or equal to*, *less than*, *less than or equal to*, *equal to*, and *not equal to*.
* **Dates** (customer since, customer imported at) use the same comparisons against a specific date.
* **Last reservation date** and **Last event attended** use relative operators: *more than X days ago*, *less than X days ago*, *before*, *after*, and *between* two dates. This is what powers "lapsed customer" and "recently active" segments. Last event attended looks at the latest past event or class the customer took part in, course classes included. A customer who has never taken part in one matches none of the options.
* **Lists of things** (sport types, events, event series, courses, memberships, session cards) use *is one of*.
* **Name** uses *contains*.
* **Yes/no fields** (marketing consent, push notifications, has the app, has a recurring reservation) and **language/gender** match an exact value.
Reservation count, events attended, and payment count can be narrowed to a
date range, so you can target, for example, customers who made more than five
reservations *this season* rather than over their whole history.
A list limited to specific venues looks at what the customer did at those
venues: their reservations, payments, lifetime value, recurring reservations,
events, courses and session cards there. A list that covers every venue looks at
the whole company. The baselines from a customer's advanced options have no
venue and always count in full. Memberships held and the **Events** filter look
at every venue.
**No. of events attended** counts the customer's confirmed places in events,
course classes included, at the venues the list covers. A queue place does not
count, and neither does an event that was cancelled or deleted. The customer's
baseline event count is added on top, so a venue that moved over from another
system can still reach, for example, everyone with more than 100 classes. With
a date range, only events held in Thril within that range count, because the
baseline has no dates.
#### Participation filters [#participation-filters]
Four fields cover what a customer has taken part in, so you can reach a whole
audience without picking one class at a time:
* **Events.** A specific event you choose from a list.
* **Event series.** Every occurrence of a recurring event, so a weekly class
reaches everyone who has ever been to it.
* **Courses.** Enrolment on a course, at any time. A customer who took the
beginners' course two years ago still matches, and a course that has ended or
been cancelled still counts.
* **Event sport types.** Everyone who has taken part in an event of a given
sport, including course classes.
All four mean a **confirmed signup**, not attendance. Somebody who signed up and
never showed up is on the list, because the attendance mark is a separate record.
Cancelled events and cancelled signups are always left out. A course waiting-list
place is not an enrolment, so a queued customer does not match the course filter.
**Reservation sport types** and **Event sport types** are two different
fields. The first looks at the sports your customer has made a reservation
for. The second looks at the sports they have signed up to an event for.
### Combining filters [#combining-filters]
Filters combine with clear logic. Within a group, every condition must be true (AND). Separate groups are alternatives, where matching any group is enough (OR). So you might build:
* **Group 1:** marketing consent is accepted AND last reservation more than 90 days ago, to win back lapsed but contactable customers.
* **OR Group 2:** lifetime value greater than 500, to keep your best customers in the audience regardless of recency.
### Example lists worth building [#example-lists-worth-building]
* **Active and contactable:** marketing consent accepted, at least one reservation. Your default marketing audience.
* **Lapsed players:** last reservation more than 90 days ago. Pair with a win-back offer.
* **High value:** lifetime value above a threshold you choose. For VIP perks and previews.
* **Single-sport fans:** sport types is one of padel. For sport-specific campaigns.
* **App adopters / non-adopters:** has the Thril mobile app, true or false. To nudge the rest to install it.
The participants of any list can be reviewed (name, email, phone, and date added) and **exported as a CSV** for use elsewhere.
### A list of your company customers [#a-list-of-your-company-customers]
Company customers have no Thril account, so the filters above never match them. To email them in bulk, build a list that holds every company customer:
1. Go to **Marketing → Lists → Create list**, name the list and select **Next**.
2. Select **Add filter** and pick **Company customers** under Customership. It replaces the other filters, and the preview lists your company customers with their count.
3. Select **Save list**.
The list covers all venues and is always up to date: a company customer you add later is on it straight away. Its **Participants** tab lists the company customers, and **Export as CSV** downloads them with their business IDs.
Pick the list as the recipients of a marketing or transactional email. Each company gets the email at its **Email** and at its contact person's email, or once if the two are the same. A company with neither address stays on the list but gets no email.
A company customer gets marketing email until it unsubscribes through the link in the email, or until you untick **Receives marketing email** on the company customer. Unsubscribing stops both addresses. The company customer's details show **Marketing email: Receives** or **Does not receive**. A transactional email still reaches every company customer with an address.
Promo codes, announcements, empty slot alerts, workflows and the statistics filters do not offer these lists, because they work on individual customers.
***
## Importing existing customers [#importing-existing-customers]
You can bring an existing customer base into Thril with **Import CSV** from the customers view. Pick the source that matches where your data comes from, and Thril parses the file accordingly:
| Source | Notes |
| ----------------- | --------------------------------------------------------------------------- |
| **Thril** | The default, richest format. A downloadable example file shows the columns. |
| **Sweetspot** | Upload a customer export from Sweetspot. |
| **DigitalBooker** | Upload a customer export from DigitalBooker. |
| **Playtomic** | Use a Playtomic CSV export. |
| **Cintoia** | Use a Cintoia CSV export. |
| **MATCHi** | MATCHi exports are XLS; convert to CSV first. |
The Thril format goes well beyond names and emails. Alongside first name, last name, and email (the only required columns), it accepts phone number, gender, date of birth, language, email marketing consent, customer-since date, credits and a credit expiry date, internal notes, a membership name and expiry, country, and baseline lifetime value, reservation count, and event count. Files can be up to 10 MB, and Thril detects the encoding and delimiter automatically.
### Preview before you commit [#preview-before-you-commit]
After uploading, a preview shows the parsed rows so you can check them before confirming. It surfaces a few helpful columns:
* **Detected memberships:** membership names from the file matched (by exact name) to your existing Thril memberships, including company-global ones.
* **Original membership names:** the raw text from the file, so you can spot a name that did not match.
* **Credits with expiry:** the expiry date shown beneath the credit amount when the file includes one.
Rows that fail validation are listed separately with the reason and are skipped, so a few bad rows never block a good import.
Duplicate emails update the existing customer rather than creating a second
record, so re-importing an updated file is safe. Imported credits are recorded
as non-taxable gift credits, and any credit expiry date is set to the end of
that day in your venue's time zone.