Before setting up your system it is important to understand the building blocks of the system to decide how best to use them to fulfil your organisation’s box office requirements.
Sales Channels
Every ticket is sold through one of the three built in Sales Channels. These are:
- Phone –for sales made to a customer over the phone
- Counter – for sales made to a customer over the counter
- Web – for sales made by a customer through your website
Phone and Counter are considered Manned Sales Channels as they require a sales operator to perform them. Web is considered an Unmanned Sales Channel as the customer performs the transaction themselves.
You can also simulate a 'web' sale in the sales interface where necessary.
Events
An Event should be thought of as a unique production or exhibition or concert etc. which will play over a certain period of time. A different production of the same piece of work should be created as a new Event.
Example: A production of Macbeth playing this year should be set up as a different Event to a completely different production of Macbeth which may have played last year.
Event Instances
An Event Instance is a single occurrence of an Event on a particular day and at a particular time and with a particular Price List, Seating Plan and Ticket Commission. This allows each Event Instance to potentially have different attributes.
Example: A production of Macbeth playing every night for a week, from Tuesday to Saturday, would be set up as a single Event with five Event Instances. Each Event Instance could have a different Price List so the weekend prices could be different.
Event Attributes
Event Attributes are a completely customisable way for you to store additional information about your Events. An attribute for an Event consists of a Name/Value pair. Event Attributes can be used for a number of purposes including searching and reporting. They can also be used on your ticket designs.
Example: You create an Event Attribute named “Performing Company”. By including this Event Attribute on the ticket design you will print out the name of the performing company that you have set for the Event that the ticket is for.
Price Bands
Price Bands are used to group seats by their cost within an auditorium. Once defined they can be included in Price Lists. Each Price Band has an associated colour which is used in Seating Plans to indicate the Price Band of the seat. For an Unreserved Seating Area, a single Price Band is used for all seats in the area.
Example: You have an auditorium with a single seating area but with three prices of seats. You would set up three Price Bands for these three price levels.
If setting up an Unreserved Seating Area you will need to select a single Price Band for it. You may find it helpful to set up a Price Band called “Unreserved” for this use.
Ticket Types
Together with the Price Band, the Ticket Type defines the price that the customer will pay for the ticket. The system comes with the “Adult” type set up by default though this can be renamed if necessary.
Apart from “Adult”, other common ticket types that you are likely to want include “Student”, “Over 60”, and "Complimentary". When setting up a “Complimentary” Ticket Type, ensure it's not available to customer’s booking online by selecting the appropriate check box.
Price Lists
A Price List is used to set up prices for each required combination of Price Band and Ticket Type. Boxes can be left blank for any Price Bands or Ticket Types that should not be included in a particular Price List.
When Event Instances are created they are assigned a particular Price List. When you edit this price list in the future, you will be able to choose whether or not the changes are affected on your existing instances.
You should be able to set up a base set of Price Lists which you can repeatedly use for all of your events. You may only occasionally need to set up “special” ones.
To deal with a price increase for a new season, you should generally edit your existing Price List.
For an Event Instance with an Unreserved Seating Area, you will only need to fill in prices for the Price Band you intend to use with the Area.
Ticket Commissions
A Ticket Commission is used to set up commissions for each required combination of Ticket Type and Sales Channel. Then, for every ticket added to the Basket, whether through the Sales Interface or Customer Interface, the appropriate commission can be looked up and applied. Along with Transaction Commissions described below, this allows you to finely control how and where customers are charged commissions.
As with Price Lists, when Event Instances are created they are assigned a particular Ticket Commission. Any changes you make to the Ticket Commission after the Event Instance has been created will not affect the Event Instance. You will need to go into the Event Instance itself to change its Ticket Commission.
When selling tickets through Manned Sales Channels, the sales operator always has the choice of waiving any commission if desired.
Example: to discourage phone sales you may decide to put a 50p commission on all “Adult” tickets bought over the phone but have zero commission for tickets bought over the counter or on the web.
You may find that only one Ticket Commission is necessary for your venue because you charge the same set of commissions regardless of the show. You will need to define at least one Ticket Commission because Event Instances must have one associated. If you don't want to charge any commissions on a per ticket basis, you could leave all the amount boxes empty.
Transaction Commissions
Transaction Commissions allow you to set up commissions which apply at a transaction level rather than a per ticket level. They are set up system-wide as opposed to Ticket Commissions which can be different for every Event Instance. As with Ticket Commissions, they can be set differently for each Sales Channel.
Example: you may want to make a charge of £2 for anyone who decides to make a payment by cheque. To do this modify the value of “Cheque Payment” for the Phone and Counter Sales Channels.
Example: you may want to apply a fixed transaction charge to anyone booking over the phone. To achieve this modify the value of “Transaction” for the Phone Sales Channel.
Lock Types
Locks can be applied to seats in a seating plan to prevent the sale of that seat, or to allocate it for a particular purpose.
A Lock Type should be set up for every reason you have to lock a seat. For customers buying tickets on the web, any seats which are locked simply show as unavailable in the same way as a sold seat does.
For unreserved areas you can apply any number of each type of lock, provided the total number of locks applied does not exceed the number of available seats.
For reserved areas you can apply locks to each seat individually. Each seat can only have one lock applied to it at any one time.
Example: You may want to set up a Lock Type called “House Seat” which you apply to a certain number of seats for every performance and release at the last minute.
Example: You may want to set up a Lock Type called “Wheelchair” which you use for reserved seating plans to lock specific seats which can be removed for wheelchairs if required. You would sell them to wheelchair users when required. Or you could clear the locks once all other seats have been sold if no wheelchairs needed them.
Locked seats can be added to the basket in the same way as ordinary tickets. The lock information will be retained by the seat, and if the tickets are returned, they will revert to their original lock type.
Each Lock Type you set up can be set to require a password to be entered when a sales operator attempts to sell or clear it. You should carefully consider which locks you consider to be sold or cleared on a routine basis and which should only be allowed to be sold or cleared by supervisors who have the password.
Example: You would probably not want to require a password to release a “Wheelchair” as a sales operator would want to be able to perform this routinely when dealing with customers. You probably would want to require a password for a “House Seat” lock as the Box Office Manager would want to keep control over these seats.
Seating Plans
A Seating Plan should be set up for every arrangement of seats for each auditorium in your venue. A Seating Plan can be a single reserved or unreserved seating area. Alternatively for larger auditoriums it can be a group of a number of seating areas. Each of the contained areas can be a reserved or unreserved area or a group of further areas, allowing a nested structure of seating areas within a single master Seating Plan.
Currently only seating plans containing a single unreserved area can be created and edited using the Admin Interface. To get more complex seating plans set up, including reserved areas, please contact support.
Seating Plans can be assigned different layout overlays, which will mask selected seats offsale. You can create price band overlays, to change the price banding; lock overlays, to change which seats are locked by default; and info overlays, to attach warnings to selected seats. These can all be changed whilst the seating plan beneath remains the same, giving you flexibility over your plans—even once the event instances are on sale.
Design your seating plan so that it contains every potential available seat—for example, it should include extra rows at the front of the Stalls (AA and BB, etc) and any boxes and Balcony seats—even if these will generally not be sold. You can mask unwanted seats off sale using mask overlays but you will easily be able to put the seats on sale in the future by changing the masked seats.
Customers
All of your customers should have a unique record in the system to which you log all their ticket sales and other activity. By maintaining your customer database you will, over time, build up a valuable database which you will be able to use for marketing and analysis purposes.
Customers can be created by sales operators through the Sales Interface. They are also automatically created when a customer creates an account on your website.
The e-mail address field in a Customer account must be unique across all Customers. The system will not allow you to create Customers with duplicate e-mail addresses.
When making sales through Manned Sales Channels, your sales operator should search carefully for a customer’s account before creating a new one in order to avoid duplicates.
Tags
Tags can be set up to store additional information about Customers.
Each Tag can be selected or not for each Customer. Tags are organised into groups and both Tags and Tag Groups can be named. You can set each Tag Group to be visible or not on the Customer Interface.
Example: You may set up two Tag Groups – “Preferences” and “Customer Type”. “Preferences” contains tags such as “Drama” and “Comedy” and should be visible on the Customer Interface so that a Customer can select their own preferences. “Customer Type” contains tags such as “Donor” and “Press” which should not be visible on the Customer Interface as only sales operators should be able to select these options on a Customer’s behalf.
Data Protection Statements
Data Protection Statements can be set up to record your Customer’s preferences as to what they have agreed that you are allowed to do with the data you hold about them.
When producing reports the information about which statement each customer has agreed to can form part of the criteria. For example if doing a postal mailing you may only want to include customers who have agreed to a statement related to postal mailings.
Example: You may decide to set up two statements. One would be to ask customers whether they are happy to receive postal mailings. The other would be to ask customers whether they are happy to receive e-mails about upcoming events.
Transactions and Orders
The Spektrix system has two important concepts when it comes to selling and returning tickets and other items.
When a new sale to a customer is made, a new Order is created. Within this Order a new Transaction is also created. The Transaction contains all the activities that were just performed in the sale.
Example: A customer buys three tickets for Macbeth. An Order is created. Inside this Order a Transaction is created. The Transaction contains the sale for three tickets for Macbeth (see below – 1).
If having booked some tickets the customer decides they want to return some tickets, a new Transaction can be created in the original Order and the returns can be added to this.
Registers
Registers are used to keep track of cash payments and a Register should generally be set up for every individual till or cash box that you have. In order to take cash sales a User must first open a Register. Any User can open any register but a register can only be open by one User at any one time. At the end of a shift a User should close their Register. The report that will be produced will show the total amount of cash that should now be in their till.
If two sales operators in fact work off the same physical register, you will still need to set up two registers whose combined totals should equal that of the physical register. This is because in the Spektrix system only one Register can be open by any one user at any time.
Users
Any person who you would like to be able to log into any part of the Client Interface will need to be set up as a User on the system.
Every transaction performed in the Sales Interface is labelled with the User who performed it enabling you to trace recurring problems with any sales operators as necessary.
Once created a User cannot be deleted as they may have transactions associated with themselves. They can however be made inactive, stopping them from being able to log into the system.
Each User can be assigned one or more of the available permissions, including access to the four main interfaces: Sales, Marketing, Admin and Website Admin
Funds
Funds can be set up to allow you to collect donations through your web site. Each Fund you set up would generally correspond to a specific campaign or fundraising activity and can have its own name and description.
A Fund can also have a default donation amount which is filled in automatically when the customer visits the donations page (either independently or on the way to the checkout). However, the customer can choose to override the suggested amount.