Exhibit D Quality Questions Peck School of the Arts Ticketing Software System.docx

47 KB Posted

Attached to
Ticketing Solution UWM Peck School of the Arts
Solicitation number
E17-062-OP
Issued by
Wisconsin

About this file

Written by GovTribe AI ·

This document is a Quality Questions exhibit for a Request for Proposals (RFP #E17-062-OP) issued by the University of Wisconsin-Milwaukee's Peck School of the Arts for a cloud-based ticketing software system (SaaS solution). The RFP seeks an internet-hosted ticketing platform capable of managing sales across multiple venues and event types, including merchandise, tickets, workshop admissions, and registration events. The exhibit comprises a comprehensive checklist of mandatory requirements, system and service goals, and nonfunctional requirements that prospective vendors must address by marking "yes" or "no" responses and providing numerical values for specific capacity questions.

The mandatory requirements encompass critical functionality including multi-type sales capability, patron profile management, PCI DSS 3.2 compliance with annual documentation, 99.99% uptime for 24/7 availability, ADA Section 508 accessibility with wheelchair seating accommodations, support across current versions of IE, Firefox, Safari, and Chrome browsers, and comprehensive documentation and online training. System and service goals address database management with unique transaction numbering, vendor-provided phone support with documented escalation procedures, customizable reporting with searchable patron databases, individualized staff logins with Shibboleth Single Sign-On integration, point-of-sale functionality with reserved seating charts, fee management capabilities, multiple payment type acceptance, ticket printing on non-proprietary stock, and refund processing. Nonfunctional requirements establish standards for 24/7 availability with scheduled maintenance windows, encryption for data storage and transfer, immediate notification of PCI-DSS compliance changes and security breaches within 24 hours, automatic logout after inactivity, system recovery within four hours of unexpected failure, audit capabilities, and provisions for data migration and archival in agreed-upon formats should the vendor cease operations.

View the file

Other files

File Type Posted
Exhibit F Narration of Solution.docx DOCX document
Vendor Reference POS.docx DOCX document
Exhibit H Maintenance Info.docx DOCX document
DOA-3054 RFB Ts Cs.docx DOCX document
Exhibit I Information Security Requirements.docx DOCX document
Exhibit A Peck Ticketing RFP response requirements.docx DOCX document
RFP Doc PEck School Arts Ticketing Solution.docx DOCX document
Amendment to RFP NO. E17-062-OP.docx DOCX document
Ticketing RFP Vendor questions.pdf PDF
Exhibit E Proforma Contract No. E17-062-OP.docx DOCX document
Exhibit G UWM Ts Cs for Peck Ticketing rfp.docx DOCX document
DOA-3054A Purchase Order Ts Cs.docx DOCX document
Exhibit B Peck Ticketing RFP Terms Acceptance.docx DOCX document
Index of documents PSOA Ticketing.docx DOCX document
Confidential and Proprietary Information Peck Ticketing.docx DOCX document
Exhibit C Cost Proposal.docx DOCX document
Vendor Info Peck Ticketing.docx DOCX document
Show all 17

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file
Try for free Login

Text version

The file's text, extracted by GovTribe without its formatting.

UWM Peck School of the Arts Ticketing System – RFP # E17-062-OP – Exhibit D – Quality Questions

1.1 Purpose of this exhibit

This exhibit is a list of all the PSOA mandatory requirements and desired functions for this system. Please check the appropriate “yes” or “no” box with an “X”. Insert the appropriate numerical value in the answer to NE1 and NE2 below.

1.2 Mandatory Requirements

ID
Expectations
YES
NO
A1
The ticketing software system (TSS) must offer multiple Type of Sales functionality
|_|
|_|
A2
The TSS shall allow the online patron to set up and save an individual profile online (via the website/portal), including the ability to manage their own account profile and the ability to establish an account independent of purchasing tickets
|_|
|_|
A3
Merchandise, tickets, workshop admission and registration events shall be ordered using the TSS.
|_|
|_|
A4
TSS shall adhere to the current version of PCI DSS Payment Application compliance recommendations and annually provide UWM with relevant documentation to prove PCI security and PCI compliance. Current system is PCI-DSS 3.2. This is reviewed annually and TSSU shall notify UWM immediately if there are any changes.
|_|
|_|
A4.1
TSS agrees it is responsible for data ownership. UWM PCI and Information Security policy states that no cardholder data is stored on UWM systems. TSS shall identify ownership and responsibility of cardholder data used to process transactions.
|_|
|_|
A5
TSS must be available via the latest IE, Firefox, Safari, Chrome browsers and be kept current with upgraded browser technology.
|_|
|_|
A6
TSS must maintain an uptime of 99.99% to allow 24/7 online ticketing
|_|
|_|
A7
TSS must provide written documentation (e.g. printed or online manuals, online help/FAQ/forums) on procedures for operating the TSS.

Online training should be available for implementing, maintaining and using product.

|_|
|_|
A8
TSS must have functionality to ensure ticketing operations are ADA compliant, specifically with ADA Section 508, including the ability to accommodate wheel chair designation on seating charts.
|_|
|_|
A9
TTS must be able to create mailing and emailing lists of patrons as needed.
|_|
|_|
A10
The TSS must have the ability to offer ticketing for multiple venues, including venue information and address locations.
|_|
|_|
A11
The TSS must offer various levels of authorization/role to UWM staff to restrict/allow box office functions such as waiving fees, Box Office Management must have ‘SuperUser’ administrative access
|_|
|_|

1.3 System and Service Requirements

University, PSOA and Box Office requirements for a ticketing software system.

ID
System Goals
YES
NO
PSOA/Box Office Goal 1
Ticketing Software System (TSS) as a database
Goal 1.1
General functions or feature of the Ticketing Software System
1.1.1
The TSS must assign a unique number for each purchase or transaction. The ability to choose the length of digits is a plus.
|_|
|_|
1.1.2
The TSS must be able to archive past events for easy access.
|_|
|_|
Goal 1.2
TSS vendor should have designated support staff to work with PSOA on an on-going basis.
1.2.1
TSS vendor should have a phone support available to resolve issues. (Note: Also, state your support business hours and time zone in your narration).
|_|
|_|
1.2.2
TSS vendor should have documented procedures for escalation of issues, prioritization of problems, and fixes.
|_|
|_|
1.2.3
TSS vendor should have documented procedures for communication and implementation of enhancements and updates.
|_|
|_|
Goal 1.3
PSOA needs the ability to run reports using TSS data.
1.3.1
TSS should offer customizable reporting platform to provide PSOA the ability to run reports using our choice of data elements stored in the TSS.
|_|
|_|
1.3.2
The TSS patron database should be searchable at a minimum by;

· First name and Last name

· Patron ID number

· Email address

· Confirmation Number

· Date of Sales

|_|
|_|
1.3.3
Reporting platform should have the ability to create and save reports that need to be run on a regular basis.
|_|
|_|
1.3.4
Reporting Platform should enable reports to be viewable online and/or offer the ability for reports to be printed or saved.
|_|
|_|
1.3.5
Reports should be exportable in .html, .xls or .pdf formats
|_|
|_|
1.3.6
Reports should consist of a summary and detail section for a specific date.
|_|
|_|
Goal 2
Operations
Goal 2.1
Operation
2.1.1
PSOA Staff should have an individualized log in per user.
|_|
|_|
2.1.2
Ability to integrate with UWM’s Single Sign On (Shibboleth)
|_|
|_|
2.1.3
The TSS must have the ability to change pricing or fees AFTER the event is activated and purchases have been made.
|_|
|_|
Goal 2.2
Point of Sales Abilities
2.2.0
The TSS should store only the last four digital of a credit card on a credit card transaction.
|_|
|_|
2.2.1
The TSS should countdown the tickets for a show as they are sold so the Box Office Staff is aware of how many tickets are remaining.
|_|
|_|
2.2.2
For reserved seating events, staff should have access to a seating chart on screen.
|_|
|_|
2.2.3
Staff should be able to see all unsold tickets in all ticket prices, if applicable.
|_|
|_|
2.2.4
The TSS should allow staff to pick specific reserved seat(s).
|_|
|_|
2.2.5
TSS must be able to select reserved seats according to the next best tickets available in each pricing category if individual seats are not selected.
|_|
|_|
2.2.6
Staff and patrons should have the ability to select tickets for more than one show, performance, and/or start time. The TSS should have “shopping cart” functionally.
|_|
|_|
2.2.7
The TSS should to be able to assess exchange fees, if necessary.
|_|
|_|
Goal 2.4
Assessing and collecting fees
2.4.1
Staff should be able to enter types of sales on screen.
|_|
|_|
2.4.2
The TSS should automatically add transaction fee per ticket or per order.
|_|
|_|
2.4.3
Administrative Box Office Staff should have the ability to assess or waive any fees for tickets at any time up until the transaction is complete.
|_|
|_|
2.4.4
How many different types can be added per ticket or per transaction?
|_|
|_|
2.4.5
The TTS payment screen should pre-populate the following information;

· The number of tickets

· The price per ticket

· The “ticket total” price (number of tickets x price per ticket)

· The amount of transaction fee.

|_|
|_|
2.4.6
The TTS payment screen should calculate the “transaction subtotal” consisting of total price of tickets and fees.
|_|
|_|
2.4.7
The TTS should calculate the grand total to be collected.
|_|
|_|
2.4.8
TTS should enter the “payment type” or any combination thereof.
|_|
|_|
2.4.9
The TTS should be able to accept a non-payment types in lieu payment type. An example would be an interdepartmental accounting charge.
|_|
|_|
Goal 2.5
TSS point of sale payment collection
2.5.1
Staff should be able to enter (and or choice) the type of payment.
|_|
|_|
2.5.2
TTS should have the ability to use multiple types of payment for one transaction.
|_|
|_|
2.5.3
The payment methods should add up to the total price (ticket and fees) or the sale will not be completed.
|_|
|_|
2.5.4
Staff should be able to enter in check number, if applicable.
|_|
|_|
2.5.5
The TSS should calculate any change due the patron.
|_|
|_|
2.5.6
Order screen should offer the ability to enter “operator notes”.
|_|
|_|
Goal 2.6
The TSS must be able to print tickets and receipts
2.6.1
The tickets should be printed on blank stock.
|_|
|_|
2.6.2
The ticket stock used by TSS will be non-proprietary.
|_|
|_|
2.6.3
TSS should be able to print on BOCA printer products. A relationship will BOCA or other printing systems needs to be discussed.
|_|
|_|
2.6.4
The TSS should have the flexibility to create tickets templates including different logos.
|_|
|_|
Goal 2.7
Box Office Staff should be able to sell tickets for other non-PSOA entities.
2.7.1
Refunds should be processed in and out of the TSS.
|_|
|_|
2.7.2
The TSS should record a refund as a negative transaction in the daily sales reports.
|_|
|_|
2.7.3
Staff should have the ability to print batch tickets or batched will call tickets.
|_|
|_|
Goal 3
Online Patron Experience
Goal 3.1
Patron User Account
3.1.1
Patrons will have the choice of creating a new account, logging into a previously established account, or checking out with a guest account.
|_|
|_|
3.1.2
Patrons needs the ability to save or change information.
|_|
|_|
Goal 3.2
Online Storefront, Ordering and Payment
3.2.1
Patrons needs to be able to view all program information on the PSOA box office online storefront. Including;

· Event

· Dates and times

· Venue (and location)

· Description of Event

· Pricing

|_|
|_|
3.2.2
Storefront needs to be organized by date and time.
|_|
|_|
3.2.3
The TSS should display a seating chart, if applicable for the selected venue.
|_|
|_|
3.2.4
The TSS should have an option to choose the next best available seats for reserved seated performances.
|_|
|_|
3.2.5
Patrons should be shown detailed breakdown of the total amount owned, including any fees, before entering payment information.
|_|
|_|
3.2.6
The TSS should have the ability to have unique pop-up windows for different performances.
|_|
|_|
3.2.7
Patrons should have delivery options; mailed, waiting at will call, e-ticket via smart phone screen or a print-at-home option.
|_|
|_|
3.2.8
Patrons should be sent a confirmation of purchase message to their email address.
|_|
|_|
3.2.9
Box Office should have the ability to reprint tickets.
|_|
|_|
Goal 3.3
Online Storefront Design
3.3.1
The TSS should have the ability to be branded with UWM/PSOA provided logos/art/information. UWM owns all its own IP/Copyrighted information.
|_|
|_|
3.3.2
The TSS should have the look and feel of PSOA website (including logos, banners, and design elements).
|_|
|_|
3.3.3
The TSS should be able to handle sub-branding within the system to include outside entities branding.
|_|
|_|
3.3.4
The TSS should offer a truly/native mobile version of the online store front.
|_|
|_|
Goal 4
Box Office Management (BOM) and Event Building
Goal 4.2
An “event or performance” shall be built in TSS
4.2.1
The TSS should have the ability to set, in advance, a start and/or close show sales window on a specific date or time.
|_|
|_|
4.2.2
The TSS should have the ability to active and deactivate events at any moment.
|_|
|_|
4.2.3
Seat and audience capacity should be able to change per production.
|_|
|_|
4.2.4
The TSS should have the ability to block off or hold seating for any of the seating charts used.
|_|
|_|
4.2.5
The TSS should have the ability to add a questionnaire/registration online form that can be retrieved via report.
|_|
|_|

Nonfunctional Requirements Nonfunctional requirements focus on the qualities that must be applied to design and implement the system. These are specific standards and attributes in support of the other requirements.

ID
Nonfunctional Requirement Statements
YES
NO
NA1
The TSS should be available 24/7 except for a pre-planned maintenance window that is announced ahead of time.
|_|
|_|

Integrity – Security Needed (authorized access, software, hardware and privacy)

NI1
Data must be stored and transferred with current commercial internet encryption.
|_|
|_|
NI2
Integrated systems must be secure over the public internet.
|_|
|_|
NI3
The TSS must be responsible for notifying UWM immediately of a change in their designated PCI-DSS compliance.
|_|
|_|
NI4
The TSS should logout after a period of inactivity, set by administrators.
|_|
|_|
NI5
The TSS vendor must notify PSOA of a breach in security within 24 hours of discovery.
|_|
|_|
NI6
UWM contract to address this
|_|
|_|
NI7
The TSS vendor must provide a written recovery plan of the PSOA database.
|_|
|_|

Interoperability – Compatibility or ability to exchange date or services with other systems.

Robustness – Degree to which system continues to function when unexpected operating conditions occur.

NB1
The TSS should be able to recover from an unexpected system failure in no more than 4 hours.
|_|
|_|
NB2
Vendor should an alert system to share unexpected system failure.
|_|
|_|

Usability – Effort required to prepare input, operate and retrieve output by various users.

NU1
PSOA staff shall be able to create reports from the system after a reasonable amount of training.
|_|
|_|
NU2
PSOA staff should be able to perform database searches on more than one data item at a time.
|_|
|_|
NU3
TSS should have audit feature for internal tracking of changes.
|_|
|_|
NU4
Consulting services should be available.
|_|
|_|

Portability – Migration of data form one operating environment to another.

NP1
Archived website content and records must be returned to the PSOA in an agreed upon format and media.
|_|
|_|
NP2
If the vendor stops hosting this product, website content and records must be returned to PSOA in the time frame outlined in the contract.
|_|
|_|

Efficiency Response time: NE1 – How many users can input data simultaneously?

Efficiency Capacity: NE2 – How many minutes do confirmation emails take to reach the customer?

File details come from the government source that posted it. Updated .