KORE Ticketing collects data from your vendor’s system, then deduplicates and processes that data for use in your CRM. Ticketing integrates with both AXS and Flash Seats; it’s possible to use just one of those ticketing systems, but most teams use both together. AXS and Flash Seats store data independently of each other, so Ticketing’s deduplication processing provides the ability to see a customer’s activity from both systems in one place.
AXS / Flash Seats allow KORE Ticketing to read ticketing data directly from their replicated databases (Amazon Redshift). We regularly read the latest updates, then process and deduplicate your data. Ticketing then pushes the updates to your CRM where you can use the additional tools we provide.
You can use the Ticketing Data Manager (TDM) to make changes to AXS data. TDM always retrieves the latest data using the AXS API, and it writes any changes you make back to AXS using the same API. Flash Seats does not provide an API, so TDM can’t support it.
Main article: Initial load
The first time KORE reads your data from AXS / Flash Seats, we copy your existing data from the replicated databases into the SQL Server database that Ticketing uses, then run our deduplication processing. This step takes quite a while—typically days or weeks, depending on how much data there is. At the beginning of this process, we note the exact time and date. We download all the records from that time or earlier.
You can keep using AXS / Flash Seats just like normal throughout this process. Since we know the cutoff date and time for the initial load, we’ll copy all the changes you make during this period when we run the first incremental update.
Main article: Incremental updates
Every hour, we connect to the AXS / Flash Seats replicated databases and request all the records that have changed since our last request. We copy those updates into our SQL Server database and check for duplicate records to combine.
The most recent changes in AXS aren’t viewable through your CMS immediately. AXS / Flash Seats don’t write updates to their replicated databases immediately, and Ticketing can’t read the updates until that happens. In the worst case, a changed record would be copied into the replicated database immediately after Ticketing started an incremental update. Ticketing won’t be able to push that change to the CRM until the next incremental update.
Main article: Deduplication and the mapping table
We perform deduplication of AXS / Flash Seats accounts during each incremental update. Without deduplication, a sales rep looking at ticketing data wouldn’t know if a given customer has two other records. Deduplication helps you avoid pitching a sales opportunity to someone who already bought tickets using a different account, for example, preventing poor relations and wasted time.
Every AXS / Flash Seats account has a unique ID number. For each account ID we receive during an incremental update, we first check our mapping table to see if we’ve previously evaluated it. If the account ID is in this table, it’s already mapped to a CRM contact and we can apply the updates to it.
If the account ID isn’t already in the mapping table, then we run our full deduplication logic. We compare this ticketing account to every other ticketing account in the mapping table, searching for information that matches. If we don’t find a match, then we create a new CRM contact, add the ticketing account ID to our table, and mark it as the primary ticketing account for this CRM contact. But if we do find a match, we mark this account ID as a secondary ticketing account for the CRM contact it matched.
Our deduplication logic works for both people and company names. We also use “fuzzy matching” to help match up information that isn’t written in exactly the same way, such as First St. and 1st Street.
If the ticketing account also has a company name associated with it, we use deduplication logic to check if there’s an existing CRM account or if a new one needs to be created. CRM accounts represent companies and let us display all your contact people at that company together in one place.
We provide new abilities to your CRM and make it possible to gain new insights into your customer base. CRMs like Salesforce or MS Dynamics lack concepts that are critically important to the sports market. We create those concepts for the CRM and give you the ability to track different groups of customers like season ticket holders and single-ticket buyers who attend multiple games each season.
All of this can be found in the Ticketing Module within your CRM. Additionally, we provide valuable tools like Fan Finder, Purchases Grid, Attendance Grid, Ticketing Data Manager (TDM), Ticket Groups, and more.
Ticketing Data Manager
Note: Since Flash Seats doesn't have an API, TDM cannot write data to it. If a CRM contact has both AXS and Flash Seats accounts, we recommend opening TDM and setting the AXS account as the primary ticketing account (if it isn't already). Otherwise, you will need to make updates using the Flash Seats interface and wait for them to sync with KORE Ticketing.
The Ticketing Data Manager (TDM) can be opened from a CRM contact’s page. This tool allows you to edit details about a CRM contact and ensure the changes are kept in sync across all the systems involved: AXS, KORE’s SQL Server database, and your CRM.
We strongly recommend that you always use TDM to edit contacts. If a CRM contact is edited directly without using TDM, AXS will still have the older version. Even worse, the next incremental update that includes that AXS account will overwrite the CRM's newer information. Most CRM managers therefore lock down (make read-only) the fields which are mapped to an AXS account, forcing changes to be made through TDM instead.
 An API (application programming interface) is a common way for one system to make automated requests for another system’s information over the internet.