L and P Ticketing System Performance Work Statement DRAFT Working Copy.docx
DOCX document 3 MB Posted
- Solicitation number
- 88310324RFI00006
About this file
This document is a Performance Work Statement (PWS) for a ticketing, admission, visitor, and event management system for the National Archives and Records Administration (NARA). NARA requires a cloud-hosted software-as-a-service (SaaS) solution that can integrate online and onsite ticketing, reservations, and facility/resource management across the National Archives in Washington, D.C. and the Presidential Libraries. The PWS outlines the functional and non-functional requirements for the system, including sales and reservations, point-of-sale, data reporting, security, availability, and accessibility. The PWS also details project management and reporting requirements, deployment and transition support, training, and the government's contracting approach. This PWS is related to a pre-solicitation for a new NARA enterprise ticketing system.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 88310324RFI00006 Archives I and Presidential Libraries Ticketing System Q and A FINAL.docx | DOCX document | |
| NARA Ticketing System RFI RVTM 2024June07.xlsx | XLSX spreadsheet | |
| 88310324RFI00006 Request for Information - Market Research Archives I and PL Ticketing System.docx | DOCX document |
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
ATTACHMENT 2
PERFORMANCE WORK STATEMENT
L and P Ticketing System
1.0 BACKGROUND
1.1 The National Archives and Records Administration (NARA) is an independent Federal agency that helps safeguard and preserve our nation's history by overseeing the management of all Federal records. The stories of our nation and our people are told in the records and artifacts cared for in NARA facilities around the country and people can discover, use, and learn from this documentary heritage. NARA’s mission is to ensure ready access to essential evidence that documents the rights of American citizens, the actions of Federal officials, and the national experience.
1.2 NARA’s Rotunda, exhibit spaces, and learning space at the National Archives located in Washington, D.C. (“Archives I”) and its Presidential Libraries and Museum (“Presidential Libraries”) sites located across the country welcome nearly 2 million visitors each year and play a critical role in connecting with customers and making access to its records happen.
1.3 Presently visitors to the Archives I and Presidential Libraries use separate ticketing systems. NARA would like to combine its ticketing capabilities into one customizable solution for a more efficient and cost effective means of providing a high quality user experience to its visitors.
1.4 The Archives I uses Recreation.gov for its online ticketing capabilities. Admission to the Archives I is free but an advance reservation convenience fee of $1 is charged for each ticket to those using Recreation.gov to reserve tickets before their visit.
1.4.1 Tickets purchased online allow users to have a timed entry into the Archives I.
1.4.2 The Archives I is currently undergoing a renovation that is planned to be completed in the spring of 2025, a major goal of which is to enhance the visitor experience through an updated ticketing capability.
1.5 The current Presidential Libraries ticketing system provided by ACME Technologies is a cloud-hosted Software as a Service (SaaS) ticketing and resource management solution.
1.5.1 Eight of the 15 Libraries use the system to support onsite and online ticket sales, handled through a “box office” model where NARA personnel handle the transactions at a Point of Sale (POS) system:
· Herbert Hoover Presidential Library and Museum, West Branch, IA
· Franklin D. Roosevelt Presidential Library and Museum, Hyde Park, NY (National Park Service manages on-site and online group reservation sales only.)
· Harry S. Truman Presidential Library and Museum, Independence, MO
· Dwight D. Eisenhower Presidential Library and Museum, Abilene, KS
· John F. Kennedy Presidential Library and Museum, Boston, MA
· Gerald R. Ford Presidential Library and Museum[footnoteRef:1] [1: The Ford Presidential Library and Museum has two campuses, but one configuration. ]
· Library – Ann Arbor, MI (no ticketing needs here)
· Museum – Grand Rapids, MI
· Jimmy Carter Presidential Library and Museum, Atlanta, GA
· George H.W. Bush Presidential Library and Museum, College Station, TX
1.5.2 NARA’s POS ticketing system integrates with NARA’s implementation of Microsoft Dynamics Great Plains to manage its financial transactions.
1.5.3 The remaining Presidential Libraries that do not use the POS front-end, use an alternative ticketing system not within the scope of this contract. However, they do use this system for the sharing and storage of visitor stats collected via third-party ticketing systems. They also use it for In addition, these Libraries currently use the functionality to reserve school groups and other group tours at each Presidential Library and Museum across the country and manage facility rentals and equipment reservations for those rentals. The Libraries that use the system to collect third-party ticketing information for statistical review include:
· Lyndon Baines Johnson Presidential Library and Museum, Austin, TX
· Richard Nixon Presidential Library and Museum, Yorba Linda, CA
· Ronald Reagan Presidential Library and Museum, Simi Valley, CA
· William J. Clinton Presidential Library and Museum, Little Rock, AR
· George W. Bush Presidential Library, Dallas, TX
2.0 SCOPE
2.1 NARA requires a ticketing, admission and visitor, and event management system that will integrate onsite and online sales, individual and group reservations, resource management and reporting into a single user friendly and customizable system. The goals of deploying a single, integrated ticketing system are to ensure consistency and automation of the reporting of attendance and sales data; simplifying financial processing; simplifying operations and maintenance of the system; and making visiting a NARA site requiring ticketing as convenient as possible for the general public.
2.2 The ticketing system will allow NARA staff to better manage visitor flow, promote deeper exploration of onsite and online resources, and expand the visitor experience beyond the specific ticketed day by sending via email curated pre-visit and post-visit information such as satisfaction surveys, accessibility information, and other relevant data that allow guests to build an itinerary and customize their experience. A ticketing system will also assist with managing visitor flow through advanced ticket sales and timed ticketing reservations.
2.3 NARA requires the ticketing system to collect information which may be used for reporting and planning future programming. This data includes not only visitor counts and demographic information, but also options to provide program feedback and audience evaluations that will allow NARA to better track customer satisfaction and make adjustments as needed.
2.4 NARA requires the Contractor to furnish, configure and deploy a SaaS that is scalable; fully hosted; capable of meeting NARA’s needs with minimal integration and configuration modifications to its websites; and requires minimal changes to business processes or employee workflows. The Contractor shall be responsible for the full project lifecycle, which includes, but is not limited to: configuration of the system; deployment; training of the NARA internal users on the operations of the system; operations and maintenance of the system; and periodic enhancements to the system for the Archives I and each of the Presidential Libraries.
2.5 The Contractor shall provide onsite capabilities such as a kiosk to reserve and pay for tickets, ticket printing, and ticket scanning. The Contractor shall also build a mobile application for each NARA site that shall provide the same ticketing capabilities as its kiosk functionality.
2.5.1 On average a typical NARA site will consist of 10 users, one kiosk (optional), three scanners, two ticket printers, and two receipt printers.
2.6 The Contractor shall migrate data from NARA’s existing ticketing systems (as needed) to the new cloud-hosted SaaS solution. The Contractor shall maintain the legacy data and future collected data within the new ticketing system.
2.7 The Contractor shall implement the controls contained within the FedRAMP Cloud Computing Security Requirements Baseline and FedRAMP Continuous Monitoring Requirements for Moderate impact systems (as defined in FIPS PUB 199). These documents define requirements for compliance to meet minimum Federal information security and privacy requirements for Moderate impact systems. The FedRAMP baseline controls are based on NIST Special Publication 800-53, Revision 4, “Security and Privacy Controls for Information Systems and Organizations,” and includes a set of additional controls for use within systems providing cloud services to the federal government.
| 2.7.1 | The Contractor shall generally, substantially, and in good faith follow FedRAMP guidelines and Security guidance. In situations where there are no procedural guides, the Contractor shall use generally accepted industry best practices for IT security. |
| 2.7.2 | NARA may choose to cancel the contract and terminate any outstanding orders if the contractor has its FedRAMP authorization (Joint Authorization Board [JAB] Provisional or Agency) revoked and the deficiencies are greater than agency risk tolerance thresholds. |
| 2.8 | The ticketing system must be available 24 hours a day, seven days a week, 52 weeks a year except under normal maintenance windows which will not exceed more than eight (8) hours per instance and not more than twice per month unless otherwise approved by the Contracting Officer’s Representative (COR). Maintenance windows must occur outside typical business working hours. |
2.9 All services required herein shall be performed at the Contractor’s facilities. Meetings, briefings, and presentations shall, to the maximum extent practicable, be held via teleconference or webinar using either contractor furnished or NARA furnished telecommunications services. Travel costs will be reimbursed as required under this contract.
2.10 NARA would like to establish a ticketing capability for the Archives I first and for the eight Presidential Libraries and Museums listed in Section 1.5.1 in a phased manner over the contract’s first three option periods.
2.10.1 In its Project Management Plan (PMP), the Contractor shall propose a plan for the most cost effective and time efficient rollout of its ticketing system. The rollout schedule shall include options to accelerate the implementation of the ticketing capability for the remaining sites should NARA decide to adopt this sooner.
3.0 PROJECT MANAGEMENT AND REPORTING
3.1 The Contractor shall participate in a post-award Kickoff Meeting with the NARA Program Manager, Project Manager, the Contracting Officer’s Representative (COR), Contracting Officer (CO) and key business stakeholders within five (5) business days after the award date of the contract and no later than September 30, 2024 to prepare NARA and the Contractor for the work described in this PWS.
3.1.1 The meetings shall be conducted via videoconference.
3.1.2 The Contractor shall be responsible for creating the agenda and documenting meeting minutes. These meeting minutes shall be delivered to the COR no later than two (2) business days after the meeting is held.
3.1.3 The purpose of these meetings are to ensure mutual understanding of critical components of the work and to introduce team members to key personnel.
3.2 The Contractor shall work in collaboration with NARA to ensure the project is a success. The main point of contact will be the COR. The Contractor shall coordinate with NARA’s Information Services (I) staff who will handle the COR and project management responsibilities, Presidential Libraries (P) staff, and the Public Museum Engagement and Legislative Archives (L) who will represent the Archives I.
3.3 All Project Management activities performed by the Contractor shall be in accordance with NARA’s System Development Life Cycle (SDLC).
3.4 The Contractor shall develop and deliver a Project Management Plan (PMP). The PMP shall describe the Contractor’s overall strategy and approach to implementing the services provided under this contract. The Contractor shall meet with the NARA project team to coordinate project roles, responsibilities, and schedules. The Contractor shall be prepared to discuss the PMP including the schedule, required resources, and how updates or changes to the plan are to be managed and communicated through the duration of the contract.
3.5 The Contractor shall provide monthly status reports (due the 1st business day of each month) which shall include the following: tasks accomplished within the previous month, progress towards completion of the scheduled tasks, and deliverables submitted. The report shall include any problems, issues, or explanations of schedule slippage to include recommendations on remediation of those issues, plan for recovery from the schedule slippage, and potential impact to the timely delivery of services within acceptable quality standards.
4.0 Performance Degradation/Unplanned Outage Notifications. The Contractor shall send an email to the NARA team (COR and NARA Administrators) within one (1) hour after it discovers an outage of its SaaS or any related component provided by the Contractor which prevents users from accessing or using the ticketing system.
4.2.1 Upon restoration of services, the Contractor shall notify the NARA team immediately. Within two (2) business days of incident resolution, the Contractor shall provide an incident report. The report shall address the following:
4.2.1.1 Summary of the incident;
4.3.1.2 Duration of the outage;
4.2.1.3 Root cause;
4.2.1.4 Resolution; and
4.2.1.5 Proposed mitigation against future outages.
4.3 Weekly Status Reports. The Contractor’s project manager shall conduct Weekly (or less, as mutually agreed) Status meetings with NARA.
4.3.1 During these meetings, the Contractor’s project manager shall report to NARA, the following:
4.3.1.1 System status;
4.3.1.2 Action item log status;
4.3.1.3 Issues log status;
4.3.1.4 System availability metrics;
4.3.1.5 Ticket coverage performance review (to show turn-time for each level of support and review of any outliers);
4.3.1.6 System downtime; and
4.3.1.7 Risk management (risk register) status.
4.3.2 For each Weekly meeting, the Contractor shall write and submit the agenda, one (1) business day in advance of the meeting. Additionally, the Contractor shall record and distribute the meeting minutes, which address the substance of the meeting, action items, and individual(s) assigned to the action items within three (3) business days after the meeting.
4.4 Meetings. The Contractor shall participate in ad hoc meetings as necessary for the execution of this PWS. If the Contractor requires or needs particular NARA personnel present, the Contractor shall request that directly through the COR.
4.5 Release Schedule
4.5.1 The Contractor shall develop a release schedule to document and track all upcoming releases for the ticketing system. The schedule will include at a minimum:
4.5.1.2 All tasks to be completed;
4.5.1.3 Planned and Actual Start/Finish dates;
4.5.1.4 Resources;
4.5.1.5 Dependencies;
4.5.1.6 Federal holidays; and
4.5.1.7 Deliverables.
4.5.2 The release schedule shall be submitted ten (10) business days after the kick-off meeting to the COR for review and acceptance.
4.5.3 The final schedule shall be due ten (10) business days after receipt of the review comments from the COR.
4.5.4 The Contractor shall provide updates to the release schedule when tasks change.
4.5.5 The release schedule shall adhere to the NARA IT Project Management schedule template and must be in Microsoft Project (MPP), (Auto Schedule mode) format. The schedule must include:
4.5.5.1 Task Name;
4.5.5.2 Duration;
4.5.5.3 Percent Complete;
4.5.5.3 Baseline Start;
4.5.5.4 Start;
4.5.5.5 NARA Actual Start;
4.5.5.6 Baseline Finish;
4.5.5.7 Finish;
4.5.5.8 NARA Actual Finish;
4.5.5.9 Predecessors; and
4.5.5.10 Resource names.
4.5.6 These SDLC activities include:
4.5.6.1 Requirements Stage Gate review and approval;
4.5.6.2 Design Stage Gate review and approval;
4.5.6.3 User Acceptance/ Test Stage Gate review and approval;
4.5.6.4 Security Stage Gate review and approval; and
4.5.6.5 Project Change Control Advisory Board (CCB) review and approval.
4.5.7 High-level milestone schedule of Contractor activities required to complete and deliver ticketing system releases. All NARA dependencies must be clearly identified.
4.6 Monthly Status Reports
4.6.1 The Contractor shall provide a monthly status report by the first (1st) business day of each month. The monthly status report shall include, at a minimum, the following program and financial information for each month performed under this contract. Monthly Status Reports shall contain at a minimum:
4.6.1.1 Summary of Major Programs/Policies/Support including current status and next steps;
4.6.1.2 Minor/Major releases;
4.6.1.3 Notable Company Updates;
4.6.1.4 Product support incidents;
4.6.1.5 Significant Project Milestones (Next Three Months);
4.6.1.6 Current Factors Impacting Schedule & Remediation;
4.6.1.7 Tasks accomplished within the previous month, progress towards completion of the scheduled tasks, and deliverables submitted;
4.6.1.8 Updated release schedule as described in section 4.5;
4.6.1.9 Planned activities for the current month and dependencies on completing those tasks;
4.6.1.10 Any problems, issues, or explanations of schedule slippages, in the previous month, to include recommendations on remediation of those issues, plan for recovery from the schedule slippage, and potential impact to the timely delivery of services within acceptable quality standards;
4.6.1.11 Device status for each point of sale device including, operating system patches or updates required, current operating system version, and point of sale application version;
4.6.1.12 Back office application version report.
4.6.2 Risk Register. The Contractor shall provide a risk register on the first (1st) business day of each month. The risk register must document any projected or actual risks to successful performance of services, to include the remediation or mitigation of those risks, as they arise. The Risk Register shall document
4.6.2.1 Risk Title and Description;
4.6.2.2 Date Identified and Entered;
4.6.2.3 Risk Owner;
4.6.2.4 Risk Statement (If-Then with Condition and Consequence);
4.6.2.5 Risk Probability (1-5);
4.6.2.6 Risk Impact (1-5);
4.6.2.7 Risk Value;
4.6.2.8 Risk Mitigation;
4.6.2.9 Risk Contingency;
4.6.2.10 Risk Status; and
4.6.2.11 Plan of Action and Milestones (POAM) number, if required.
4.0 REQUIRED SERVICES
4.1 Operations and Maintenance Support. Service Desk Support. The Contractor shall provide service desk support to internal users, both online and via telephone. The Service Desk shall provide one phone number and website uniform resource locator (URL) for internal users. Service shall include, but not be limited to assistance with:
4.1.1 Technical questions associated with internal user configuration;
4.1.2 Resolution of technical problems; and
4.1.3 Other system functionality questions, regardless of complexity and tier of support required to remediate or assist.
4.1.4 The Contractor should plan to provide support to internal users with disabilities and be prepared with strategies for doing so.
4.1.5 Service Desk support shall be provided for internal users from 8:00 AM ET through 10:00 PM ET, seven (7) days a week.
4.1.5.1 The Contractor shall answer 95% of the calls received within 2 minutes.
4.1.5.2 The Contractor shall resolve all minor incidents, those that affect one (1) internal user (e.g. login error, user account password resets, etc.), within 2 hours of the incident being reported.
4.1.5.3 The Contractor shall provide fixes or alternative workarounds, as appropriate, for major incidents, those that affect two (2) or more internal users (e.g. unplanned or temporary interruption of service or disruption of core software functionality), reported within four (4) hours.
4.1.5.4 Written follow-up to NARA of incident and resolution must be provided by the Contractor within eight (8) hours for major incidents.
4.1.5.5 All problems shall be analyzed and a proposed resolution provided to the COR for approval.
4.1.5.6 The Contractor shall also provide ongoing consulting services on best practices for use of the software and recommendations on business process improvements.
4.1.5.7 The point of sale application must be maintained and updated by the Contractor.
4.1.5.8 The contractor must provide hardware support for any peripheral devices (ticket printers, iPads, credit card readers, etc.) either directly or through subcontractors.
4.2 System Hosting
4.2.1 The system shall be hosted through a Cloud Service Provider (CSP) infrastructure-as-a-service (IaaS) that is FEDRAMP authorized at the moderate impact level as listed on the official FedRAMP site (https://www.fedramp.gov/marketplace/).
4.2.2 The Contractor will be the stewards of the data and systems in its cloud, but ultimately the data belongs to NARA. The Contractor shall ensure that NARA can seamlessly transition that data to and from the Contractor’s cloud infrastructure as efficiently, simply, and as cost effectively as possible.
4.2.3 The Contractor’s cloud solution must use industry standard virtual machine configurations that can be ported to other cloud environments either by direct import or through commercially available conversion tools. The hosted system must:
4.2.3.1 Be established in NARA’s name;
4.2.3.2 Allow for all the transfer of all operations and maintenance and system administration activities to another Contractor within five (5) business days’ written notice from the COR; and
4.2.3.3 The system must be transferable to another cloud provider within 10 business days’ written notice from the COR.
4.2.4 The Contractor must cooperate with and assist NARA or its contractor(s) as needed to ensure an efficient and complete transfer of data in the native and/or open format (e.g. CSV, XML) as requested by NARA, from the hosted system to another system, whether cloud hosted or onsite at NARA.
4.2.5 NARA currently uses username and password authentication via Lightweight Directory Access Protocol (LDAP) that is tied to a Novell eDirectory account. This hosting service shall integrate seamlessly with NARA’s LDAP to allow for internal user authentication.
4.3 Systems Administration
4.3.1 The Contractor must ensure appropriate backup, security, and recovery of the system and its associated data. Current versions of the software must be maintained across all sites, to include patch updates or upgrades. Upon initial installation of software updates and patches, remaining facilities will be brought current within five (5) business days.
4.3.2 Systems Administration Support shall include troubleshooting of the ticketing system application and its environment including troubleshooting and evaluating the expected input and output of external software components that are tied into the ticketing application.
4.3.3 The system shall not require a dedicated, onsite, IT professional for proper operation.
4.3.4 Any updates and upgrades made by the Contractor to its ticketing product shall be made available to NARA. NARA reserves the right to incorporate enhanced functionalities or features as they become available. Any changes to the ticketing system must be made in accordance with PWS paragraph 4.4.
4.4 Change and Configuration Management Support
4.4.1 The Contractor shall attend the Change Control Board (CCB) meetings and respond to the questions as needed.
4.4.2 The Contractor shall adhere to NARA’s documented policies and procedures related to configuration management and shall follow a ticketing system Configuration Management Plan (CMP)
4.4.3 The Contractor shall follow NARA’s CM guidance, procedures, and standards to identify project configuration items (CIs) to establish, maintain, and retrieve project baselines. The Contractor shall develop and update the following documents to maintain baselines and to provide critical information about project CIs, and controlled CM work products:
4.4.4 Any other document that may be needed for the release to be deployed to production.
4.4.7 NARA will provide templates, as necessary.
4.4.8 The Contractor shall provide all appropriate Operations and Maintenance Standard Operating Procedures (SOPs) as requested by COR.
4.5 System Configuration, Installation, and Deployment
4.5.1 In the event NARA requires the deployment of current functionality to an existing site or the addition of a new site to the system, the Contractor shall perform all services necessary to configure, install, and deploy the system or particular functionalities, as directed by NARA. The COTS software must be installed, integrated and optimized with system servers/cloud environment and NARA’s IT architecture.
4.5.2 The Contractor shall develop a high level Concept of Deployment paper that describes in business terms how it will deploy the system to the business environment and integrate with existing business procedures and staff.
4.5.3 The Contractor shall conduct a pre-deployment consultation with the COR and relevant stakeholders before deploying and configuring the system at individual sites. How far in advance of deployment the meeting is held will vary according to the individual sites’ business processes, existing data, required functionality and needed user interface (UI) configurations. The consultation shall address but not be limited to:
4.5.3.1 Site readiness;
4.5.3.2 Onsite hardware delivery due dates and placement of hardware;
4.5.3.3 Site specific UI configurations;
4.5.3.4 Existing ticket categories and museum inventory; and
4.5.4 Configurations may include the re-purposing of unused data fields as needed at each site. Configurations shall also include refinements to pick lists, and user help features to support NARA data standards; defining/customizing selected pre-built queries and/or reports, and other refinements to prepare the base application for NARA system-wide use.
4.5.5 The Contractor must provide the NARA ticketing system System Owner (SO) and any other authorized staff the necessary hands-on instruction and login authorities and/or work with the SO to execute system-wide security and authority settings, and to customize screen-accessible help features to meet NARA data standards and interface requirements (including interfaces with NARA’s systems).
4.5.6 In consultation with NARA, the Contractor shall create a Deployment Plan that ensures maximum efficiency of resources necessary to execute a rapid implementation within the quality and cost constraints of this system. The plan must address the Contractor’s plan for:
4.5.6.1 Setup, configuration, and integration of the hosted system with NARA’s systems and business processes;
4.5.6.2 Installation procedures that specify how to install the new hardware and software components;
4.5.6.3 Site preparation, installation, configuration, and training for all internal users; and
4.5.6.4 Roll-back procedures for the operational environment to the installation starting point.
4.5.7 The first phase of deployment will include three (3) sites (Archives I plus a few Libraries) to allow the Contractor and NARA an opportunity to assess, collaboratively, the efficacy of the deployment, gather lessons learned, and determine the most efficient approach for completing the deployment at all sites.
4.5.8 The Contractor shall be onsite at each site that will deploy the point-of-sale system during deployment. NARA and the Contractor will review system documentation, Deployment Plan, Standard Operating Procedures (SOPs), and training materials in order to identify and complete any needed adjustments prior to further roll out of the application. Deployment and training for site who will only use the back-end for statistical reporting may be managed remotely.
4.6 System Design Updates and Deployment
4.6.1 In the event NARA requires the deployment of current functionality to an existing site or the addition of a new site to the system, the Contractor shall update the System Design Document (SDD) describing the system architecture. This document must have a diagram or diagrams, with text or textual documents that describe the diagrams. At a minimum, the SDD shall address the following:
4.6.1.1 Structure and relationships between components of the system;
4.6.1.2 System design constraints;
4.6.1.3 System human interfaces (input and output);
4.6.1.4 Interfaces with internal and external systems;
4.6.1.5 Functional requirements that the COTS product and other system components meet;
4.6.1.6 Data export (and import if relevant) mechanisms, API, or SOP as appropriate;
4.6.1.7 The level of network support required.
4.6.2 The Contractor shall facilitate peer review sessions with NARA to understand, refine and decompose the requirements, as needed, to ensure they are clear and testable. After which the Contractor shall deliver an updated Requirements Document for final approval. The Contractor shall also update the Requirement Traceability Matrix (RTM) to demonstrate the traceability between the requirements and software configuration items.
4.6.3 The system architecture shall, at a minimum, include four (4) environments to facilitate design and hosting services throughout the duration of this contract: Development environment, System Integration Test environment (SIT), Customer Acceptance Test (CAT) environment, and Production environment.
4.6.4 The Contractor shall be responsible for ensuring that these environments are available on an as needed basis to limit the operational costs of the system
4.7 Transition-Out Data Migration Support
In the event NARA replaces the system, in the future, NARA will require the Vendor to provide transition-out data migration support to NARA and a successor contractor.
4.7.1 The Contractor shall support the migration of data into any new successor system, as directed by NARA. The current system holds approximately one-hundred (100) GB of data across all the sites, including an aggregation of that data into a centralized database.
4.7.2 The Contractor shall provide NARA with a Data Mapping Document that shows alldata elements and fields based on the current schema and tables.
4.7.3 The Contractor must alert NARA to areas where legacy data will need reconfiguration, such as combined field assignments, areas where links may be unretainable, or if to the best of the Contractor’s knowledge, any data truncation, corruption, or loss is likely, and/or what follow-up manual data entry or clean-up will be needed. The Contractor is responsible for full documentation of the data quality.
4.7.4 The Contractor shall provide a Logical Data Model. The logical data model should be normalized to at least the third normal form and must contain the logical names of entities and fields (elements), their format and lengths, along with their relationships to one another.
4.7.5 The Contractor shall also provide a Physical Data Model that contains physical names of entities and fields (elements) and how that data is stored; and provide a Data Dictionary containing logical and physical names, definitions, formats, lengths, and required fields.
4.8 Training
4.8.1 The Contractor shall make refresher / new user training available online for internal users, throughout the term of the contract.
4.8.2 The Contractor shall develop and make available to all internal users a Quick Reference Guide and a comprehensive User’s Manual to include instructions for effective and efficient operation of the system.
4.8.2.1 The User’s Manual shall be made available on-line and for download and printing.
4.8.2.2 The manual shall be completed and available for use during user training and will become the property of the Government upon completion of the training class.
4.8.3 The Contractor shall update the User’s Manual and Quick Reference Guide concurrently with changes to the capabilities, functionality, and technology of the system. Updates must be provided prior to initial phase-in and go-live on subsequent deployments of free releases to the software, which result in significant changes to the software functionality.
4.8.4 The Contractor shall submit a Training Plan. The Training Plan will detail the Contractor’s approach for providing both initial and refresher/new user training to internal users. The Contractor shall provide periodic updates to the Training Plan throughout contract performance should technology or programmatic changes necessitate a revised training approach.
4.9 Changes to Site Deployments of the System and New Sites
NARA requires the Contractor to provide system configuration and setup support for the addition of point of sale (POS) or online ticketing to sites currently not using those services, as directed by NARA. In the event NARA adds a new site to the system, the Contractor shall provide all support necessary to add that site to the ticketing system.
5.0 FUNCTIONAL REQUIREMENTS
The Contractor shall ensure that the current ticketing system meets the requirements described herein.
5.1 Sales & Reservations
5.1.1 NARA requires multiple platforms to be available for customers to be able to purchase tickets and/or reserve free tickets; an onsite box office point of sale; an option for onsite kiosks at a site’s request; online through the customers’ personal computers; and online through the customers’ mobile devices. The system must be accessible on all of these four platforms and each platform shall be able to interface with all others. These platforms must be customizable depending on local site needs.
5.1.2 NARA requires the functionalities of these systems to provide each site the ability to configure the user experience and data field constraints based on each individual site’s logos, colors, sale categories, ticket prices, and other fields. Furthermore, the system shall display the available museum entry times to all users during purchase.
5.1.3 The system shall enable transactions for the customers to purchase and/or reserve tickets depending on site needs. obtain admission tickets. Each transaction shall have a unique identifier such as an order/transaction number and barcode. Each ticket shall display the ticket category (such as “senior,” “adult,” “military,” etc.) and the unique identifier number which is a barcode code. Customers shall be able to include add-on items with their ticket purchase, such as entrance to specific exhibit spaces, audio tours and brochures. The system shall have the ability to collect donations online, at the POS, and via kiosks. The system shall allow all users to purchase tickets (admissions and events) for multiple visitor categories within one transaction.
5.1.4 The system shall allow all users to apply discounts to ticket prices from sales, promotions, and memberships. The system shall allow the creation, management, and purchase of timed-entry tickets, and facilitate group sales.
5.1.5 The system shall allow internal users to alter ticket prices and apply single dates or date ranges to changes in ticket prices. Additionally, the system shall allow internal users to look up ticket sales across all platforms after purchase and be able to print the ticket and the associated barcode.
5.1.6 All sales platforms shall be able to accept and process VISA, MasterCard, Discover, and American Express credit cards, manually, and contactless payments, as needed. Additionally, the box office point of sale shall be able to accept cash or check. The system should also be able to process zero dollar transactions without requiring a credit card. Zero dollar transactions should not be submitted to the back office accounting system.
5.1.7 The system shall send an email confirmation of purchases to the customer for transactions, which are initiated by the customer online through either the customer’s personal computer or mobile device. The email confirmation shall include the order/transaction number and printable ticket with a barcode, and any other relevant text or graphics as determined by each site.
5.1.7.1 The solution shall provide the capability to automatically send batch emails with attached documents/URLs to attendees based on reservation date or other criteria.
5.1.8 The system shall enable customers to manage their reservations and/or ticket purchases online and/or at kiosks.Customers shall be able to look up their prior online ticket purchases at onsite kiosks and online using their email address and/or order/transaction number, and to print tickets with the unique identifier barcode. This function shall not require customer accounts to function.
5.1.9 The system shall allow all users the ability to make group reservations including multiple group visits in one order. Group data shall be accessible at the POS with the ability to create new orders at the POS for existing groups on future dates.
5.1.10 The system shall notify internal users of group reservations.
5.1.11 The system must be able to send email invoices and collect payment for custom bookings.
5.1.12 The system shall have the capability to have two events on one printed or electronic ticket.
5.2 Box Office Point of Sale and Ticket Check In
5.2.1 The system shall maintain a link amongst available data such as the order/transaction number, the tickets sold, customer information, method of purchase, and credit card information for all online and onsite purchases. Online ticket sale lookup shall be available by using the available data.
5.2.2 The system shall allow internal users to scan in tickets via barcode either manually or via a self-service scanner QR code.
5.2.3 The system shall enable internal users to be able to manually enter and/or edit data on all transactions, including all ticket sales with the associated order/transaction number and credit card information.
5.2.4 Internal users shall also be able to scan in promotional coupons at the Box Office point of sale.
5.2.5 The box office point of sale, onsite hardware, and user interface shall have and be optimized for touch screen.
5.2.6 The system shall provide the capability to support automated self-check in.
5.3 Option for Self- Service Kiosks
5.3.1 The system application shall include an option for deployment of onsite self-service kiosks, through application programming interface (API)s that enables customers to purchase and print tickets at the kiosk as well as find and print tickets previously purchased online. The kiosk APIs shall:
5.3.1.1 Be optimized for touch screen interface;
5.3.1.2 Enable customers to look up prior purchases by using available data such as order/transaction number or a customer’s email address or cell phone number;
5.3.1.3 Enable customers to scan in promotional coupons or enter promotional codes and apply such discounts to the transactions, as configured and approved by the internal users within the system; and
5.3.1.4 Be optimized for scanning tickets via barcode code at the kiosks.
5.3.1.5 Enable customers to make donations to the museum’s gift fund.
5.3.1.5 Enable customers to use credit cards and tap-to pay for payment and/or process zero cost reservations.
5.4 Online Sales
5.4.1 The system shall be optimized for use on web-based systems including personal computers and mobile devices (i.e., smart phones and tablets, at a minimum, both Android and iOS based) and the site will follow visual design requirements as set forth by NARA.
5.4.2 The customer interface shall be readable and usable on a variety of commercially available computers/laptops and mobile devices.
5.4.3 Updates (content, design, functionality, etc.) for online ticketing websites for each site shall be optimized for smart phone and tablet experiences (mobile web) using responsive web design (RWD), adhere to US Web Design System principles and components, and comply with Archives.gov branding and style guide, to be reviewed by NARA Web Program. Online interface must be section 508 compliant.
5.4.4 When designing the online sales platform, RWD shall be used with pinch-zoom capability enabled for mobile devices. A barcode must be transmitted to the mobile device for display at the site..
5.4.5 All online functionality shall be available through the mobile devices.
5.5 Event Scheduling, Reservations, and Resource Management
5.5.1 The system shall allow all users to register for events and purchase event tickets, across multiple platforms. To facilitate this function the system shall:
5.5.1.1 Enable users to register for an event for multiple visitor categories within one transaction;
5.5.1.2 Print event tickets; and
5.5.1.3 Assign unique identifiers for each event transaction.
5.5.2 The system shall allow internal users to scan in tickets via barcode and shall record and maintain event attendee data.
5.5.3 The system shall provide the capability for internal users to schedule an event, including creating, modifying and canceling both future and past events. The system shall enable internal users to:
5.5.3.1 Apply single dates or date ranges to events;
5.5.3.2 View events in a calendar view;
5.5.3.3 Assign a maximum number of attendees for an event; and
5.5.3.4 Send event cancellation notification to registered attendees.
5.5.4 The system shall maintain an audit history of changes for an event. Data capt100 https://www.qr-code-generator.com/blog/qr-codes-vs-barcodes/ured and reportable for events shall include, but not be limited to the following:
5.5.4.1 Description;
5.5.4.2 Room reservation;
5.5.4.3 Selecting and reserving equipment;
5.5.4.4 Maximum capacity;
5.5.4.5 List of attendees;
5.5.4.6 Customer information; and
5.5.4.7 Pricing.
5.5.5 The system shall allow internal users to manage staffing for events, including scheduling, adding, changing the staff and shifts for events.
5.5.6 The system shall enable the management (i.e. reservation, addition, changing, and deletion) of rooms by internal users, through the following functionalities:
5.5.6.1 Display of the list of rooms;
5.5.6.2 Display of the availability of rooms for reservations; and
5.5.6.3 Display of a list of available equipment by room.
5.5.7 The system shall provide the capability for internal users to input data manually and print forms and registrations for groups, workshops, tours and other site activities.
5.5.8 The system-generated forms shall contain all or a portion of the line items for events (i.e. attendee list only). The system shall provide the capability for internal users to manage and customize forms.
5.5.9 The system shall enable internal users to process deposits for room and/or resource rentals, maintain records, generate invoices, and accept payment of outstanding balances.
5.5.10 The system shall allow for the creation of private links/sites for special events such as event rentals (event info and RSVP is online but not shown on the main ticketing calendar).
5.6 Data Exporting, Reporting, and Management
5.6.1 Data Export. The system shall enable internal users to export data fields and the associated data to .doc, .docx, .xls, .xlsx, .csv, XML, .rtf and .pdf formats from individual locations and across all sites. The system shall enable users to select fields to be exported with minimal steps or keystrokes.
5.6.2 Data Reporting. The system shall enable internal users to generate reports using all data fields and the associated data, including legacy migrated data, across sites and within individual sites. The system shall enable internal users to export reports to .doc, .docx, .xls, .xlsx, .csv, XML, .rtf and .pdf formats.
5.6.2.1 The system shall generate pre-packaged (canned) reports as defined by NARA. These canned reports must be easily run on various variables without manually inputting the report name individually.
5.6.2.2 The system shall have the capability to create and generate ad-hoc reports using all data fields and associated data.
5.6.2.3 The system should have a “smart” reports function that handles multiple variables in one report such as Online Sales, credit card sales, cash sales, event sales, etc. Reports function must also be able to compile visitation data into reports by zip code, country, and state.
5.6.3 Data Management. The Data Management Plan must detail the Contractor’s technical approach for the maintenance, storage, cataloging, retrieval, segregation, back up, recovery, security, and safeguarding of all data. The Contractor shall maintain its Data Management Plan.
5.6.3.1 The plan must be updated at least annually and submitted to the COR for approval each year of contract performance.
5.6.3.2 Additionally, many factors, such as enhancements, changes to Government IT security requirements, etc. may necessitate interim updates to the Data Management Plan. The Contractor shall submit interim updates within thirty (30) days of receiving an official request, in writing, from the COR.
5.6.3.3 The Contractor shall update the data management plan to the extent necessary to reflect current system data requirements and configurations.
5.6.4 The system shall maintain an audit history of all activities performed in the system including transactions, event registration and resource (i.e. staff, and room) management, and other related data.
5.6.5 The solution shall scale to handle future data growth without major design or architectural changes.
5.7 System Interfaces
5.7.1 The system shall provide the necessary interface for the transfer of sales transaction information to the back office financial accounting system, Microsoft Dynamics Great Plains (GP).
5.7.1.1 The real-time interface must be compatible with and optimized for the Microsoft Dynamics GP Application Programming Interface (API), eConnect, and Microsoft Message Queuing (MSMQ).
5.7.1.2 The system shall only submit transactions with a financial impact to the accounting system. Zero dollar transactions should not be sent.
5.7.1.3 The system shall utilize unique order numbers across all sites or have the ability to preface the order number with the site name before sending the XML document to the accounting system.
5.7.1.4 The Contractor shall ensure that the XMLs sent should have a unique Label field that identifies the originating site and associated order number.
5.7.1.5 The system shall have the capability to send XML transactions to different database servers and databases per site.
5.7.1.6 The system shall utilize XML acknowledgements for reconciliation purposes between the provided system and Microsoft Dynamics Great Plains.
5.7.1.7 The Contractor shall maintain automated nightly alerts to notify staff if there was a failure in the external integration or if the reconciliation of orders is inconsistent.
5.7.2 The Contractor shall maintain an Interface Summary Document that identifies all interfaces in the system, providing a general characterization of each interface in terms of communicating elements, information communicated, information assurance considerations, usage characteristics, and communication formats and protocols. This information must be included as a section within the System Design Document (SDD), see PWS paragraph 4.6.1.
5.7.3 The Contractor shall provide and update Interface Control Documents (ICDs) that specify the functional and technical characteristics of each interface to fully express the technical design of each interface. The ICDs shall reference the functional elements and requirements allocated to each interface design. Each interface must be documented in a unique ICD. This information can be included as a section within the System Design Document, see PWS paragraph 4.6.1.
5.8 User Interfaces
5.8.2 NARA requires a system with a flexible and/or customizable screen interface to enable its internal users to optimize screen designs to support current, local tasks and workflows, and save screen settings for future use.
5.8.3 The system shall provide the capability for internal users to arrange the icons displayed on the admissions desk touch screen monitor, including assigning functions to icons.
5.8.4 The system shall enable internal users to add, change, or configure the following:
5.8.4.1 Ticket design;
5.8.4.2 Ticket prices;
5.8.4.3 Ticket categories (e.g. senior, adult, child), including activating ticket categories and rendering selected categories inactivated;
5.8.4.4 Date range(s) for promotions and discounts;
5.8.4.5 Sale items (e.g. brochures, audio tours);
5.8.4.6 Discounts;
5.8.4.7 Promotion categories and related discount amounts;
5.8.4.8 Promotions and related discount amounts;
5.8.4.9 Schedule events and resources (personnel, facility spaces); and
5.8.4.10 Entry times, durations, and maximum number of visitors/attendees.
5.8.5 Each site shall have its specific logo and color theme displayed for all users. The logo and color theme for each site will be furnished by the COR, post award.
5.8.6 The Contractor shall include up to five (5) optional fields in the database for later configuration by NARA.
5.9 Search and Browse
5.9.1 The system shall provide the internal user the ability to browse and search keyword and/or dates across the database and within fields for:
5.9.1.1 Promotional discounts, including current and past discounts;
5.9.1.2 Individual ticket orders;
5.9.1.3 Group reservations; and
5.9.1.4 Events, by date, time, program, name, attendees, and assigned resources (e.g. personnel, facility space, and equipment).
5.9.2 The system shall provide all users the ability to search and print results by date; order/transaction number and by email address; or by a combination of a customer’s first name, last name, and street address.
5.9.3 The system shall provide internal users the ability to print search results to .doc, .docx, .xls, .xlsx, .csv, .mdb, XML, .rtf and .pdf formats.
5.9.4 The system shall return a message to all users when search results are not found and allow them to try again.
5.10 FINANCIAL PROCESSING STANDARDS
5.10.1 The Contractor shall process credit cards through the Department of Treasury’s Card Acquiring Service (CAS) with NARA being the Merchant of Record.
5.10.2 Each site shall have a separate NARA-owned Merchant ID (as appropriate), which will be provided by the CAS under the coordination and direction of NARA.
5.10.3 The Contractor shall abide by all card-processing rules as directed and issued by the CAS.
5.10.4 The system shall comply with all payment processing requirements from the Department of Treasury and NARA's cross-service accounting provider the Bureau of the Fiscal Service, which includes but is not limited to:
5.10.4.1 Receipts shall be generated for all transactions and shall adhere to all required data elements printed on the receipts;
5.10.4.2 All transactions shall be logged within the application with the user be linked to each transaction processed by that user;
5.10.4.3 Enable internal users to reconcile all daily transactions by user, payment amount and payment type;
5.10.4.4 Enable internal users ability to run ad-hoc transaction reports, which include the payment date, transaction total, payment amount, and payment type, by a given date or date range to be used for auditing purposes; and
5.10.4.5 The system shall track and be able to report on any transaction cancellations, voids, returns, refunds or…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .