USER GUIDE QUALITY.xlsx
XLSX spreadsheet 26 KB Posted
- Attached to
- Event Registration System
- Contract number
- V18-014-O
- Issued by
- Wisconsin
About this file
This document is a User Guide Quality checklist for an Event Registration System (ERS) used by the University of Wisconsin-Milwaukee (UWM). The document outlines mandatory and non-mandatory technical requirements and functional specifications for event ticketing and registration services, including integration with payment processing, mobile compatibility, and security compliance standards.
The system must support comprehensive ticketing services including multiple payment methods (Visa, MasterCard, American Express, Discover, bank accounts, and PayPal), variable ticket pricing structures, and both paid and free events with no fees charged to UWM or patrons for free events. Key requirements include 99.99% uptime availability, PCI DSS 3.2 compliance for payment security, mobile-responsive design, and integration with UWM's Single Sign On system. The platform must provide customizable reporting capabilities, social media integration, barcode scanning functionality, and comprehensive data export options. Additional services include training documentation, phone support during business hours, API access, and the ability to brand the storefront with UWM logos and information while maintaining UWM's intellectual property ownership.
View the file
Other files
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Sheet1
| Brown Paper Tickets | University Tickets | |
| MANDATORY REQUIREMENTS | ||
| Must assign a unique tracking number for each purchase or transaction. | X | X |
| Patrons must be shown the detailed breakdown of the total amount owed, including any taxes and fees, before entering payment information. | X | X |
| Must automatically add transaction fee, processing fee (ie. credit card fees), and local taxes (ie. where event is being held), if applicable, per ticket or per order. These fees must all be split out. | X | X |
| If event is full (tickets are sold out), ERS must provide a “No more tickets available” or “Tickets sold out” message or similar. | X | X |
| Must accept Visa, MasterCard, American Express, Discover, and Account/Routing Numbers connected to a bank account or PayPal Account. | X | X |
| Must have the ability to offer registration for multiple venues, including venue information and address locations. | X | X |
| Each event that UWM creates must have a distinct URL. | X | X |
| UWM must be able to create “public” and “private” events (ex. Anyone can see the event, vs. only people given the link or invited may see the event). | X | X |
| Must provide printable tickets which can be scanned by event sponsor. | X | X |
| Must be accessible through both desktops, as well as mobile phones/tablets (in a mobile friendly design), with full registration functionality available via either. | X | X |
| Must be available via the latest IE, Firefox, Safari, or Chrome browsers, and be kept current with upgraded browser technology. | X | X |
| Must maintain an uptime of 99.99% to allow 24/7 online registration. | X | X |
| Must support free events (i.e. no minimum fee for tickets), where patrons “sign up” for an event, but there is no fee paid. Vendor must not charge UWM or patron a fee for free events. | X | X |
| Must allow varying/multiple ticket types for one event (ex. child vs. adult tickets) (ex. Bungee jumping and darts as possible ticket types available within the event titled “UWM Fall Welcome”, e.g. mini events within a master event). | X | X |
| Must allow basic custom content that can be added to an event, such as: clickable links, bold font, and images. | X | X |
| Administrators must have the ability to export data, including Customer and Event data (during and after event), as well as have the ability to customize reports of usage within the system (i.e. attendance outcome, history of events, sales data, etc). | X | X |
| Must adhere to the current version of the Payment Card Industry Data Security Standard (PCI DSS) compliance recommendations for payment applications and Services. Vendor is required to annually provide UWM with an Attestation of Compliance signed by either a Qualified Security Assessor or Internal Security Assessor, attesting to the latest version of the PCI DSS security standard, and should be willing to discuss, upon request, the security of the application as it pertains to card holder data security and to prove PCI DSS security and PCI DSS compliance. Current version is PCI-DSS 3.2. UWM reviews PCI DSS documentation and applications annually, and the vendor shall notify UWM immediately if there are any changes to their application affecting cardholder data security. Vendor is responsible for notifying UWM immediately of a change in their designated PCI-DSS compliance. | X | X |
| Vendor must be responsible for cardholder data ownership and cardholder data security. UWM PCI and Information Security policy states that no cardholder data is EVER stored on UWM systems or servers. Vendor shall annually identify ownership and responsibility of cardholder data and cardholder data security, and the provide sufficient information on how cardholder data is transmitted to process credit card transactions. | X | X |
| Data must be stored and transferred with current commercial internet encryption. | X | X |
| Integrated systems must be secure over the public internet. | X | X |
| Vendor must notify UWM of a breach in security within twenty-four (24) hours of discovery. | X | X |
| At contract expiration, archived website content and records must be returned to UWM in an agreed-upon format, media, and timeframe. | X | X |
| Must offer various levels of authorization to UWM staff (Administrator vs. program creator). | X | X |
| Vendor must provide operating and training documentation for the ERS. | X | X |
| Vendor must have support staff available via phone to resolve glitches/issues during normal business hours (Monday – Friday 8:00AM – 4:30 PM CST). | X | X |
| NON-MANDATORY | ||
| Vendor should have documented procedures for escalation of issues, prioritization of problems, and fixes. | X | X |
| Vendor should have documented procedures for communication and implementation of enhancements and updates. | X | X |
| PURCHASES/SALES/REFUNDS | ||
| Should count down the tickets for an event as they are sold/claimed so UWM is aware of how many tickets are remaining. | X | X |
| UWM should have the option to either include the transaction fee in the ticket price, or add the transaction fee on top of the ticket price. | X | X |
| UWM should be able to see all unsold tickets in all ticket prices, if applicable. | X | X |
| UWM should have ability to access or waive any fees for tickets at any time up until the transaction in complete. | X | |
| Should have a place to enter a coupon or discount code. | X | X |
| Payment screen should pre-populate the following information: # of tickets, price per ticket, the “ticket total” price (number of tickets x price per ticket), amount of transaction fee. | X | X |
| Payment screen should calculate the “transaction subtotal” and “transaction total” consisting of total price of tickets, and any applicable taxes and fees. | X | X |
| Should enter the “payment type” or any combination thereof. | X | X |
| Should have additional online payment mechanisms (e.g. ApplePay, PayPal) as a possible payment options. | X | |
| Should be able to accept a non-payment type in lieu of payment type (ex. Interdepartmental accounting charge). | X | X |
| UWM should be able to enter and/or choose the type of payment. | X | X |
| Should have the ability to use multiple types of payment for one transaction. | ||
| Historical data should be available to UWM for the term of the contract. | X | X |
| Administrator should be able to customize system permissions, such as view-only access or create/edit permissions. | X | X |
| Payment methods should add up to the total price (ticket, taxes, and fees) or the sale will not be completed. | X | X |
| UWM should be able to enter check numbers, if applicable. | X | X |
| Should calculate any change due to patron. | X | X |
| Order screen should offer the ability to enter “operator notes”. | X | X |
| The software should provide an API that is accessible to UWM staff. | X | X |
| Should record a refund as a negative transaction in the daily sales reports. | X | |
| Refunds should be processed in and out of the ERS. Only UWM should be able to process refunds. | X | |
| Patron should be able to request a refund, but not process a refund. | X | X |
| Controls over the refund process, such as refunds only being issued in the same manner as the original purchase (i.e. refund issued to the same credit card used to purchase). | X | X |
| TICKETING | ||
| Should have flexibility to create ticket templates including different logos. | X | |
| Should offer Mobile Barcode Software, both for generating a mobile ticket and for scanning a mobile barcode (ex. QR code). | X | X |
| UWM should have the ability to print batch tickets or batched will call tickets. | X | X |
| ONLINE STOREFRONT USER FEATURES | ||
| Should connect to Google Maps (so patrons can interactively move the map and see where the event is located). | X | X |
| Patrons should be able to search by Vendor/Event Holder (ex. UW-Milwaukee) and pull up all events they offer. | X | X |
| Patron should be able to search multiple versions of UWM’s name, or “DBAs” (ex. UW-Milwaukee, UWM, UWM Planetarium, UWM Union, etc.). | X | X |
| Should have the ability to have unique pop-up windows for different performances. | X | |
| Past events should be handled in a graceful manner (user would not receive a 404 error, but a message like “Sorry, this event has already taken place”). | X | X |
| Should have the ability to connect, share, and promote events with social media, such as Facebook, Twitter, or Instagram. | X | X |
| Staff and patrons should have the ability to select tickets for more than one show, performance, and/or start time. Should have “shopping cart” functionally. | X | X |
| Should have a location for “discussion”, where patrons can voice their interests, expectations, or suggestions on what should be covered in the talk or event. | X | X |
| Requestors should be able to indicate accommodations that are needed, such as a wheelchair. | X | X |
| Should have an opt-in option for users to receive administrator-generated auto, push, and SMS notifications. | X | |
| Patrons should have delivery options to choose from: mailed, pick-up at a UWM location, e-ticket via smart pone screen, or print-at-home. | X | X |
| Patrons should be sent a confirmation of purchase message to their email address. | X | X |
| ONLINE STOREFRONT DESIGN/FUNCTIONALITY | ||
| Should have ability to be branded with UWM provided logos/art/information. UWM owns all its own IP/Copyrighted information. | X | X |
| Website storefront should be sortable by multiple variables. | X | |
| Should link to UWM’s homepage (www.uwm.edu). | X | X |
| Should offer some customization to apply UWM branding. | X | X |
| Should be able to handle sub-branding within the system to include outside entities branding. | X | X |
| Should offer a truly/native mobile version of the online store front. | X | X |
| Should offer a “check-in” module, where event holders can scan ticket barcodes (ex. QR codes) and/or mark attendees as “attended” as they arrive to the event. | X | X |
| EVENT BUILDING | ||
| Should have the ability to set, in advance, a start and/or close show sales window on a specific date or time. | X | X |
| Should have the ability to activate or deactivate events at any moment. | X | X |
| Ability to customize event URL. | X | X |
| Participant capacity should be able to change per production. | X | X |
| Should have ability to add a questionnaire/registration online form that can be retrieved via report. | X | X |
| Should be available 24/7 except for a pre-planned maintenance window that is announced ahead of time. | X | X |
| UWM should be able to “un-archive” past events and/or duplicate past events (ex. Annual events, instead of creating from scratch each year, can copy from last year’s event). | X | X |
| Should have the ability to change pricing or fees AFTER the event is activated and purchases have been made. | X | X |
| REPORTING | ||
| Should offer customizable reporting platform to provide UWM the ability to run reports using UWM’s choice of data elements stored in ERS. | X | X |
| Database should be searchable at a minimum by: First Name, Last Name, Patron ID number, email address, confirmation number, and date of sales. | X | |
| Platform should have the ability to create and save reports that need to be run on a regular basis. | X | |
| Platform should enable reports to be viewable online and/or offer the ability for reports to be printed or saved. | X | X |
| Reports should be exportable in .html, .xls, and .pdf formats. | X | |
| Reports should consist of a summary and detail section for a specific date. | X | X |
| Each event should have a separate ID to track revenue per event. Ability to set up sub-events and/or keep same id per recurring event. | X | X |
| SECURITY | ||
| Should log out after a period of inactivity, set by UWM administrators. | X | |
| Must integrate with UWM’s Single Sign On (Shibboleth). | X | |
| Should store only the last four digits of a credit card number on a credit card transaction. | X | X |
| Should have an alert system to share unexpected system failure. | X | |
| Should be able to recover from an unexpected failure in no more than four (4) hours. | X | X |
| Should limit the control of adding deposit information for UWM to the administrator level or specific security role permission. | X | X |
| UWM STAFF USABILITY | ||
| UWM staff should be able to create reports from the system after a reasonable amount of training. | X | X |
| UWM staff should be able to perform database searches on more than one data item at a time. | X | |
| Should have audit feature for internal tracking of changes. | X | X |
| Consulting services on event best practices should be available. | X | X |
| UWM staff should have an individualized login per user. | X | X |
| Staff should have the ability to communicate to all registrants via the application (e.g. emergency event cancelation). | X | X |
| UWM staff should have option to track people who have signed up, have access to patron contact information, etc. | X | X |
| Vendor should be able to create mailing and emailing lists of patrons as needed, so UWM can communicate via email to registered patrons within the ERS. | X | X |
| Vendor should provide UWM with training and technology marketing materials to promote the ERS system internally to patrons and staff. | X | X |
http://www.uwm.edu/
File details come from the government source that posted it. Updated .