Hello,
We are a consortium with 3 resident companies. We (TPAC) sell tickets to their events and each resident company sells their own tickets as well. We do not share bank accounts for transactions (which I am sure is the norm), so control groups are necessary to make sure orders are paid for using the right payment methods...cross pollination is bad!
Our resident companies have shows offsite at their own venues, but those tickets can be sold by us or them. Providing customer service night of show is becoming quite problematic because they are unable to access orders they haven't processed. Mostly the issue is in printing tickets. Other than the batch ticket printing option, I was hoping that for those of you in similar situations, have you come up with anything to make it easier for your partners?
Thanks in advance for any assistance, we want to help our family and keep hitting a brick wall.
Best,
Kimberly Darlington - SVP, Ticketing & Customer Service, TPAC
Hello!
The previous organization I worked with was part of a consortium. To get around the printing/order access issue, we created a shared mode of sale that gives user access to all performances at all venues. The trouble comes into play when training all staff across all venues to process orders in that mode of sale. As long as the order was processed in that mode of sale, all users could access and print the order. Additionally, each org had their own payment methods (*Org 1* Visa, *Org 2* Visa, etc.)
Same! Carol Keeney is helping us clean up some of this now. It’s a little tricky and there isn’t a perfect solution!
Here's our full approach:
Data Element
Shared Approach
Season and related performances
For the seasons that are to be sold by more than one organization, the season will be assigned to the shared control group. Once the season is over, it can be moved to the “owner” control group.
Modes of Sale (MOS)
The “owning” group will maintain the modes of sale. The MOS’ will be added to the security groups that need them. (e.g., CBO Manager, CBO Box Office). My assumption is that the “selling” group will largely use their own MOS’, but need access to others for ticket reprints, and potentially returns/exchanges. (MOS’ are not technically control-grouped.)
Price Types
The “owning” group will maintain all the data related to prices (types, rules, etc.). The Price Types will be added to the security groups that need them. (e.g., CBO Manager, CBO Box Office). (Price types are not technically control-grouped.)
Hold Codes/Allocation Codes
The “owning” group will maintain the Hold Codes. The Hold Codes will be added to the security groups that need them. (e.g., CBO Manager, CBO Box Office). I assume the only reason they need access is to “break” the holds. (Hold Codes and Allocation Codes are not control-grouped.)
Batch Types
Each control group will have it’s own batch types; it is assumed they do not need to be shared. (A reason for sharing would be if the “owning” group needs to close/post batches from the “selling” group.)
Payment Methods
The “owning” group will maintain all the Payment Methods in their own control group. The Payment Methods will be added to the security groups that need them. (e.g., CBO Manager, CBO Box Office).
Appeal/Source Codes
Similar to Seasons, if the “owning” group wants to share usage of appeals/source codes (a/k/a promotions), the appeal will be assigned to the shared control group.
Venue/Facility
If a venue/facility is to be shared, it will not be control-grouped.
Activities
If the owning group wants the selling group to use activities (either Customer Service-related Activities that show on the Connections tab a/k/a/ TR_CUST_ACTIVITY_TYPE or Activities that show on the History tab a/k/a TR_SPECIAL_ACTIVITY), they will be managed like Seasons – assigned to the “shared” control group for as long as the selling organization needs access to them.