-
Notifications
You must be signed in to change notification settings - Fork 22
2. Main concepts and abstractions
-
The patron (model:
Customer
) is the unit to which most operations are indexed. -
Whenever a patron purchases something (even if the "purchase" is actually comped or consists of a donation rather than the purchase of tickets), an order is created (
Order
). The order collects all the items that were purchased together, the manner of payment, and so on. An order is connected to both the person who paid and the person who received the products; these are often the same person, but might not be, for example in the case of gift purchases. Orders can be fully or partially refunded, with the corresponding items then marked as canceled. -
A patron's view of their account is that it holds some number of vouchers (
Voucher < Item
). Some of these may be reserved, for example if they bought tickets to a particular performance. Some may be open, for example if they bought a subscription and want to reserve performance dates for specific shows. Of those that are reserved, you may choose to allow patrons to self-cancel or self-change their reservations, or not.
During season setup, you specify one or more voucher types (Vouchertype
). Typically, a voucher type is either a specific kind of ticket at a specific price point (e.g. "Adult General Admission" at $35.00; "Press Comp" at $0.00), or one of several tickets included in a bundle (see below).
A given voucher type is not automatically valid for a specific performance. A voucher redemption record (ValidVoucher
) is required to make that connection. In effect, a redemption record says: "This type of voucher [e.g. Adult General Admission] is valid for specific performance(s) of this production, possibly subject to sales cutoff dates and capacity restrictions."
When you create any kind of voucher type, whether a single ticket type or a bundle, you can indicate whether purchasing that voucher qualifies the buyer as a Subscriber. This is important because Audience1st allows many operations to distinguish between Subscribers and non-Subscribers. For example, when a new Voucher Type is created, you can specify whether it can be purchased by anyone or only by Subscribers. This makes it easy to offer premium tickets available only for Subscribers, or a general-admission ticket offered at a discount but only to Subscribers.
Each user of the system has one of six privilege levels. A user of a higher level can do everything that a user of lower levels can do. The levels in order of increasing privilege are:
-
Patron: The default level: can log into their own account, manage their own reservations, and edit their own contact information.
-
Staff: Can also generate reports, including mailing lists, box office statistics, etc. Can record donations, search and update patron contact information, and so on. This is the appropriate category for any staff member who needs reporting capabilities but does not deal directly with reservation processing.
-
Walkup Sales: can also do day-of-show box office procedures, such as generating the will-call list, processing walkup sales transactions, and generating the box office settlement report.
-
Box Office: Can also make and cancel advance reservations, search the patron database, update patron information, add and remove comp vouchers from patron accounts, refund orders.
-
Box Office Manager: Can also do season setup: add/edit shows, add/edit performance dates, add/edit voucher types and bundle types, determine which voucher types can be redeemed for which performances.
-
Admin: Can grant/revoke any of the above privileges to other users.
In this guide, "admin" refers loosely to any non-patron privilege level.
All "admin" privilege levels (Staff or higher) can act on behalf of a patron. That is, they can search for a patron by name, view that account as if they were the patron, and generally do all the things the patron could do, acting on behalf of the patron.
The user interface seen by patrons is a proper subset of that seen by staff. At the bottom of every page is a button "Regular Patron View" that lets the logged-in admin see that page as a regular patron would see it (if the page is accessible to patrons at all).
Various features of Audience1st are designed to limit what patrons can do: how far in advance of a show they can reserve tickets, whether they can cancel their own reservations, and enforcement of capacity controls on both overall house size and ticket type inventories.
Admins of any level are immune to these restrictions. They can oversell the house, redeem tickets not normally acceptable for a given performance, and even sell a ticket to a sold-out show that occurred in the past, whereas a regular patron can buy tickets/make reservations as specified by the deadlines and capacity controls that are specified when each production's ticketing is set up.
The initial deployment of Audience1st contains a single administrative user whose login is admin@audience1st.com
and password admin
.
-
The first thing you should do is login as this user and edit the user name and information to match whoever the box office manager or operations manager is. The Admin privilege is the highest privilege and can do anything, so set a good password.
-
Next, create user records for additional staff (box office, phone orders, FOH staff, anyone who will need some level of administrative access). See "Working with users" for how to do this. Edit each user's Billing/Contact info, and under Admin settings for that user, set their privilege level as appropriate (you can always change it later).
Account Codes (model AccountCode
) are optional, arbitrary strings used in your internal financial reporting system; for example, QuickBooks Online uses 4-digit numbers to code accounts. An Account Code can be attached to tickets and subscriptions, donations, retail-sale items, and nonticket purchases (e.g. exchange fees). The revenue reporting breaks out subtotals by account code. There is always at least one Default Account Code, which cannot be deleted but can be changed. That is, at least one Account Code must always exist.