the attached request for systems integration services is open to

The attached Request for Systems Integration Services is open to entities that have entered into Citywide Systems Integration Services master agreements with DoITT.

The City of New York

Department of Information Technology & Telecommunications

Request for Systems Integration Services

For

311 Customer Service Management System Replacement and Re-Architecture Project

4/28/2015

ehines

Typewritten Text

ehines

Typewritten Text

Department of Information Technology & Telecommunications Request for Systems Integration Services 4/28/15

Page 2

Table of Contents

1 PROJECT TITLE ................................................................................................................ 3

2 PROJECT INTRODUCTION ................................................................................................ 3

3 BACKGROUND AND CURRENT STATE .............................................................................. 7

4 BUSINESS REQUIREMENTS ............................................................................................ 13

5 TECHNICAL REQUIREMENTS .......................................................................................... 23

6 PROJECT TIMELINE ........................................................................................................ 31

7 PROJECT ORGANIZATION .............................................................................................. 32

8 SERVICES REQUIRED ..................................................................................................... 34

9 CONTRACTOR SELECTION AND ASSIGNMENT TIMELINE................................................. 40

10 GLOSSARY ................................................................................................................. 42


Page 3

1 Project Title 311 Customer Service Management System Replacement and Re-Architecture.

2 Project Introduction The following sections introduce the project, and provide background and scope of services being requested. Expected outcomes and results after solution implementation are also described.

2.1 Overview

The City of New York (“City”), through the Department of Information Technology &

Telecommunications (“DoITT”) and the 311 Customer Service Center (“NYC 311”), is seeking a systems

integrator with extensive contact center experience to support the replacement and re-architecture of

the City of New York’s 311 incident-oriented Customer Service Management System (“CSMS”) with a

more customer-centric, cost-effective, and extensible system that offers all of the functions of a

Customer Relationship Management System (“CRM”) required to organize customer data and facilitate

communications between City staff and customers through all channels. Though the current CSMS

largely supports the minimum requirements of the day-to-day business operations of NYC 311 and the

correspondence work of other city agencies, the technology stack and software is highly customized

and offers limited expandability and scalability for new initiatives or high-volume scenarios. The City

seeks a new solution (“System”) that will be fully scalable, leverage a rich CRM feature set, and integrate

seamlessly with other City applications that support the City’s customer service work. The System will

offer robust customer service capabilities that enable customers and agencies to quickly and easily

engage with the City when, where and how they chose. The solution will deliver greatly enhanced

content management that allows NYC 311 to manage and update content rapidly and efficiently. Finally,

the System will enable NYC 311 to offer new APIs to support external development, distribution and

innovation.

The system integrator (“SI” or “Contractor”) will be responsible for submitting responses that address the goals and requirements described in this RFS and its attachments and appendices. The system integrator must propose using one of the following methods:

1. Submit one (1) proposal for a cloud solution only. (*) 2. Submit one (1) proposal for an on-premise solution only. (*) 3. Submit two (2) separate proposals, one for a cloud solution and another for an on-premise

solution.


Page 4

(*) The “on-premise” or “cloud” is dictated by the location of the on-line 311 system. For example, if the on-line 311 system is installed in the cloud, then the solution is “cloud-based”, regardless if the content management tool is installed on-premise or in the cloud. Similarly, in an “on-premise” solution, the on-line 311 system is installed on-premise.

Each solution, cloud and on-premise, will be evaluated as a separate proposal, according to section 9.2 of this RFS. Responders will not be awarded a contract in more than one solution.

Cloud-based solutions will require the use of an encryption tool that will enable the City to hold the encryption key.

2.2 Project Goals

This project will deliver a System that is:

• Customer-centric – Customers can manage profiles and preferences to streamline and enhance

their experience, and content, services and interactions deliver an optimal customer experience.

• Highly accessible – Customers can access information and services through their channel of

choice.

• Highly available – A responsive, high performance System that supports all customer activities

at all times and at all volumes through highly scalable architecture and near zero required

downtime and contingency periods.

• Easily extensible – A flexible platform using out-of-the-box functionality so that future

enhancements can be achieved in a timely, cost-efficient way with minimal coding. In addition,

the proposed solution should be able to support non-311 business functions.

• Straightforward to support - Enhancements and modifications administered in a single venue

extend across channels. Content management work is both enhanced and simplified.

• Open for innovation – Offers APIs, including enabling third party submission and tracking of

customer requests.

• Ease of use – Provide a mobile-responsive and an intuitive user interface across all channels

(web, mobile and Call Center), which can be used with minimal or no training.

• Track, report on and analyze customer behavior - implement new / leverage existing tools that

capture and provide the ability to report on customer behavior.


Page 5

The City uses a DoITT hybrid project methodology and looks for a vendor with experience managing

projects successfully using this methodology. For more information about the DoITT project

methodology, please visit: http://www.nyc.gov/html/nycproject/html/home/home.shtml.

2.3 Project Scope

The scope of the project is to replace the existing CSMS with a fully functional system that addresses the

elements contained in this RFS. The scope includes implementation of customer relationship

management functionality, API offerings, and other new elements as well as support for the city’s

current customer service offerings and integrations with City agency systems. In regards to content

management, the City prefers to leverage the existing TeamSite tool, or to have the content

functionality built within the new system. If a different solution is proposed, the System Integrator

should highlight its benefits vs. the solutions discussed in Section 2.1 of this RFS.

DoITT seeks a qualified vendor to provide system integrator services for the re-architecture and

implementation of the system. During the project, it is required that the systems integrator (“SI” or

“Contractor”) will follow industry standards for Systems Development Lifecycle processes. In doing so,

the Contractor will be responsible for the work efforts categorized in Table 1 below.

The City requires that the work is delivered in two phases: • Phase 1 delivers a “fully functional” prototype of a subset of the overall scope. The subset will

be fully defined upon the vendor selection. As an example, the subset may consist of implementing the end-to-end functionality of a one complaint type (“construction noise”), or of a category of related complaints (“noise”). Phase 1 will also serve as a “stage-gate” process. Specifically, its successful delivery against project objectives (scope / schedule / cost / quality) will commence Phase 2 of work.

• Phase 2 consists of delivering the remaining project scope.

http://www.nyc.gov/html/nycproject/html/home/home.shtml


Page 6

Table 1 (“Contractor Work Efforts by Category")

Project Planning and Management

Analysis, Requirements Gathering and Design

Architecture, Development and Configuration

Testing Training and Documentation

Maintenance and Support

• Project Planning • Project

Management • Subcontractor

Management and Coordination

• Change Management

• Risk Management and Mitigation

• Project Reporting • Environment

Preparation and Management

• Transition Management

• Business Analysis • Requirements

Gathering and Validation

• Detailed Functional and Technical Design Specifications

• User Experience Design

• Application Architecture, Development and Configuration

• Reports Development

• Data Model Design and Development

• Data Cleansing and Data Migration

• Integration Services • System compliance

with city’s IT security and privacy policies (*)

• Test Plans, Test Scenarios, Test Scripts

• Functional Testing • End-to-End

Testing with all Integrated Systems

• User Acceptance Testing.

• Performance and Stress Testing

• Training plan and materials

• Knowledge transfer plan

• User and System documentation (including Service Desk scripts, Run books, Standard Operating Procedures)

• “Train the Trainer” training

• Administrator training • Agency User training

• Implementation and rollout

• Post-production support

• Maintenance and Support Services

• Warranty

The contractor will also be responsible for providing reports and Communications, as required by the City. (*) Compliance with security and privacy policies involve activities throughout the project life cycle and require early involvement and tight cooperation with the DoITT security group. The actual security-related project activities will be detailed in the project plan. Data security and privacy measures should include, but not be limited to ensuring the encryption of data at rest and in transit, providing role-based access to the application data and objects, and the use of a tool to ensure that the City manages the encryption keys. For additional details, please review http://www.nyc.gov/html/doitt/html/business/security.shtml and “Attachment H - DoITT Technology Standards”, which details the City’s data classification, encryption, identity, and security architecture standards, as well as the security accreditation process. As part of the RFS response, the contractor is expected to provide a recommendation on how to best achieve the City’s requirements and standards around data security and privacy.

http://www.nyc.gov/html/doitt/html/business/security.shtml


Page 7

3 Background and Current State This section contains background information, an overview of NYC 311 and features of the current CSMS that are part of the project scope.

3.1 Background and Current State Overview

The current CSMS is built on Oracle’s Siebel CRM software and was launched with the 311 Call Center in 2003. The CSMS initial deployment was designed to support customer inquiries and requests received through the 311 Call Center only, with no support for other channels. In addition, certain capabilities customarily found in CRMs, such as customer profile management and correspondence tracking, were disabled as there were no foreseeable plans to use them.

Since 2003, there have been a number of key enhancements and many incremental changes, including addition and modification of customer request types, expansion to the web and mobile channels, reactivation of correspondence functionality and integrations to a number of agency systems (see Attachment C – NYC_311 System_ RFS_Integration Requirements). While this expansion has improved customer service, it has resulted in a highly customized and complex solution that is burdensome to modify and support.

To this point, it is important to note that the current 311 solution is made up of multiple, distinct and different applications for each channel. As mentioned, the Call Center application is based on Siebel. 311 Online is a custom web application that leverages the data stored in the Siebel application. It is not mobile friendly. The 311 mobile application is a separate set of native iOS and Android applications. Texting is handled through a separate third-party provider. Our goal going forward, as much as it is practical, is to have application and content changes made once and then automatically reflected in the system and available in multiple channels (e.g. 311 Call Center, online, etc.)

3.2 Existing Service Channels

The City’s CSMS currently supports 311 services offered through the call center, web and mobile. Through these channels, customers can generally get status on Citywide conditions such as parking rules, make inquiries and receive information, report and track an incident or complaint, and be directed to another government entity that is better served to meet their needs. Table 2 below shows interaction statistics for the call center and web channels.

Table 2: Customer Interaction Statistics

Channel Date introduced

2014 Interactions Daily Interactions Percentage

Call Center 2003 20,870,131 57,178 75% Web 2009 6,526,249 17,880 23% Mobile 2012 536,965 1,471 2%


Page 8

Total 27,933,345 76,530 100% The CSMS also supports customer service activities by City Hall and City agencies through NYC.gov web forms and correspondence functions.

311 Call Center 3.2.1

The 311 Call Center was established in 2003 to provide customers with a single point of contact for accessing non-emergency City government information and services. The Call Center is available 24 hours a day, 365 days a year and offers service in nearly 180 languages. Since launch, the Call Center has received more than 185 million calls.

The 311 Call Center is a standard inbound customer service call center operation with approximately 450 seats in two locations. The Call Center receives on average 50,000 calls per day, of which about 25,000 are handled by Customer Service Representatives (“CSR”). The remainders are self-serviced within the Interactive Voice Response (IVR) system. The 311 Call Center operation is unusual in the breadth of topics covered and the limited discretion given to CSRs. The Call Center has content on over 3,000 topics, and CSRs are directed on call handling by the topic content.

The CSMS is the primary tool used by 311 CSRs. The application is used to track incoming calls, provide information and as an intake tool for customer requests resolved by specific City Agencies. In addition to the CSMS, the Call Center uses agency websites and legacy applications to service customers, and an array of tools to handle support functions such as telephony, workforce management, quality assurance, training, and CSR reference and support. For this project, required integration with Call Center tools and technologies will primarily be in the telephony area.

By calling 311, Customers can:

• Hear a broadcast recording that provides information on top inquiries such as alternate side parking status and holiday closures

• Access information and/or be routed internally or to another organization through a Natural Language Understanding (NLU) IVR system

• Receive information to resolve an inquiry • Receive a transfer to the appropriate servicing agency or entity • Submit a service request to report an incident or condition • Check the status of a service request

Web Channel 3.2.2

311 Online (http://www1.nyc.gov/apps/311/) offers much of the same functionality as the 311 Call Center, allowing Customers to:

• Search the knowledgebase • Quickly access top requests

http://www1.nyc.gov/apps/311/


Page 9

• View status of citywide daily attributes (e.g. alternate side parking rules) • Submit a service request to report an incident or condition • Check the status of a service request • Obtain information specific to an address (e.g. trash collection schedule)

311 Online is tightly integrated within NYC.gov and content is shared across both sites.

Mobile 3.2.3

The 311 Mobile App is a smart-phone application available on the Android and iPhone platforms. The mobile app allows customers to:

• View status of citywide daily attributes (e.g. alternate side parking rules) • Submit a service request for a limited set of conditions • Track the status of a service request • Maintain limited profile information

Text, Chat, and Social Media 3.2.4

In the last several years 311 has expanded into new channels that are serviced outside of the CSMS. While 311 currently has pilot projects providing customer service through text, chat and social media, these channels have no integration with CSMS and build out is not included in the scope of this project. As the City does plan to use the new System to offer these and other services in future, this implementation should not prevent future deployment to these channels.

3.3 311 Service Requests

A 311 Service Request (SR) is a complaint or request for service submitted by a 311 user (Customer or CSR) and resolved by a City agency. Service Requests:

• Comprise specific information that describes a particular type of incident or condition • Identify the location of the incident or condition • May contain customer information, which may be required or optional • May contain other information based on specific agency need. Please note that in a limited

number of cases, this information may be of confidential nature, such as Social Security Number All 311 SRs are given a unique Service Request number upon submission to CSMS. Customers use this number to check the status of their request through any 311 channel.

The CSMS currently offers 39 different Service Request forms. The forms were customized to the business and operational needs of different City agencies but they almost all share the following common principles:


Page 10

• Information is collected and ordered in: incident/condition description, incident/condition location, customer information

• Complaint types drive the population of other fields as well as the workflow rules to route the request

• The information provided by the Customer (directly or via CSR) cannot be updated after the SR is submitted

• Every SR must have a resolution action before it can be closed

For more information on the Service Request process, refer to Appendix I: 311 Service Request Primer. Appendix K provides the workflows for current Call Center- and Service Request-related processes. Appendix J provides a list of the forms (templates) that are being currently in use. Please note that a single form may accommodate multiple complaint types.

3.4 311 Knowledge Management

The majority of the content available in the CSMS and 311 Online is managed using the HP TeamSite content management application (“TeamSite”). There are currently more than 8,300 pieces of content maintained in TeamSite. The content change process, data and attributes – each impacting how the CSMS and 311 Online presents content – are also managed through TeamSite.

NYC 311’s Agency Relations team works with its City agency partners to develop content for the CSMS and 311 Online. In collaboration with the Content Management team, NYC 311’s Agency Analysts publish the content using TeamSite.

TeamSite publishes content to the CSMS and the web channel via a workflow. Content editors can choose to publish using either the approval workflow (where changes are reviewed first before being published to the relevant production environments), or using the emergency workflow (where content is posted in real-time to the environments specified).

In TeamSite, content is managed in two ways:

• Content can be created and modified within the TeamSite tool • Content can be exported and bulk-loaded by using spreadsheets for large updates.

Additionally, TeamSite is used to manage content changes and posts to the various CSMS environments (i.e., production, staging, development, training, and test).

Currently, the data model in TeamSite is designed around the data model required by the Siebel implementation.

Certain content that is published online by TeamSite is made available through 311 Content API. Please refer to http://www1.nyc.gov/nyc-resources/service/979/311-content-api for more information. The data in this API is used by NYC.gov and other applications.

http://www1.nyc.gov/nyc-resources/service/979/311-content-api


Page 11

3.5 Electronic Service Request Management (eSRM) Forms

eSRM uses portal forms containing structured and unstructured data to route messages from online customers to the mayor, agency commissioners, and other senior City staff members (the “recipients”). Most recipients receive the forms as email messages sent from CSMS. The messages cover a broad range of topics:

• Complaints or compliments about Agency policy or performance • Complaints or compliments about a City employee’s work • Write-in campaigns seeking to influence the City’s position on a particular issue • Invitations to speak at a public forum • Requests to register for an upcoming seminar • Requests for City statistics or records

eSRM supports the routing of these messages to the correct Agency recipients and stores the data in its database.

Most agencies receive eSRM messages as email and have opted not to leverage CSMS to manage the response. A few agencies use CSMS to view and provide a disposition for the requests.

Agency recipients have varying Service Level Agreements (SLAs) for the messages sent via eSRM. For the correspondence sent to the mayor and agency commissioners, they are required to respond within 14 days. They may respond using phone, email, or surface mail but email is the most common mode of communication.

3.6 Correspondence

While customers may correspond with the City via 311 or eSRM, they also may also reach out via phone, email, or surface mail directly to agencies. Unlike Service Requests, which typically request an agency response to a general, public problem at a specific location (e.g. pothole, rats, etc.), correspondence is an avenue for a customer to provide specific, personal feedback (e.g. opinion on the construction of a new pedestrian plaza) or make an individual request (e.g. ask the mayor to come speak at a high school). Regardless of the nature of the correspondence, the City requires the receiving agency to provide a direct response to the Customer within 14 days.

Most agencies have a central correspondence unit for processing customer correspondence. Though each agency’s manner of handling correspondence may vary, this is the general pattern for handling from a “happy path” perspective:

• Phone or email to the customer to clarify the request as needed • Work with internal agency Subject Matter Experts (SME) to compose a response • Send a response to the customer within 14 days • Mark the correspondence as completed and close


Page 12

If all or part of the customer’s correspondence concerned a different agency, the receiving agency would redirect the correspondence to the correct one for review, response, and disposition.

The current CSMS does provide some automated support for correspondence tracking through the existing Enterprise Correspondence (EC) functionality. Figure 1 below depicts the current state architecture.

Figure 1: Current State Enterprise Correspondence Overview


Page 13

4 Business Requirements The following sections describe the future state of the new NYC 311 System and how it will enhance and modernize the City’s customer service offering.

4.1 Conceptual Business Architecture

Figure 2 below provides an overview of the specific business functionality grouped by tier that the contractor’s proposed solution must support.

Figure 2: 311 System Conceptual Business Architecture

User Interface (UI) Layer 4.1.1

The user interface (UI) layer depicts the key user groups that will interface with the System and the service channels that will be available to them. The System will enable NYC 311 CSRs, City Agencies, 311 Content Managers and Customers to conduct transactions efficiently and effectively through a mobile-responsive interface.

Application Layer 4.1.2

The application layer contains the seven core functional components of the System which provide the capabilities needed for users to request, manage and provide customer service , including:


Page 14

• Customer Management • Service Request Management • Knowledgebase and Content Management • Search • Correspondence Management • Business Intelligence (BI) & Reporting • Administration

Details on the specific functional requirements in each area as well as additional functional areas are discussed in Section 4.3.

Data Layer 4.1.3

The data layer depicts the centralized System database and its primary data components that align with the functional areas described above. The layer also includes the interfaces with other City systems and external information sources. (For a list of data interfaces reference Attachment C.)

4.2 User Group Descriptions

The user groups for the System are shown in Table 3.

Table 3: 311 System User Group Descriptions

System User Group Functional Responsibilities Activities Performed

NYC 311 CSR Responsible for assisting customers in the call center channel.

• Call taking • Inquiry response • SR creation • Direct fulfillment • Customer profile assistance

311 Call Center Supervisors & Managers

Responsible for supervising and supporting NYC 311 CSRs.

• Call taking • NYC 311 CSR performance

management • Call center management

311 Content Managers & Agency Analyst

Responsible for managing content for all channels.

• Information / content inputs and edits

• Content approval and publication

City Agency Staff Responsible for offering and providing services to Customers. (services and Agency Action/outcome)

• Content inputs • SR response / management • SR creation • Correspondence

management Customers A resident, business owner or visitor, • SR submission

• SR feedback


Page 15

requesting services or information from the City. A member of the public.

• Information inquiries • Correspondence submission • Profile creation and

management Administrators Business or technical users with

varying degrees of administrative rights to make business rule or technical changes to the System without coding.

• User administration • Production incident tracking

/ issue resolution • Application maintenance • Assigning levels of functional

security assigned to different business units

4.3 Functional Requirements

The future system functionality is categorized into the following sections as reflected in the Conceptual Business Architecture diagram in section 4.1:

• Customer Management • Service Request Management • Knowledgebase and Content Management • Search • Correspondence Management • BI and Reporting • Administration

Each of these sections will describe a key component of the System and provide context for the requirements definition report presented in Attachment A. In general, functionality should be identical across all three channels (Call center, Web, Mobile). While Social Media integration is currently planned for a future phase (not in the scope of this RFS), authentication via social media credentials needs to be provided for phase 1 (within the scope of this RFS).

Customer Management 4.3.1

Customer Management functions should work to provide an optimal customer experience for each customer, and provide data to the organization on customer behavior and trends. Creation, maintenance and management of customer accounts will be new for NYC 311 and is central to the City’s customer service vision. The primary goal for this new functionality is to enhance the customer experience, in particular to enable the customer to manage their own profile in the self-service channels.

The system will allow customers to create and manage profiles and set preferences to streamline Service Request submission, track requests, and receive updates.


Page 16

Service Request Management 4.3.2

As described in section 3.3, a NYC 311 Service Request (SR) is a complaint or request for service submitted by a 311 user (Customer or CSR) and handled by a City agency. We expect significant improvement to Service Request processes and management in the new System. In particular, we plan to streamline Service Request offerings and input for customers, simplify Service Request response and management for Agency users, and allow for third party Service Request input and tracking through an API offering.

These enhancements will require the support of a system architecture that is responsive to all mobile devices (including, but not limited to, iPhone, Android, and Windows) on both its front end for customers’ SR creation and on its back end for agency users’ Service Request processing and management. The System needs to provide functionality related to these phases of a request’s lifecycle:

• Creation and submission • Routing and processing • Resolution and closure

4.3.2.1 Creation and Submission A Service Request (SR) is created by filling out and submitting a SR form – either by the Customer directly or by the CSR when a Customer calls NYC 311. In general, SR forms will be consistent in format and the kind of information that is captured. However, some data fields will be pre-defaulted, required or visible depending on the SR or complaint type and the user completing the form. For example, a comments field may be available only to a CSR, but not to a Customer. Configurable business rules will need to be applied across entities within the system to enforce access limitations.

The system should have the ability to identify duplicate or potential duplicate records based on specific business criteria and enable the following actions:

• Identify and restrict submission of duplicate SRs , instead allowing a customer to “follow” the existing SR, and receive updates

• Notify the receiving agency of a potential duplicate SR In this scenario the system will allow the agency user to confirm and link the new with the original SR and allow for updates to cascade to all linked SRs.

4.3.2.2 Routing and Processing Most Service Requests are automatically assigned, routed, or have their status updated based on business-defined rules. For example:

• A new Service Request is automatically routed (assigned) to the appropriate Agency division based on the request type (e.g., a “Missing Street Sign” report will be routed to the Department of Transportation, Street Signs Unit)


Page 17

• A Service Request is closed when an Agency user changes the value of a particular field (e.g. “Resolution Action”) to a specific value

• When a Service Request has been incorrectly assigned to an agency, the system will support an agency user having the ability to flag the Service Request, and reroute back to the System or another agency for further action and rerouting

Similarly, business defined rules are employed to automatically send notifications, such as alerting a customer when the status of a SR changes. Once a SR is submitted, the information provided by the Customer will be read-only and cannot be updated. Business rules will be defined during the design of the system to meet this technical requirement in a manner that will permit agencies to action Service Requests which require information to be edited.

Some Agencies will use the System to process the SR while others will use their own system(s) (i.e. the SR information is passed from the System to an Agency system via an interface). In either case, the agency is required to respond to the SR by taking certain actions and providing corresponding updates. If processed in a different system, the resulting status from the agency action is provided back to the System via an interface (the list of system interfaces is provided in Attachment C).

For certain Service Request types customers may add a comment to their open Service Requests (e.g. “I found the wallet I thought I lost in the taxi.”). The System should indicate to the Agency that the comment has been submitted. Action taken in response to such comments is at the agency’s discretion.

4.3.2.3 Resolution and Closure Agency users generally close a Service Request by updating the Resolution Action, however manual closure may be necessary as an option. When a Service Request is closed an automated notification will be sent to the customers using their preferred contact method. The closure notification will contain a feedback survey the customer may complete. Based on that feedback and the Service Request type, the customer may be given the option to resubmit a Service Request for the same condition.

Knowledgebase and Content Management 4.3.3

NYC 311 uses a content management and knowledgebase article system to address customer inquiries and requests. We expect the knowledgebase and content to be transformed in the new System, driven by both the consolidation of content records for use across all channels and by redesign of the content model to support optimal customer experience in the new toolset. The SI is going to be accountable for implementing this model in the new system and the selected content management solution. Additionally, the SI will be responsible for building any content management related workflow functionality changes. Different clients, such as CSRs will have different rights, controlled by the system’s role-based access.

The content in the knowledgebase will be updated and maintained by 311 content management staff in collaboration with City agencies. Designated users can initiate content creation requests and facilitate the editing of existing content.


Page 18

The content within the System drives the outcome available to the user on each topic. While there is a large array of topics covered by 311, from birth certificates to dead animals, there are a limited set of outcomes that can be executed. The primary outcomes available are:

• Information provision, meaning the inquiry is resolved with information (e.g., citywide rent

increase information) • Transfer/referral, meaning the inquiry is directed to another entity for resolution (e.g., civil

service exam information). Note that the “transfer” outcome execution is channel specific, meaning it will be a phone transfer in the call center, and a link to another entity’s website on the web

• Service Request creation and submission

Each topic, through the content record, is set with the appropriate outcome, leaving the user with no discretion on the topic resolution. Users may choose within bundled topics, for example, “order a birth certificate online or by phone”; they may also choose between topics, such as “residential vs. commercial noise”, but a user cannot choose an outcome outside what is offered for that topic. This functionality is currently achieved through interaction between information stored on the content record and functions within the CSMS. The new System will need to maintain this core function.

The System will enable content to be quickly and efficiently manipulated to reflect state changes across the city, such as parking rule suspension due to snow or the annual planned opening of outdoor City pools.

Additionally, the knowledgebase will have the following basic capabilities and features:

• Import and export content • Search within knowledgebase executed by internal staff/content team/agency users • Configure user roles and permissions for content access, creation, and editing • Support approval workflows for content creation and editing • Configure content publish and expiration dates. For example, content relevant to beach

schedule during the summer season • Support different content lifecycles (e.g. Draft, Ready for Review, Final) • Provide content versioning capabilities and allow access to prior versions • Support content tagging (i.e. metadata and keywords) capability • Publish content to multiple repositories (e.g. for aggregation with content from other

applications, such as NYC.gov for the web channel) • Store content in a consistently organized fashion representative of the data model

Search 4.3.4

The search features will include:

• Searching the 311 content


Page 19

• Conducting a search of City sites such as clinics and parks by proximity and other factors • Enabling a lookup (search) of City assets, e.g. identifying a taxi by the medallion number • Filtering the search results based on various data elements, including content type, user role

(e.g. Customer vs. CSR), etc. • Providing the means to prioritize the search results by channel; prioritization methods should

include defining custom prioritization algorithms (e.g. based on weighting different fields) • Provide predictive/intelligent search capabilities.

Correspondence Management 4.3.5

As described in Section 3.6, the CSMS supports customer access to government services via correspondence. Each year, approximately a million messages are sent to the City via correspondence. The System will support a customer-centric solution for correspondence management that provides functionality related to these aspects of correspondence:

• Creation and Submission • Routing • Customer/Case Research • Resolution and Closure • Reporting

The System must be flexible enough to accommodate varying agency processes while meeting the needs of core correspondence management functionality.

4.3.5.1 Creation and Submission Customers correspond with the City via a variety of channels and formats on a multitude of topics. The System needs to support the existing inbound correspondence channels:

• Phone (311 or directly to agency) • Email • Surface mail • Fax • Web

Correspondence is organized by topic and sub-topic. The System must store these topics in a way that enables intuitive end-user selection, topic-driven workflows, search/filtering and easy additions/modifications.

Wherever possible, submissions will result in the appropriate records created in the System, including, but not limited to customers, cases, correspondence, and attachments. The System will need to have to the ability to identify whether a customer is a new or existing customer, create a new customer entity record if needed, establish a new case record if needed or link the correspondence activity to an existing


Page 20

customer and/or case. The System also will be required to integrate with the City’s GIS system to collect and store geo-coding for customer addresses.

To the extent possible, user-entered information will automatically populate the correct data fields in the system (e.g. web form data, email metadata, data entered by 311 CSRs) in order to optimize customer relationship management and business reporting.

4.3.5.2 Routing and Processing Most customers will correspond directly with the City, without the aid of a 311 CSR. Some of these customers will address their correspondence to a particular person and agency. Other customers will wish to correspond with the City about a particular topic but they won’t know to whom they should direct their comments. Both types of customers will need to receive routing support from the System to ensure that their feedback is directed to the correct place. Likewise, in the event a customer sends the comment to the wrong person or agency, the System will need to support its reassignment and/or re-routing to the correct person and agency.

In general, the System must support the processing and management of correspondence with business rules and workflows that consider the channel, requestor, topic/sub-topic, status and time passed. Escalations and the need for internal approvals will be triggered by user actions on correspondence records.

4.3.5.3 Response and Closure As discussed in Section 3.6, City agencies are required to respond to all customer correspondence within 14 days. The System will need to support this requirement with functionality allowing for the efficient assignment, escalation, response, and disposition of all correspondence and associated cases. Further, it will need to allow for the exchange of documents and media files with customers. It will be important to support tracking and auditing of all these activities for internal workforce management and external KPI reporting.

Also, since most agency staff will use Microsoft Outlook to respond to correspondence, the System will need to integrate with Microsoft Outlook to support conversion of Outlook and Office 365 Online email and tasks into system records. The System will support the use of email and letter templates for the purpose of standardizing responses per Cityhall requirements. Multiple users may need to collaborate on responses. Therefore, the System must support a drafting, editing and approval process for responses.

The closure of a correspondence record can be manually triggered or automated based on topic. Once closed, the fields cannot be edited although other actions may be allowed (e.g. link a duplicate request, add an attachment, etc.).


Page 21

4.3.5.4 Reporting The System must support the loading of all correspondence data into the Citywide Performance Reporting (CPR) application. NYC agencies use CPR to report on their correspondence volumes and performance (i.e. ability to meet SLA) via dashboards and reports.

BI & Reporting 4.3.6

The system must have the ability to produce a wide variety of Business Intelligence (BI) and reporting content. This content is aggregated and culled from data stored in the system (e.g. customer data, SLA data, KPI data, etc.) and loaded into the CPR tool. CPR is hosted in an integrated system called City Share. The integration between the new system and City Share will be a continuing interface for reporting within the future system. The included reporting types are aggregate reports, KPI reports. (See Attachment C integrations)

BI and Reporting content must be timely and configurable into data sets appropriate for the different types of users making the queries. The following types of reports will be designed and utilized:

• Operational Reports • Analytical Reports (CPR) • New York City Legal Compliance Reports: address the needs of the legal department. For

example, the legal department may request information about Service Requests or correspondence based on a Geo-Coordinate within a one mile radius from an intersection within a specified time frame of 10 years

• Ad Hoc Reports: advanced search query reporting based on filters

Administration 4.3.7

Administrators will have the ability to configure components within the system without the use of custom coding. The administrators will have the capability to design forms, system views, processes and workflows within the system. System administrators will also be responsible for the delegation of user credentials, business units, and security roles.

The following is a list of administrative functionality which will be included in the system.

• Creation of User roles within the system • Configuration of users within skill groups • Configuration of users to have limited or restrictive security access to records • Creation of system wide organizational views • Create alerts and reference content within the new system

For security purposes, system users are classified as either internal or external. Internal security will determine which system functions City users may access. External Security will be managed through the portal (ADX).


Page 22

Mobile 4.3.8

The system should employ a mobile-responsive architecture. The Mobile platform should:

• Offer submission of all Service Request types • Make content available through Search • Offer Site Finder function (See Attachment A) • Integrate with the City’s Geocoding Service

Note that a 311 mobile application is currently in use. The proposed mobile solution must either utilize or replace the existing functionality.

IVR, Telephony and Call Handling 4.3.9

The Call Center interface will be redesigned in the new System to support enhanced customer service functions, such as customer profiles, and to maximize efficiency in call handling. The functionality described below applies only to the Call Center Channel.

4.3.9.1 IVR/NLU The System will interface with the NYC 311 Natural Language Understanding (“NLU”) IVR solution, primarily to utilize information provided by the customer within NLU.

4.3.9.2 Telephony Computer telephony integration (CTI) functions will need to be supported and integrated with the System. These will be standard call center functions that support efficient call handling, including:

• Log in and log off of phone • Notify system that CSR is ready or not ready to take a call • Release/hang up • Place call on hold • Resume Call • Transfer Call • Retrieve phone call from failed transfer • Conference call (e.g. , to 911 or supervisor)

Additional CTI functionality may be suggested by the System Integrator and may be included based on a cost-benefit analysis. System should be able to combine CTI and NLU data to perform call center functions.

4.3.9.3 Call Handling The NYC 311 Call Center has standard processes for each step of call handling, including greeting, probing to determine customer inquiry, searching content, inquiry handling and resolution, and closing. Additionally, there are case-based processes such as 911 transfer, engagement of Language Line (interpretation services) support, and escalation to a supervisor. The System should support all required


Page 23

processes. Additionally, all action taken by the CSR should be logged for quality assurance and data mining purposes.

The system will also support the NYC 311 CSR “Call Wrap Up” process, which provides the agent the means to send the Customer a follow up email or text. This communication will provide the customer with content from the knowledgebase, or links to such content or documents, which address the customer inquiry.

Language Support 4.3.10

The System must support display functionality in 6 languages. Per the executive order 120 City Language Access Policy (see: http://www.nyc.gov/html/imm/html/eoll/eo120.shtml)

5 Technical Requirements The system integrator (“SI” or “Contractor”) will be responsible for proposing and submitting responses using one of the methods outlined in Section 2.1 – Overview.

The solution needs to fulfill the functional and technical requirements set forth in this request.

This section will outline: • Current technical landscape overview • Core future system capabilities • Technical requirements

5.1 Current Technical Landscape Overview

This section contains an overview of the current CRM and integrated technical landscape. Table 4 outlines the major software components comprising the CRM architecture:

Table 4: CRM Ecosystem Major Supporting Software

Software Functional Responsibilities

Siebel Public Sector (v 7.8.2.16 QF5)

Primary Customer Service Management System Application framework to support 311 call center data activities and Enterprise Correspondence.

Genesys Server (v 7.6) Genesys Application Information framework integrates the Siebel application with the telephony environment to provide CTI integration to the end users.

Symposium Call Center Sever Symposium Call Center Server provides Automated Call


Page 24

Distribution (ACD) capabilities; it also integrates with the CTI middleware and the telephone switch (PBX).

HP TeamSite, LiveSite & OpenDeploy 7.3.2

TeamSite is a content management tool that maintains and manages the 311 Knowledgebase. LiveSite is a rendering tool that NYC.gov/311 is built upon. OpenDeploy is a tool used to publish certain content to the web channel.

WebLogic (v10.3.x) App Server used by NYC.gov and 311 Online

Oracle HTTP Server 11g R1 Web Server used by NYC.gov and 311 Online

Oracle Database 11g Relational Database used by NYC.gov and 311 Online

WebSphere MQ (IBM Message Broker is 6.0.0.3 IBM MQSeries 6.0.2.0)

MQ is used by NYC DataShare, an application framework that supports Enterprise Application Integration data activities. DataShare is a gateway to exchange information with NYC government Agencies.

Oracle Business Intelligence Enterprise Edition (v 10.1.3.4.1

Oracle 10g)

Analytics is the Business Intelligence system that currently consolidates and stores service transaction information from 311 and various Mayoral agencies.

Informatica (v 9.1 with Hotfix 3)

Primary tool for Extract, Transform Load (ETL) jobs that extract data out and import data into CRM.

GIS Application Information GIS is a Location Administration System used for updating, locating address information.

The current CSMS and associated elements are hosted on-premise within DoITT. Integrations are currently completed as a mix of batch jobs (sFTP, ETL, email or HTTP etc.) and use of the City’s DataShare platform that enables asynchronous XML messaging over MQ.

The following figure represents the current state at a high level.


Page 25

Figure 3: CRM Current State Elements


Page 26

5.2 Other Technical Landscape Considerations

DataShare 5.2.1

DataShare is a DoITT City-wide platform designed to facilitate, streamline, and standardize interagency data sharing. DoITT is strongly encouraging the adoption of the DataShare platform by all agencies. DataShare currently facilitates data sharing across 42 different agencies supporting various initiatives such as NYC 311, HHS Connect, NYC Business Express, Integrated Justice Project, and Data Element Exchange Program (DEEP).

The DataShare platform currently consists of components such as:

• The Enterprise Service Bus (DataShare integration message broker) integration layer provides message brokerage/routing and integration business services for City-wide Agencies, specifically:

o WebSphere Message Broker to provide routing and a reliable message transport. The Message Broker product is used to implement message flows that transport data and integrate services between applications of a providing Agency to one or more receiving Agencies and;

o WebSphere MQ for a reliable transport mechanism for the ESB over secure channels. WebSphere MQ uses a store-and-forward method, to assure delivery of data from one end point to the other.

o iWay Agency Adapter platforms for integration with legacy systems.

The data structures and interfaces are standardized on NIEM compliant XML models and WS Specifications.

The selected SI will be required to develop as many needed interfaces to external systems using the DataShare platform as possible. In the event DataShare cannot meet integration needs, the SI will be responsible for developing interfaces directly to those external systems.

NYC.gov 5.2.2

NYC.gov is the City of New York’s official and unified presence on the Internet, where anyone can obtain information about, or conduct business with, the City. When a Customer searches the information via the 311 web channel, the search result encompasses information and self-service options from both 311’s and NYC.gov’s knowledgebase (federated search). The current NYC.gov platform consists of the following:

• Operating System: Red Hat Enterprise Linux 6.0 • Web Server: Oracle HTTP Server 11g+ • Application Server: Oracle WebLogic 10.3+ • Runtime Environment: Java 1.6+ • Database: Oracle 11g • Rendering Engine: LiveSite 7.3.2


Page 27

5.3 Envisioned Technical Architecture

The selected Responder will partner with NYC311, DoITT, and the 311 Re-architecture Project Team to deliver a technical solution that fulfills the business and technical requirements set forth in this request. This section will outline:

• The core system capabilities • Security architecture • Technical requirements

Core System Capabilities 5.3.1

In order to support the business requirements of the new system, the technical solution must provide the following capabilities:

Table 5: Core System Capabilities

Capability Area

Core Capabilities

Solution Footprint • Provide web-based, mobile-friendly access for City employees ideally with zero footprint (i.e. it is not necessary to install a desktop agent for either system administrators or Call Center representatives)

• Provide web-based, mobile friendly access for approved City customers (e.g. Plan Examiner participants) ideally with zero footprint (i.e. it is not necessary to install a desktop agent)

Workflow and Business Rules

• Provide workflow management that is configurable and changeable by a business user. Capabilities need to include workload balancing and re-assignment functionality

• Support rules-driven, table driven and configured business rules • Provide business rules that are flexible, configurable and modifiable

without major re-programming and deployment efforts Content Management

• Support a flexible knowledgebase and content management that allows for the viewing and publishing of information, content and forms across multiple channels (e.g. to call takers, web and mobile channels)

Search • Enable metadata management that allows advanced auditing and search capabilities

• Deliver search capabilities across multi-channel content stores (federated search)

• Provide predictive/intelligent search capabilities Data Management • Support system-side data cleansing activities (e.g. bulk duplicate check and

geo-coding of Contact and Account records.) Retention and Access to Historical Data

• Adhere to NYC311’s data and document retention policy for NYC311 data and documents. Support e-discovery, FOIL requests, etc.

• Provide agency users with integrated access to all current and historical correspondence records.


Page 28

• Provide the means to access and report on other historical information (i.e. Service Request)

User Interface/Design Considerations

• Support user-friendly navigation and interaction features that are easy to learn by end-user

• Implement form and template management that allows for local changes and configuration

Alerts/Notifications • Enable production of reports and/or electronic notifications (including emails) which will alert users of pending and overdue work

Audit • Collect information required to support business activity monitoring • Provide field and entity-level auditing capabilities

Integration • Provide Integration services with City and external systems

Security/Identity & Access Management

• Implement identity and access management that is integrated with the City identity authentication standards

Security Architecture 5.3.2

The NYC311 system has to be available to both City users (311 users, and other City agencies) and to “external users” (Customers). The Customers will be able to access the application via multiple channels, including web, mobile and text. Therefore, it is critical to secure points of entry for the system infrastructure as well as the types of outbound communication allowed while ensuring the network integrity. In addition to aligning with the DoITT Security Architecture Standard, the 311 system must enable the following:

• Role-based Identity and Access Management (IAM) aligned with the DoITT Identity Management Strategy for external applicants, as well as City Workers.

• All interfaces between 311 technical components must use secured methods of communication that meet Citywide policies and industry best practices if “private” or “confidential” data is transmitted.

• Data must be classified based on DoITT Data Classification Policy; data needs to be classified by the owners of the data.

• The system development and test effort will incorporate the following security domains: o Network Security o Authentication and Authorization o Platform Security o Web Server Security o Database Security o Vulnerability Assessments


Page 29

The SI’s development and maintenance of the NYC311 system must follow a security-driven approach to protect the application and infrastructure from security threats, and conform to all DoITT IT Security policies and standards. While delivering the NYC 311 system, the SI must adhere to the following:

• Contractor is responsible for adhering to the guidelines, standards, IT Security policies, and best practices as published by DoITT at: http://www.nyc.gov/html/doitt/html/business/technical_vendor_resources.shtml

• SI shall surface issues, suggest options, and make recommendations to the City with regard to security, based upon the classification of application data as described in the City's Data Classification Policy.

• All staff and consulting resources provided by the SI are required to acknowledge receipt of the Citywide User Responsibilities Policy.

• SI will be required to adhere to City policies, standards, and best practices for information security, application and systems network architecture, disaster recovery, and the secure storage and transmission of data.

311 Open API 5.3.3

One of the project’s objectives is to engage the public, and boost innovation and economic development through API’s open to external developers. The vendor will be expected to support this effort through the integration of Write Open APIs and the support of the 311 Open API standard, if supported by the System architecture. This will ensure external applications like mobile are able to submit service requests and other information to the System in a uniform, standard fashion.

Open 311 Standard 5.3.4

Similar to 311 Open APIs, the vendor will be expected to adhere to the Open 311 Standard so long as it comports with the City's other functional and technical requirements. For details on the Open 311 Standard, please visit http://www.open311.org/

http://www.nyc.gov/html/doitt/html/business/technical_vendor_resources.shtml

http://www.open311.org/


Page 30

5.4 Technical Requirements

Attachment B - NYC_311 System_ RFS_Technical Requirements describes the specific technical requirements with which the proposed solution must comply. These requirements are categorized into the following sections:

• Architecture • Backup and Business Continuity • Business Rules • Capacity • Data Migration • General Technical • Knowledge Management • Mobile Services • Online Help • Performance and Reliability • Record Retention • Security • System Integration Services • User Interface / Experience • Workflow

Proposers are required to submit with their proposal(s) a completed version of Attachment B - NYC_311 System_RFS_Technical Requirements indicating how their solution complies with each requirement.

A list of integration services that will need to be operational in the System in order to go-live are included as Attachment C - NYC_311 System_ RFS_Integration Requirements.

Secondary Data Storage and Reporting Requirements 5.4.1

For the purposes of legal reporting requirements in addition to minimizing storage costs there will be a need to establish a secondary data storage solution.

The secondary data storage location would hold all historical records from the 311 system. This would require the ability to report on all attributes of all records. The secondary data storage system would ideally act as an intelligent BI reporting platform. Information about historical records should be able to be reported on using a reporting tool and exported into a tool commonly available through the City’s productivity suite, such as Microsoft Excel. Both On-Premise and Online solutions will be considered for this requirement. It is to be determined whether this secondary data storage system will need to be accessible online. Best practices in Record Management should be followed, and security should be enabled to prevent the deletion of records.


Page 31

6 Project Timeline

6.1 Project Duration

Once the vendor is selected, the expectation is that the total duration of the project from solution design and development to go-live will be 18 – 24 months.

6.2 Project Dependencies

The City has identified several potential known project dependencies, which include:

• Ensuring the appropriate level of City Agency engagement and support. • Ensuring that an environment with stable, “near production” quality code is available for

training the CSRs and City Agency Users.

The Contractor should identify any other Project dependencies in the response.


Page 32

7 Project Organization The Replacement and Re-Architecture of NYC311’s CSMS is being conceived and run by the Mayor’s Office of Operations, 311, and the Department of Information Technology and Telecommunications (DOITT) with assistance from the Technology Development Corporation. There are many other agencies and departments within the City with a stakeholder interest in this project.

7.1 Project Sponsors

• Anthony Shorris, First Deputy Mayor • Minerva Tantoco, Chief Technology Officer, Office of the Mayor • Anne Roest, Commissioner, DOITT • Mindy Tarlow, Mayor’s Office of Operations

7.2 Project Business and Technical Directors

• Joe Morrisroe, NYC311 • Donald Sunderland, Department of Information Technology and Telecommunications

(DoITT) • Steven Bezman, DOITT

7.3 Business Leads

• Chenda Fruchter, NYC311 • Emily Newman, Mayor’s Office of Operations

7.4 Project Stakeholders

In addition to the key stakeholders represented as Project Sponsors, the project’s implementation leads also must engage effectively with agency liaisons from multiple City agencies and other government entities. Specific stakeholder agencies include, but are not limited to:

• Administration for Children’s Services (ACS) • Department of Consumer Affairs (DCA) • Department of Education (DOE) • Department of Environmental Protection (DEP) • Department of Finance (DOF) • Department of Health and Mental Hygiene (DOHMH) • Department of Homeless Services (DHS) • Department of Sanitation (DSNY) • Department of Transportation (DOT) • Human Resources Administration (HRA) • New York City Police Department (NYPD)


Page 33

• Taxi and Limousine Commission (TLC)

7.5 Project Team Makeup

Project Organizational Chart 7.5.1

The 311 Re-architecture project organization is depicted below

Figure 5: 311 Project Organizational Chart

7.6 Key Roles and Responsibilities

The following table details the key project roles and responsibilities.

Table 6: Overview of Roles and Responsibilities

Project Role Responsibilities

Project Sponsors The Project Sponsors are the ultimate decision makers for the project. It is imperative that they receive timely updates to assure that the project is moving forward successfully.

Project Directors The Project Directors function as the business and technical project decision makers and will remove any barriers and champion the project.


Page 34

They will also be responsible for providing timely project status updates to the Project Sponsors.

Business Implementation Leads

The Business Implementation Leads will be the key liaisons between the Project Directors and the Key Stakeholders for all business issues regarding the project. They will also provide any necessary business support to the project.

Key Stakeholders

The stakeholders have a vested interest in this project, and must be kept informed for the duration of this effort – particularly with respect to design and operation decisions.

PM/QA Group The PM/QA group is responsible for working with the Project Director and the Project Managers to ensure that the project standards, practices and procedures are being met. In addition, the PM/QA will review all the SI deliverables to ensure an acceptable level of quality is achieved for all completed work products and deliverables. However, the formal acceptance or rejection of the work products and deliverables will be made by the Project Directors.

System Integrator Project Manager

The SI Project Manager will be responsible for managing all SI resources, and developing and maintaining the overall Project Plan. The responsibilities of the SI Project Manager will include, but are not limited to, assuming overall accountability for the quality of all services as set forth in this proposal; meeting Project goals; defining success criteria; overseeing schedule obligations; ensuring quality of all Project deliverables; and securing acceptance of deliverables from the Project. Furthermore, the SI Project Manager will be responsible for providing weekly status reports, meeting minutes and weekly time reports for its project team members.

8 Services Required

8.1 Contractor Project Roles and Responsibilities

The selected Contractor will participate as part of the Project Management team and lend appropriate subject matter expertise throughout the project. The Contactor will work with the City program management on program and project planning. The City will have the final decision-making authority for the project.


Page 35

The Contractor will be responsible for the review of the initial requirements, gathering the detailed requirements (which will be validated and approved by 311, DoITT and TDC), and the review of existing architecture and applications.

The Contractor will be responsible for activities necessary to deliver the full set of deliverables on-time and in accordance with generally accepted industry standards, best practices and DoITT’s project methodology. For details, please visit: http://www.nyc.gov/html/nycproject/html/home/home.shtml

The following table provides details on the suggested key Contractor Project roles and responsibilities. The Contractor should propose additional roles as they see fit. The City will provide a Steering Committee for overall administration as well as individualized, area-specific oversight in all areas listed below.

Table 7: Overview of Contractor Roles and Responsibilities

Project Role Responsibilities

System Integrator Project Manager

The SI Project Manager will be responsible for managing all SI resources, and developing and maintaining the overall Project Plan. The responsibilities of the SI Project Manager will include, but are not limited to, assuming overall accountability for the quality of all services as set forth in this proposal; meeting Project goals; defining success criteria; overseeing schedule obligations; ensuring quality of all Project deliverables; and securing acceptance of deliverables from the Project. Furthermore, the SI Project Manager will be responsible for providing weekly status reports, meeting minutes and weekly time reports for its project team members.

Analysis & Design The Contractor’s Analysis & Design team is responsible for detailed functional and technical design specifications and coordinating the validation of requirements designs with the City. The Contractor’s Analysis & Design team is responsible for producing project documents, including the requirements traceability matrix, business rules, and functional and technical design specifications.

User Experience Design The Contractor’s User Experience Design team is responsible for all User Interface designs and related wireframes for the development team.

Application Development The Contractor’s Application Development team is responsible for the development of technical design documents, code development, configurations and unit testing of the system code. In addition to this, all development work done must follow the City’s development standards and undergo regular review cycles.



Page 36

Quality Assurance The Contractor’s Quality Assurance team is responsible for designing test plans and testing documentation. The team is also responsible for verifying that the developed, configured functionality and capabilities match with the requirements and designs. Quality Assurance also verifies the application’s performance against the City’s performance standards.

Training The Contractor’s training team is responsible for designing a training plan including training materials. The Contractor’s training team is also responsible for conducting training sessions with City Project resources, including train the trainer sessions, training of City agencies, and training of DoITT development and support staff.

Production Support and Technical Architecture

The Contractor’s Production Support and Technical Architecture team is responsible for the day-to-day maintenance of the system, all of its environments, the support of users and resolution of Remedy tickets, and the development of minor releases.

While the City Project Team and the Contractor will perform work planning and monitoring activities collaboratively, the Contractor will be responsible for producing all deliverables described in Section 8.2 below.

The Contractor is expected to provide resources necessary to complete the following project phases and deliverables on time and within budget.

• Project Management o SI and Subcontractor Management and Coordination o Change Management o Risk Management and Mitigation o Project Reporting o Training Delivery and Knowledge Transfer o Transition Management o Contract Change Management o User and System Documentation

• Applications and Systems o Requirements Gathering, Validation and Business Analysis o Functional and Technical Design Specifications o Application Architecture, Development and Configuration o User Experience Design o Reports Development o Testing – Unit and Assembly, Integrated System, Performance, Stress, User Acceptance


Page 37

o Implementation and Rollout o Transition Management o Post-production Support o Product and Service Warranty o Maintenance and Support Services

• Data Cleansing • Data Migration • Integration Services • Training Services

o Training Plans o Training Materials

8.2 Contractor Tasks and Deliverables

The Contractor is expected to perform the tasks and deliver the work products specified on DoITT’s NYC Project Site listed and also located at http://www.nyc.gov/html/nycproject/html/home/home.shtml unless otherwise agreed upon by the City.

Table 8: Contractor Deliverables

Functional Area Deliverables

Project Management Plan and Schedule

• Project Management Plan • Program Roadmap • Project Review • Project Schedule • Risks and Issues Report • Status Report

Business Analysis • Data Dictionary • Data Definition Language (DDLs), including schemas and

relationships • Error and Message Inventory • Detailed Business Requirements • Logical and Physical design requirements • Use Cases • Workflow diagrams

User Experience Design • Annotated Wireframes • Content Inventory • Front-end Production • GUI Design • User Interaction Flows

Application Design and Development

• Bill of Materials • IT Security Accreditation, including Security Design • Migration Plan



Page 38

• Release Notes • Runbook • System Artifacts • Architecture strategy document • Logical and Technical Design

Quality Assurance • Defect Report • Test Plan • Test Progress Report • Test Report • Test Scripts • User Acceptance Test Plan

Training Services • Training Plans • Training Materials • Train the Trainer • End User Training for Agencies

8.3 Contractor Expertise Required

Contractors should include project staff with demonstrated experience in the following areas:

• Experience with similar projects In the RFS response, the contractor should detail and provide references for work performed on CRM projects of a similar size and scale, with a focus on public sector initiatives, and using the product they recommend for this project. Similarly, the contractor should highlight the relevant experience of the project team members that would be engaged for this project.

• Experience with replacement of legacy systems with multiple or complex integration points • Experience with large-scale call center integrations • Experience with business analysis and business process re-engineering for replacements of

public-sector case management systems • Experience with Agile development methodology (particularly as it pertains to user design and

use case development)

8.4 Additional Contractor Requirements

Status Reports and Rollup Statements 8.4.1The Contractor will submit to the City Project Manager a monthly roll up report that includes all services and equipment provided by the Contractor under this project for the billing period. The reports will include the project number, project title, user agency, description of work performed (indicating which project tasks are being billed for), inventory report, a detail of purchases, systems deployed, hours billed, amount billed and total charges to date on the project. The Contractor will be responsible for providing weekly status reports, meeting minutes and weekly time reports for its project team members.


Page 39

Coordination with Other Contractors and Project Owners 8.4.2The Contractor agrees to cooperate with other Contractors and assigned project owners who may be on-site; and coordinate the work required under this Agreement with the work performed by other Contractors and/or assigned City Agency personnel.

Product and Services Warranty 8.4.3

The contractor agrees to warrant their work, including any custom coding or configurations, hardware installations and any other work or services performed for a period not less than 12 months.

8.5 Content and Format of Contractor Proposal

The Contractor should submit fixed price proposal(s) (for on-premises and/or cloud-based approaches) with milestone-based payments schedule. The milestones will be determined based on vendor’s proposed implementation approach. Fixed-price proposals must show the basis for computing the total cost per deliverable including the estimated hours and associated hourly rates. The City reserves the right to request that the Responder submits both fixed price and time and materials price proposals, where appropriate. In addition to the pricing methodology requested by the City in this request, responders may submit alternative pricing proposals for consideration. The City reserves the right to select the payment approach that it believes is in the best interest of the City. The price set forth in the proposal must be inclusive of any and all expenses incurred by the Contractor in providing services, including overhead, travel, lodging or meals.

The contractors shall provide post-production support for a period of 12 months. Post-production support will be provided on a Time and Materials basis for a total amount not to exceed the proposal cost.

Responders should use the Systems Integrator Proposal Template (Attachment L), to submit their written proposals.

Responders should identify all items and services that comprise the total cost in their proposals and complete the relevant cost schedules from the list below:

a) Complete Staff Hourly Rate and Workload Estimates (Appendix F) b) Complete Miscellaneous Cost Schedules, as required (Appendix G) c) List Miscellaneous costs (Appendix G)

In addition to the above, all responses should include a breakdown of resources, duration and costs by the following components:

• Content Management • Mobile • Search • Multi-Language Support


Page 40

• Integration • All CSR Activities (e.g. Transferring a call) • Training • All Other

9 Contractor Selection and Assignment Timeline

9.1 Contractor Selection Process

The contractor will be selected via a two-stage process:

• Stage 1 consists of selecting a subset of contractors, based on the submitted RFS responses. The evaluation criteria for this stage are outlined in Section 9.2.1. The total subset of contractors will be determined at DoITT’s discretion.

• Stage 2 consists of the selected subset of contractors participating limited-scope, well-defined demo. Attachment M provides information regarding this demo. Additional details will be provided at the start of this stage. The evaluation criteria for this Stage are also outlined in Attachment M. The Contractor will be selected at the conclusion of this stage.

As mentioned in Section 2.3, the City requires that the project work is delivered in two phases: • Phase 1 delivers a “fully functional” prototype of a subset of the overall scope. The subset will

be fully defined upon the vendor selection. As an example, the subset may consist of implementing the end-to-end functionality of a one complaint type (“construction noise”), or of a category of related complaints (“noise”). Phase 1 will also serve as a “stage-gate” process. Specifically, its successful delivery against project objectives (scope / schedule / cost / quality) will commence Phase 2 of work.

• Phase 2 consists of delivering the remaining project scope.

9.2 Evaluation Criteria

Evaluation Criteria for Stage 1 of the Selection Process 9.2.1Contractor proposals will be evaluated according to the following weighted criteria:

Criteria Weight Relevant Project Experience (demonstrated quality and quantity of relevant experience)

30%

Approach and Methodology 20%

Project Organization and Staffing (quality of proposed project team) 30%


Page 41

Cost (Fees and associated charges) 20%

Total 100%

Evaluation Criteria for Stage 2 of the Selection Process 9.2.2

The evaluation criteria for this stage are outlined in Attachment M

Overall Evaluation Score (for Stage 1 and 2) of the Selection Process 9.2.3

The overall evaluation score is a weighted averages of Stage 1 and 2 scores, as shown below:

Criteria Weight Quality of the demo score (Contractor’s Stage 2 score) (*) 70%

Contractor’s Stage 1 score 30%

Total 100%

(*) Please refer to Attachment M for information on the quality of the demo scoring

9.3 Contractor Assignment Timeline

The following are the anticipated target dates for the contractor selection process.

Event Date Request for Services Sent to System Integrators April 28, 2015 Contractor Q&A Session May 12, 2015 Contractor Proposals Due June 16, 2015 Contractor Oral Presentations (Stage 1 of the Selection Process) July 14, 2015 Evaluation Committee Selection(Stage 1) August 24, 2015 Distribute Stage 2 Instructions August 31, 2015 Contractor Q&A (Stage 2) September 9, 2015 Contractor Oral Presentations (Stage 2) September 22, 2015 Evaluation Committee Selection (Stage 2) October 8, 2015 Task Order Due November 9, 2015 Estimated Contractor Start Date January 18, 2016


Page 42

10 Glossary Term Definition 311 Customer Service Center

The City service center that provides non-emergency government services to Customers through traditional call center support, web self-service, and chat. .

Agency User A city agency staff member, such as a Department of Transportation parking meter staffer, who interacts with the system in order to respond to customer requests and correspondence concerning government services.

Case Management Case management refers to the coordination of services on behalf of a Customer. Case management is a core component of the customer relationship management process. The case can link to all interactions across channels, whether email, online, short message service (SMS) / text, mail, fax, or a phone call.

Channel The mode or medium used to initiate a service request or correspondence; There are 3 fundamental channels: Call Center, 311 Website, and Mobile. Text is not a separate channel per se but leverages the Mobile channel. Social Media and Twitter are also not separate channels but fall under the “Web” category along with 311 Website.

CPR Citywide Performance Reporting – the business intelligence/analytic tool integrated with the 311 CRM and used by the City for reporting.

CTI Computer Telephony Integration is the software, hardware, and programming necessary to integrate computers and telephones so they can work together seamlessly and intelligently.

Customer Customer refers to an external customer who will access the 311 system via one of the Channels.

Customer Service Representative (NYC 311 CSR)

Call Center representatives who answer inbound telephone calls from Customers. Most 311 agents are trained to handle Tier 1 calls, and one or more Tier 2 agency skillsets.

Configuration Configuration corresponds to the ability to design the system to meet an organization’s unique needs without the use of Code.

CRM Agency A City Agency that actions its 311 Service Requests and/or correspondence directly in the 311 system


Page 43

CSMS Current Siebel-based Customer Service Management System used by the 311 Customer Service Center.

Enterprise Correspondence (EC))

Enterprise Correspondence is the functionality added to the 311 CSMS in 2010 to allow participating agencies to process and manage customer correspondence and their relationships with those correspondents.

eSRM Electronic Service Request Management (eSRM) is an application that was created to support the sending of emails from City websites to City officials. It gets backend support from 311 CSMS.

ETL Extract, Transform, Load (ETL) is a process for extracting data from a source system (database) and loading it into a target system.

IVR Integration Out of the box integration from the CRM through a computer telephony integration (CTI) or integrated voice response (IVR) system.

Knowledgebase A knowledge repository that holds all structured and unstructured information that can be searched. Customer may access this information directly via web customer service (WCS) or indirectly via a NYC 311 CSR.

LMIQ Lockheed Martin Intranet Quorum (LMIQ) is the application that City Hall uses to handle the correspondence addressed to the Mayor and to route correspondence to City agencies for response.

Mobile Data channel for service via a mobile device includes service notification and requests via mobile device or smartphone. Provides mobile Customer service applications or engagement on channels such as mobile web chat and mobile virtual assistants.

Skillset Defines the discrete skills of a CSR and the type of calls that can be routed to the agent.

Social Media Mining Harvesting of content from social networks and updating the knowledgebase with the content to allow better resolution of recurring problems across all interaction channels.

System The CSMS replacement system which will re-architect and streamline existing services and expand the Customer Service Center’s core customer service capabilities with a more robust self-service and social CRM offering.

Text / SMS Service notification and requests via mobile device or smartphone using data and an SMS channel.


Page 44

Service Request (SR) A 311 Service Request (SR) is a complaint or request for service submitted by a 311 user (Customer or CSR) and resolved by a City agency.

Service Request Management

This refers to the intake, routing and resolution of a Service Request; Service Requests can be created by a customer or submitted on behalf of a customer (by a 311 CSR or Agency); Service Requests are acted upon by the receiving agency and the resolutions communicated via status updates.

Generalist / Tier 1 The pool of NYC 311 CSRs that receives all inbound calls to the call center. Calls are distributed on a virtual “next available agent” basis to multiple sites. Approximately 90% of all call handled are serviced by Tier 1. The objective is for all NYC 311 CSRs to be trained and skilled in handling Tier 1 calls.

Specialist / Tier 2 The 311 Call Center contains many specialized functions performed only by certain CSRs. Specialists receive calls transferred from Tier 1, directly from the IVR by customer selection/routing, and from distinct non-311 phone numbers. There are approximately 30 different skill set profiles, based on schedule, skill set, topical, and other defined variables, in Tier 2.

Web Chat Web chat is an online, text-based interaction with a live agent, or a speech-based interaction with a virtual assistant. A Web chat session involves interactive, Internet-browser-based, live text interactions among NYC 311 CSRS and Customers

Web Customer Service Web customer service refers to self-service problem resolution through web-based service channel. It is a style of service process whereby Customers navigate to a website to look for information or to request information in order to resolve their own problems and answer their own questions, as opposed to calling 311 Customer Service Center for assistance.

Web-Self Service SR Ability for Customers to generate a SR on the online channel via a web form


Page 45

Attachments The following documents are provided separately: Attachment A - NYC_311 System_ RFS_Functional Requirements

Attachment B - NYC_311 System_ RFS_Technical Requirements

Attachment C - NYC_311 System_ RFS_Integration Requirements

Attachment D - Citywide Performance Reporting (CPR) Ecosystem

Attachment E - NYC 311 Operational Reports Attachment K – NYC_311 Current Process Flows

Attachment L - Proposal Template

Attachment M - 311 SI Demo

Appendices

Appendix F - Staff Hourly Rate and Workload Estimate

Appendix G - Miscellaneous Cost Schedule

Appendix I – 311 Service Request Primer

Appendix J – List of (Currently Used) Complaint Type Templates


Page 46

Appendix F: Staff Hourly Rate and Workload Estimate

Appendix F: Staff Hourly Rate and Workload Estimate

HOURLY RATES #

COMPONENT (*)

STAFF NAME LABOR CATEGORY CONTRACT $

PROPOSED $

ESTIMATED HOURS

TOTAL $

1 2 3 4 Totals: 0 $0

(*) Please use the following components: Content Management, Mobile, Search, Multi-Language Support, Integration, All CSR Activities, Training, and “All Other”

The City expects all “key personnel” identified in a Contractor’s proposal will be present at the demonstrations described in the “Contractor’s Oral Presentation” below. The City also expects “key personnel” for the selected Contractor to remain on the project to ensure continuity of knowledge. The Contractor shall not transfer or replace the project manager or other individuals designated as “key personnel” unless such transfer or replacement is at the City’s request or due to a bona fide promotion, illness, family leave, disability, termination of employment, or other circumstance beyond the Contractor’s reasonable control. Prior to any permitted transfer of “key personnel” to another position, the Contractor shall provide the City with at least thirty (30) days’ notice of such transfer. No staffing decisions regarding the addition or removal of staff will be made without the City’s consent and approval.

Labor rates must be inclusive of any and all expenses incurred by the Contractor in providing services, including overhead, travel, lodging or meals. Traveling, lodging and meals will not be reimbursed.


Page 47

Appendix G: Miscellaneous Cost Schedule

Appendix G: Miscellaneous Cost Table

All miscellaneous items other than software/hardware to be acquired by the contractor to support the proposed solution(s) described in the project proposal.

UNIT DISCOUNT

# ITEM QUANTITY ITEM DESCRIPTION COST $ % ACTUAL COST $

1 2 3 4

Total $0

Note: The City has the right to select a subset of the quoted goods and services to purchase from the Contractor. This includes, but is not limited to, deciding to purchase software and/or hardware from another source (including directly from the vendor) if the Contractor’s proposed pricing is not the most favorable option available to the City.


Page 48

Appendix I: 311 Service Request Primer

What is a Service Request?

A 311 Service Request (SR) is a complaint or request for service submitted by a 311 user (customer or agent) and resolved by a City agency.

• SRs are composed of specific information that describes a particular condition • Identifies the location of the condition • SRs may contain customer information, which may be required or optional. • Other information may be offered or required based on specific agency need.

All 311 SRs are given a unique Service Request number upon submission to Siebel. Customers use this number to check the status of their request through any 311 channel.

How are Service Requests captured?

Service Requests are offered to users via SR forms. SR forms exist in:

• Siebel (used exclusively by call center agents) • As a corresponding Universal Intake (UI) or web form (for web channel and for call center

agents) • or an agency legacy system • As a mobile app form

All subsequent information refers to Siebel and UI forms only.

A Service Request form is composed of different elements and fields to capture information; workflows route the SR to a particular agency division to process the SR within that agency. There are a host of standard form elements, such as a calendar widget to capture date/time, dropdown fields etc. that are used across all forms. There are also special tools available on specific forms (ex. Facility Finder, Building Type).

Standard SR elements

All 311 Service Requests contain a Complaint Type. Complaint Type (CT) is the principal organizing element of a Service Request, and is a standard element across SRs. While the elements of a SR are constrained by the form, they are actually determined by the Complaint Type.

• The Complaint Type determines which values will be offered on a form • The form determines which fields will be required.

There are two subsidiary fields to Complaint Type, Descriptor 1 and Descriptor 2, which contain dropdowns or Lists of Values (LOVs).


Page 49

• Descriptor 1 is constrained by Complaint Type and is used to drive routing destination workflows, customer notifications, video-picture capabilities etc.

• Descriptor 2 is constrained by Descriptor 1.

The purpose of these fields is to capture sufficient information while allowing the user to choose from a manageable list of options. All SRs contain a CT and D1; D2 is optional based on the specificity/level of detail needed by the agency.

SR Form sections

Both Siebel and web forms are broken up into sections.

• The first section, ‘WHAT’ contains the elements to identify and describe the condition or request, such as ‘Noise – Residential’ or ‘[ex]’. Generally this includes Complaint Type, Descriptors 1 +2, Complaint Details (free text field), and Date and Time of incident.

• The next section, ‘WHERE’, includes Location Type and controls and fields used to input location [Geo].

• The ‘WHO’ section allows for Customer Information to be captured.

In both Siebel and web forms, required elements from each section must be completed and, in cases, validated (as in an address), in order to move to the next section.

• The web forms have an additional final step, ‘SUBMIT’, for the user to review information and submit the form.

Pre-population of the SR Form from the service

As described above, SR Forms are particular shells within which certain elements are offered and required based on both the type of form and the Complaint Type. Population of the Complaint Type, and sometimes Descriptor 1, is driven by the content selected by the user. 311’s core content item, the Service, contains information or settings that determine the SR Form, Complaint Type, and Descriptor information that launch once the “Next Steps,” or Service Outcome, is selected within the service. In this way, selection of the service drives the creation and population of key elements of the form. This reduces the information the user needs to enter within the form, and enforces consistency across SRs.

The Service content item and all of the settings contained therein is created and managed in 311’s Content Management System (CMS), TeamSite. TeamSite integrates with Siebel to provide content loads and updates. Thus the determinations about how a form will be presented are actually set and managed in TeamSite, though the form interaction for the user happens in Siebel or web forms.

Filling out and submitting a SR Form

The user interacts with the SR Form to provide SR information, and then the user submits the form. Following submission, the user is provided with a SR#, and initial message, called the Submit Message,


Page 50

and Service Level Agreement (SLA) describing the expected next step and time to next action by the agency, respectively. The Submit Message and SLA are available on the screen for Call Center and web users, and contained in the Confirmation Email for all users providing an email address.

SR Processing by Agencies

Agencies receive SRs in Siebel or an agency legacy system. The following describes activities of Siebel agencies only.

• Agency users review and take action on individual SRs by changing the Resolution Action field. Resolution Actions indicate Agency work steps, such as ‘Scheduled for Inspection’ or ‘Condition Corrected.’

• Each Resolution Action is associated to a particular Status (e.g., Open, Closed). • Additionally, each Resolution Action has a corresponding Resolution Action Description, which is

a message for the customer conveying the status and/or expected next action. [Example]. • Lastly, Resolution Actions associated with the ‘Open’ status may update the SLA.

The Status and SLA fields are not available to be manipulated by Agency users; rather, they are driven by the Resolution Action. Resolution Actions may or may not impact Status or SLA. Resolution Actions that are associated to the “Closed” status will close the Service Request and thus do not have an associated SLA.


Page 51

Appendix J: List of (Currently Used) Complaint Type Templates

Template Name Complaint Type CDBG_Request_CCR

NYC Housing Recovery Programs CDBG_Request DCA_Customer_Concern_BT

Consumer Complaint DCA_Customer_Concern_D1 DEP_OUTFALLS Dry Weather Discharge DEP_Service_Request_NO Hazardous Material

Industrial Waste Lead Noise Sewer Maintenance Water Conservation Water Maintenance Waste Water Treatment Plant Water Quality

DEP_Service_Request Air Quality Industrial Waste Noise Sewer Maintenance Water Quality Water Conservation

DFTA_Senior_Services

Alzheimer's Care Bereavement Support Group Case Management Agency Complaint Elder Abuse Eviction HEAP Assistance Home Delivered Meal - Missed Delivery Home Delivered Meal Complaint Home Repair Housing - Low Income Senior Housing Options Legal Services Provider Complaint Noise Survey NORC Complaint SCRIE Senior Center Complaint Transportation Provider Complaint Utility Program Weatherization


Page 52

Template Name Complaint Type DOB_Inspection_Scheduling Boiler

Construction Electrical Elevator Noise Survey

DOB_Service_Request_Source Abandoned Building Adult Establishment Advertising Sign Awning/Canopy/Marquee Boiler Building Condition Building Exit Building Exterior Building Sign Building Sprinkler System Building Structure Damage Certificate of Occupancy Construction In Progress Crane Curb Cut/Driveway Debris Deck Safety Demolition DOB Posted Notice or Order Electrical Wiring Elevator Excavation Fence DOB_Service_Request

DOE_School_Maintenance School Maintenance


Page 53

Template Name Complaint Type DOHMH_Environmental_Health Animal Facility - No Permit

Asbestos Beach/Pool/Sauna Complaint Bottled Water Calorie Labeling Drinking Water Food Establishment Food Poisoning Harboring Bees/Wasps Illegal Animal Kept as Pet Illegal Animal Sold Indoor Air Quality Lifeguard Mobile Food Vendor Mold Non-Residential Heat Poison Ivy Portable Toilet Radioactive Material Rodent Smoking Standing Water Summer Camp Tattooing Trans Fat Unleashed Dog Unlicensed Dog Unsanitary Animal Facility Unsanitary Animal Pvt Property Unsanitary Pigeon Condition Window Guard X-Ray Machine/Equipment

DoITT_Cable DoITT_Public_Pay_Telephone Public Payphone Complaint DOT_Bridges_and_Highways Bridge Condition

Highway Condition Highway Sign - Damaged Highway Sign - Dangling Highway Sign - Missing Tunnel Condition

DOT_Ferry Ferry Complaint Ferry Inquiry


Page 54

Template Name Complaint Type DOT_Streets_and_Sidewalks Broken Muni Meter

Broken Parking Meter Bus Stop Shelter Complaint Bus Stop Shelter Placement Curb Condition Parking Card Public Toilet Sidewalk Condition Street Condition Street Sign - Damaged Street Sign - Dangling Street Sign - Missing

DPR_General_Intake Animal in a Park Maintenance or Facility Violation of Park Rules

DSNY_Derelict_Bike Derelict Bicycle DSNY_Derelict_Vehicles Derelict Vehicle DSNY_Lit_Request Literature Request DSNY_Service_Request Dirty Condition

Illegal Dumping Other Enforcement Recycling Enforcement Snow

DSNY_Snow_Removal Snow Removal OEM Disabled Vehicle

EDC_Service_Request Noise - Helicopter FDNY_Cust_Info_Only FDNY_Inspection_Scheduling EAP Inspection - F59

Fire Alarm - Addition Fire Alarm - Modification Fire Alarm - New System Fire Alarm - Reinspection Fire Alarm - Replacement Fire Safety Director - F58 Gas Station Discharge Lines Hazmat Storage/Use Healthcare Facilities Laboratory Micro Switch Open Flame Permit Rangehood Sidewalk Cafe Heater Sprinkler - Mechanical Standpipe - Mechanical


Page 55

Template Name Complaint Type HPD_Service_Request Appliance

Door/Window Electric Elevator Flooring/Stairs General Heat/Hot Water Outside Building Paint/Plaster Plumbing Safety Unsanitary Condition Vacant Apartment Water Leak

HRA_Rapid_Benefit_Card Benefit Card Replacement NYPD_Quality_of_Life Animal Abuse

Bike/Roller/Skate Chronic Blocked Driveway Derelict Vehicle Disorderly Youth Drinking Graffiti Homeless Encampment Illegal Fireworks Illegal Parking Noise - Commercial Noise - House of Worship Noise - Park Noise - Residential Noise - Street/Sidewalk Noise - Vehicle Non-Emergency Police Matter Panhandling Posting Advertisement Traffic Vending

Rapid_Cust_Info_Only Rapid_Service_Request_NW City Vehicle Placard Complaint Rapid_Service_Request Lead TLC_Compliment Dispatched Taxi Compliment

Taxi Compliment TLC_FHV_Complaint For Hire Vehicle Complaint TLC_Lost_and_Found Found Property

Lost Property TLC_Non_Passenger_Complaint Taxi Complaint


Page 56

Template Name Complaint Type TLC_Passenger_Complaint_Compliment Dispatched Taxi Complaint

Taxi Complaint DSNY Missed Collections Missed Collection

the attached request for systems integration services is open to

Documents