RFP N12079-1 CRM Requirements

The City of Richmond, Virginia
Customer Relationship Management (CRM) Requirements

Rating Definition
4 Standard. Is available in the current release. Software supports this requirement. No customization or
modification is required.
3 Is available with third-party application. The Offeror has established a relationship (for example, as an
OEM) with a business partner to provide this functionality, which doesn't need any customizing or work
around. Indicate the name of the application recommended and the number of installs completed.
2 Functionality is provided by the Offeror, but it requires customization. The functionality can be
accomplished with the Offeror's product, but needs customizing or a work around. Identify any areas
where modification will affect the application upgrade path.
1 Functionality is provided, but it requires customized integration with a third party. The Offeror has
established a relationship with a business partner to provide this functionality, but it needs customizing or
a work around. Identify any areas where modification will affect the application upgrade path.
0 Functionality is not provided. The software will not meet the requirement.
F Future release: The requirement will be available in a future release (indicate anticipated time of
update: month and year).
When responding to the, "Solution Supports The Requirement" on each tab, use the above ratings.
Page 1 9/22/2014
Req # Description of Requirement
Solution
Supports
Requirement
ERP Offeror Reponse Comments
(Indicate if any manual processes are required)
1.01 The system shall be capable of handling both information requests (which do not create a
corresponding work order in a departmental system) and services requests (that do create
a corresponding work order in a departmental system.) Unless specified otherwise, the term
service request refers to both information requests and service requests throughout this
requirements list.
1.02 The system shall be capable of displaying a service request (case) submission form for the
service request (case) submitter to enter the required data fields for the service request
(case) type.
1.03 The system shall be capable of accepting the upload and storage of documents and/or
images as part of the service request (case) submission form. The application shall have
the ability to attach documents to a citizen inquiry or request (e.g. pictures, scanned letters,
emails, text documents, etc.)
1.04 The system shall be capable of performing validation of the submitted data from within the
form in order to ensure data quality prior to service request (case) submission.
1.05 The system shall be capable of generating and displaying a service request (case) number
upon successful submission of a service request (case).
1.06 The system shall define fields of information as mandatory or optional, and shall be
capable of displaying and capturing different mandatory and/or optional fields for each
service request (case) type as necessary as part of the service request (case) submission
form.
1.07 The system shall be capable of capturing and displaying addresses either by direct entry
into the service request (case) submission form, or by pointing and clicking on the GIS map
display.
1.08 The system shall interface with the City's Address Verification web service in order to
validate and standardize addresses provided during the service request (case) submission
process.
1.09 The system shall provide the ability to verify and validate addresses not found within the
Citys Address Verification web service.
1.10 The system shall create service request (cases) from inquiries on demand (i.e., an
incoming call can be converted to a service request with corresponding work order(s) at any
time.)
1.11 The system shall develop, customize, and maintain multiple service request (case)
templates for different inquiry types.
1.12 The system shall develop, customize, and maintain inquiry categories for different service
request (case) types.
1.13 The system shall develop, customize and maintain multiple customer-profile templates for
different customer types.
1.14 The system shall record call activity data associated with a contact.
1.15 The system shall provide or support features to expedite data entry by 311 agents/CSRs.
Request Entry and Status Tracking
Initial Request Entry (Information Requests and Service Requests)
Page 2 9/22/2014
Solution
Supports
Requirement
1.16 The system shall automatically record date and time of service request (case) creation.
1.17 The system shall automatically record identity of the agent/CSR receiving/initiating the
service request (case).
1.18 The system shall automatically validate and populate city and state based on zip code.
1.19 The system shall provide automatic entry of customer data via field-based auto-population
(i.e., an entry in a field invokes population of a template with appropriate information).
1.20 The system shall Support automatic entry of data via field-based auto-population.
1.21 The system shall automatically assign a unique individual service request (case) number.
1.22 The system shall Display lists or menus containing multiple options for indicating category
of inquiry.
1.23 The system shall Include fields for entering customer name prefix (e.g., Mr., Mrs., Miss and
Ms.)
1.24 The system shall include fields for entering customer name suffix (e.g., III, Jr., Sr., MD or
CFA.)
1.25 The system shall include fields for request detail information that the end users define.
1.26 The system shall Display lists or menus containing multiple options for indicating outcome
of inquiry (e.g., C-Closed, O-Open, H-On Hold, Pending).
1.27 The system shall provide relevant lists of information during the creation of an inquiry
record, including lists of standard service request (case) submission forms and lists of most
frequently used service request (case) types.
1.28 The system shall provide a flag to indicate that an address is a valid address with the Citys
Address Verification Web Service when applicable.
1.29 The system shall provide the ability to enter intersections, blocks, etc as service request
locations.
1.30 The system shall provide a flag to indicate that an email address is in valid email address
format.
1.31 The system will provide the capability to route service requests either to an individual or to a
workgroup queue depending on the requirements for the specific type of request.
1.32 The system shall provide the ability for service requests to be routed to an alternate
destination, for example, when the primary servicer for the request type is on vacation.
1.33 The system shall have the ability to provide load balancing for equitable distribution of
assigned serviced requests to multiple individual work queues.
1.34 The solution may support one or more advanced service request routing techniques (e.g.,
content-based routing, location-based routing.)
Request Status Tracking and Follow-up (Information and Service Requests)
Request Routing (Information and Service Requests)
Page 3 9/22/2014
Solution
Supports
Requirement
1.35 Information requests will essentially be tracked like service requests, as many of the service
request types are actually requests for information. In cases where the CSR has access to
the information in the knowledgebase or through an interface, the CSR could open a
request, relate (read/email) the information, and close the request on the spot. In cases
where outside help was needed, the request would be forwarded to the additional
resources who will fill the request and then close the case. Either way, the system shall be
capable of handling the tracking.
1.36 The system shall be capable of displaying the latest status of a service request (case) to an
external submitter from within the submitter's portal page (if he/she has completed the
registration process).
1.37 The system shall be capable of displaying the latest status of a service request (case) to an
external submitter by entering the service request number.
1.38 The system shall be capable of allowing the external submitter to close (withdraw) his/her
service request (case) for certain service request (case) types as may be specified by the
City.
1.39 The system shall be capable of allowing the entry of comments by the original external
service request (case) submitter at any time after the case has been opened until it has
been closed.
1.40 The system shall be capable of allowing the submission of documents and/or images as file
uploads by the original external service request (case) submitter at any time after the case
has been opened until it has been closed.
1.41 The system shall allow city employees/case workers/CSRs to view information and
comments entered by service requestors.
1.42 The CRM application shall integrate with the City's designated departmental applications
(e.g., CityWorks, CIS) in order to ensure that real-time (or near real-time) status of a
citizens service request is available to the citizen through a web-based application or
through a 311 agent/CSR.
Page 4 9/22/2014
The City of Richmond, The City of Richmond, Virginia
Solution
Supports
Requirement
2.01 The system shall include a knowledge base that can be used to research issues, find
department and service information, and respond to requests.
2.02 A knowledge base shall be provided by the application to 311 agents/CSRs containing
questions asked by citizens and the associated correct answers.
2.03 A knowledge base shall be provided by the application for general citizen use containing
frequently asked questions and associated correct answer, as well as other information.
2.04 The system shall be able to import Knowledge base Items from a user specified XML file.
2.05 The system shall be able to import Knowledge base Items by means of a web-based
submission form.
2.06 The system shall be capable of storing file attachments of any type as attachments to
Knowledgebase Items.
2.07 The system shall be capable of displaying an outline view of the Knowledgebase data
structure as a tree using the names of the Knowledgebase Items in the data structure.
2.08 The system shall be able to handle a Knowledgebase of at least 100,000 items.
2.09 The system shall be capable of providing multiple ways to search for Knowledgebase
Items, including "drill-down" through a topic hierarchy, keyword and/or natural language
search, alpha/index search of topics, etc.
2.10 The system shall provide search engines that encompass the following basic capabilities:
keyword search, part of a keyword, exact word search, Boolean search.
N/A The system shall provide a search engine that supports the following capabilities:
2.11 presents relevant hits before entire search is complete
2.12 floats the most relevant hits to the top in order of closest match
2.13 allows the agent to launch another parallel search
2.14 allows the agent to multitask and use the application to perform other work
2.15 The system shall be capable of providing support for translation of knowledgebase articles;
either through an internal facility, or by interfacing with an open-source solution (e.g.,
Google Translate.)
Capabilities Knowledgebase / Repository
Knowledgebase (General)
Storage of Knowledgebase Items / Articles / Answers
Management of Knowledgebase Items / Articles / Answers
Search and Retrieval of Knowledgebase Items / Articles / Answers
Language Translation Support
Page 5 9/22/2014
Solution
Supports
Requirement
3.01 The proposed CRM solution shall support single sign-on using LDAP, if the Offeror
proposes that the application is hosted by the City. If it is not hosted by the City, a similar
single sign-on capability that integrates with the City must be proposed.
3.02 The proposed CRM application shall provide robust tools for bilateral communication
between the City and its citizens, which includes features such as the ability for citizens to
register themselves with the CRM system so they may be kept informed of the status of
their requests via email, through the web portal, and/or by message to their mobile device.
3.03 The application shall group related citizens together in 'households' so as to more
intelligently manage customer relationships. This grouping must support multiple
households and should include such data as address, home phone, cell phone, etc. from
each individual.
3.04 The application shall display a history of past events/actions using various search filters
such as by citizen, by date, by type of event/action, by location and by CRM user. This filter
list is not all inclusive.
3.05 The system shall have the ability to be launched via a single application (versus having to
launch multiple applications.)
3.06 All of the system's desktop client applications shall be "thin client" applications rather than
"thick or fat client" applications, meaning that no or minimal client software will be required
for their operation.
3.07 The CRM application shall include a public-facing front end that all citizens can use to
request City services.
3.08 The proposed application shall provide an online web portal that allows citizens to submit
service requests, check request status, gain information relative to City non-emergency
services, etc.
Integrated Web-based Portal
Internal User Sign-in and Access
External User Registration and Account Profile
Integrated (Single Virtual Application) Portal
Web-based Applications
Page 6 9/22/2014
Solution
Supports
Requirement
4.01 The system shall have the ability to work with the City's IP Contact Center system to enable
IVR capabilities for incoming calls.
ACD capabilities for incoming calls.
4.03 The system shall have the ability to receive Caller ID information from the City's IP Contact
Center System in order to provide "intelligent screen pops" of citizen profile information.
4.04 The application shall integrate with caller-id/telephony software to facilitate a 311 agents
ability to identify the requesting citizen. This is also known as Computer Telephony
Integration (CTI). This feature shall be optional so as to provide for situations whereby a
citizen does not want to be identified by phone number.
monitoring of CSRs, to include screen monitoring.
4.06 The system shall have the ability for a citizen service representative to transfer a call in
progress to another citizen service representative, including both the voice connection and
the working screen (including any open profile and/or case, as well as any teleservice script
currently being executed.)
the routing of calls based on captured IVR data.
4.08 The system shall be capable of maintaining a database of skills possessed by individual
call center employees / citizen service representatives, along with a level of proficiency in
each of the skills.
4.09 The system shall be capable of storing and executing business rules pertaining to the
routing of calls to individual call center employees / citizen service representatives
depending on the nature of the call and the skills of the availability of the representatives.
4.10 The database of skills must be maintainable through an administration function and not
require IT support to configure or modify.
4.11 The system should have the ability to employ advanced collaboration technologies such as
web chat and co-browsing.
Data-directed Call Routing
Skills-based Call Routing
Advanced Collaboration Capabilities
Computer Telephony Integration (CTI)
Interactive Voice Response
Automated Call Distribution
Intelligent Screen Pops
Call Monitoring
Voice and Screen Transfer
Page 7 9/22/2014
Solution
Supports
Requirement
5.01 The system shall have a script authoring tool that can be used to create teleservice scripts.
5.02 The system shall have the ability to create scripts by importing part or all of an existing
script and modifying it.
5.03 The system shall have the ability to associate the completed script with one or more service
request types as defined by the City.
5.04 The system shall have the ability for one or more scripts to be associated with a service
request type as defined by the City (e.g., beginner and expert-level scripts).
5.05 The system shall have the ability to create scripts incorporating standard form elements and
controls (e.g., labels, single and multi-line text fields, combo boxes, hyperlinks, check
boxes, radio buttons, images, etc.)
5.06 The application shall provide a scripting capability to guide users through citizen
interactions in order to provide consistent and accurate information regardless of which
agency actually provides the service or whether the service is provided via another system.
5.07 The system shall have the ability for the citizen service representative to back up and
change responses from within the script as it is executing.
5.08 The system shall shave the ability to suspend a script already being executed, and to
reopen it at a later time to the place where it was suspended, retaining all information
previously entered.
5.09 The application shall provide automated call flow and scripting capabilities. Automated
scripting shall allow all 311 agents/CSRs to handle any type of citizen request except those
restricted service request types requiring special skills and/or certifications.
5.10 The system shall provide support for the creation of scripts incorporating multiple iterations
and instances of complex functions including looping and branching.
5.11 The system shall have the ability to support both looping and branching within the same
script.
5.12 The application workflow shall automatically present the appropriate questions and
information as needed to insure 311 agents/CSRs follow the correct sequence of steps or
ask the right questions.
5.13 The system shall have the ability to support both incoming/incall and outgoing/outcall
surveys.
5.14 The system shall support surveys including multiple question types (e.g., true/false,
numeric, selection from discrete values, freeform text, etc.
Script Authoring
Executing Scripts
Support for Complex Scripts (Loop and Branch)
Integration with Workflow Engine
Support for Surveys
Call Scripting
Page 8 9/22/2014
Solution
Supports
Requirement
Call Scripting
5.15 The system shall have the ability to support conditional branching within the survey (e.g., if
the answer to question 4 is yes, then skip to question 8, otherwise go to question 5).
Page 9 9/22/2014
Solution
Supports
Requirement
6.01 The application shall automatically assign a unique identifier to each citizen request, while
providing the ability to tie it back to the requestor and the household.
6.02 A single citizen service request may generate multiple work orders across multiple
departments. The CRM application shall track each work order (not always created at the
same time) in order to keep the citizen informed of the progress of their case.
6.03 A single issue may result in multiple cases being opened (e.g., a pothole reported by
multiple Citizens. The system shall provide a mechanism to tie together multiple service
requests while continuing to provide status information to all of the individual requestors.
6.04 The system shall provide the capability to flag service requests related to specific events
(e.g., a hurricane, earthquake or flood event).
6.05 The system shall provide the capability to upload, download and save file attachments in
commonly used formats for office automation files, graphics, etc.
6.06 The system may provide the ability to compress saved attachments.
6.07 The system shall have the ability for a citizen service representative to search for and
retrieve a case by the case's identification number.
6.08 After a citizen communicates a request for government services, the fulfillment of that
service, and the component tasks that must be completed to complete the request, shall be
tracked by the CRM tool.
6.09 The application shall capture, track, and manage citizen correspondence, inquiries, or
service requests regardless of their origin (i.e. phone, fax, email, letter, web portal, face to
face, etc.)
6.10 Websites and other applications shall be accessible from within the CRM application and
open up within the CRM application.
6.11 The system shall be capable of reassigning a case in accordance with business rules
defined by the City.
6.12 The system shall be capable of escalating a case in accordance with business rules
defined by the City.
6.13 The application shall provide the ability to configure or define service level target
turnaround times based on department and request type.
6.14 The proposed application shall not close a service request/case until all associated work
orders are completed or a reason is given why the request is being closed without all the
tasks being completed.
6.15 The system shall support basic workflows for handling various types of requests.
Workflow Engine
Case Management and Workflow
Case Initiation
Attachments and File Types Supported
Case Management
Case Reassignment and Escalation
Case Resolution
Page 10 9/22/2014
Solution
Supports
Requirement
6.16 The application shall provide for flexible workflow processes, rules, automated alerts, and
flexible email notifications. These shall be configurable by a business analyst and not
require technical staff.
6.17 As required, the workflow shall route transactions and actions to the correct departmental
application.
6.18 Notifications and Alerts (E-mail, "Push" SMS, Prompt for CSR Call)
6.19 The system shall be capable of supporting e-mail notifications in both plain text and HTML
formats.
6.20 The system shall be capable of utilizing the Microsoft Exchange e-mail gateway.
6.21 The system shall be capable of generating "push" SMS (text message) notifications to
mobile devices.
6.22 The system shall be capable of prompting a responsible service representative to call the
(external citizen) submitter as a notification method.
6.23 The system shall be capable of placing an outbound telephone call via the City's IP Contact
Center solution with a pre-recorded message containing information on a service request
status change or update.
6.24 The system shall be capable of generating printable correspondence (letters) in Microsoft
Word format that can be mailed to service request (case) submitters via mail.
6.25 The system shall be capable of generating printable correspondence (letters) that can be
faxed to service request (case) submitters.
6.26 The proposed CRM application shall provide correspondence handling. The application
shall handle citizen requests from multiple communication channels, including US mail, fax
and e-mail.
6.27 The system shall be capable of issuing a notification when a new service request (case) is
opened.
6.28 The system shall be capable of issuing a notification when an administrator-selectable
period of time has elapsed since the service request case) was opened.
6.29 The system shall be capable of issuing a notification when an administrator-selectable
period of time has elapsed since the service request case) changed status.
6.30 The system shall be capable of issuing a notification when the status of a service request
(case) is changed.
6.31 The system shall be capable of issuing a notification when comments and/or notes have
been entered.
6.32 The system shall be capable of issuing a notification when a service request (case) is
reassigned.
6.33 The system shall be capable of issuing a notification when a service request (case) is
closed.
6.34 Reminder functions shall be used to remind 311 agents/CSRs of a service request that is
aging past a certain time period as specified by the City for follow up.
Types of Notifications Supported
Notification Triggers / Event Types Supported
Page 11 9/22/2014
Solution
Supports
Requirement
6.35 The system shall be capable of supporting different notification "profiles" based on the
service request (case) type.
6.36 The system shall be capable of supporting different notification "profiles" for notification to
the (external citizen) submitter based on the preference of the individual submitting the
service request (case).
6.37 The system shall be capable of storing a default notification "profile" for the external citizen
user including preferred means of contact/notification, as well as frequency of notifications
for service requests (cases) -- e.g., notify me upon status change, notify me only when
completed/closed.
6.38 The system shall be capable of utilizing a specific notification "profile" for the external
citizen user for an individual service request (case) that overrides the default profile -- e.g.,
notify me upon status change, notify me only when completed/closed.
6.39 Automatic multi-level alerts/emails shall be initiated by the application to specific individuals
when a citizens inquiry or service request is approaches or exceeds the target service level
turnaround time.
6.40 The system shall be capable of accepting and storing notification templates compatible with
Microsoft Word, to be used for generating printable notifications to be mailed to service
request (case) submitters.
Microsoft Outlook, to be used for generating e-mail notifications to service request (case)
submitters and internal users.
standard SMS gateways, to be used for generating SMS (text message) notifications to
service request (case) submitters and internal users.
6.43 The solution shall provide integrated application modules sufficient to support the vision,
technology objectives, business objectives and contextual architecture for the CRM
solution, while providing the functionality as specified in the system scope and these
detailed requirements.
6.44 The Solution shall be flexible enough to include relevant information for all interfaced
sources to support a total view of Citizen Information and service request activity. To this
end, the City expects the Solution to utilize a centralized relational database and utilize
common features (security, system utilities, menu design, key mapping, tables, etc.), where
practical.
Customization of Notification Types by Service Request Type, User Preference
Notification Templates
General
Page 12 9/22/2014
Solution
Supports
Requirement
7.01 The internal client application must be compatible with the City's desktop computing
standard (Dell / Microsoft Windows).
7.02 The system's client application software must be capable of running on the Microsoft
Windows platform, including currently supported (e.g., Windows XP, Vista, 7) and future
versions of that platform.
7.03 The system's web-based client application software shall provide interface support for
Microsoft Internet Explorer, Firefox, Google Chrome and Apple Safari browsers.
7.04 The system shall provide the ability to use any native application or plug-in such as Adobe
Acrobat, Flash, QuickTime, and Microsoft Office to create and view attachments.
7.05 The proposed CRM application shall have some degree of capability for each department
to configure the application to meet its unique and varied needs without the use of a
technical resource (i.e., a developer).
7.06 The proposed CRM application shall be web-based, and should use the latest client-side
technologies (e.g., AJAX) to enhance the user experience.
7.07 The proposed CRM application shall be accessible from any location provided the 311
agent/CSRs terminal is located on the Citys intranet.
Technology Architecture Standards and Requirements
Client Hardware
Application Software
Communications
Page 13 9/22/2014
Solution
Supports
Requirement
8.01 The system shall be capable of rendering and displaying properly on World Wide Web
Consortium (W3C) compliant and/or most popular web browsers including Microsoft
Internet Explorer, Firefox, Google Chrome and Apple Safari.
8.02 The application shall display physical locations (such as customer address or service
request location) using a GIS solution compatible with the City's GIS data layers.
8.03 The system shall be capable of displaying multiple GIS data layers which are user-
selectable (on/off).
8.04 The system shall be capable of utilizing and displaying geographic data layers provided by
the City's ESRI ArcGIS X platform (data format = SDE feature class).
8.05 The system shall be capable of identifying the location of a service request on a map by
use of a visual "pin" or other appropriate indicator, once the address is entered.
8.06 The system shall be capable of deriving the address of a service request (within a small
margin of error) based on the location of a "pin" or other indicator placed on the map by a
user.
Geographic Information Systems (GIS)
Browser Compatibility
Map Features
Data Layers / Views
Location (Pinpoint) Identification
Page 14 9/22/2014
Solution
Supports
Requirement
9.01 The application shall provide role-based security controls access to specific functions for
internal users.
9.02 The application shall provide role-based security controls access to specific data for internal
users.
9.03 The application shall provide record ownership-based security controls access to specific
functions for internal users (e.g., for case workers who may "own" specific cases and
should be the only ones authorized to perform certain functions.)
9.04 The application shall provide role-based security controls access to specific functions for
external users.
9.05 The application shall provide role-based security controls access to specific data for
external users.
9.06 The system shall allow an external user to see only the information relating to him or her.
9.07 The system shall allow anonymous submission of certain service request types as
determined by the City; this ability should be configurable by the business user so that
service requests can be added or removed from the list of those that are capable of being
submitted anonymously.
9.08 The CRM system shall provide complex passwords accounts should require complex
passwords, which are generally 8 or more characters with three of the four character types
(upper case letters, lower case letters, numbers and symbols).
9.09 Password change policy and history the CoR (City) Password Administrative Regulation
(AR 2.8) requires that passwords be changed every forty days and that password history
maintains the past 24 passwords.
9.10 The system shall provide administrative auditing and reporting the capability to manage
users, groups and access permissions along with being able to monitor and report on user
and file activity.
9.11 The system shall provide the ability to retain all data in accordance with the Citys record
retention policy and eDiscovery requirements.
Access Control and Data Security
Internal User Access Control
External User Access Control
Passwords
Audit Trail
Page 15 9/22/2014
Solution
Supports
Requirement
10.01 The application layout, design, and navigation shall be easy to use, consistent, and
intuitive.
10.02 Screen layouts shall be capable of being tailored or personalized to individual needs (such
as modifying home page contents to add daily calendars, activities, to do tasks,
outstanding service requests, etc.)
10.03 The application shall support a user interface that allows for the ability to easily search for
and retrieve information.
10.04 The application shall provide senior-friendly displays, or provide the option of switching to
a senior-friendly layout.
10.05 The application shall provide kiosk friendly displays, or provide the option of switching to a
kiosk-friendly layout suitable for use on self-contained, touch-screen computer kiosks.
10.06 User interface considerations apply to both desktop and mobile displays.
10.07 The application's color scheme shall be modifiable to match the City of Richmond identity
standards (color scheme).
standards (fonts and sizes).
standards (style sheets and wrappers).
User Interface Standards and Requirements
General UI Considerations
City of Richmond Branding and Identity
Page 16 9/22/2014
Solution
Supports
Requirement
11.01 The system shall comply with W3C Web Content Accessibility Guidelines.
11.02 The system shall comply with Section 508 Requirements regarding accessibility.
11.03 The system shall comply with Commonwealth of Virginia and City of Richmond policies
regarding accessibility.
11.04 The system shall be capable of providing support for translation of content; either through
an internal facility, or by interfacing with an open-source solution (e.g., Google Translate.)
Accessibility Standards and Requirements
Compliance with W3C Web Content Accessibility Guidelines
Compliance with Section 508 Requirements
Compliance with State and City Policies
Language Translation Support
Page 17 9/22/2014
Solution
Supports
Requirement
12.01 The system shall provide response time performance in line with leading Tier 1 commercial
web applications.
12.02 The system shall have sufficient backup utilities, backup and recovery procedures, and
storage infrastructure to minimize the possibility of data loss.
12.03 The system is expected to available on a 24/7 basis except for scheduled maintenance,
version upgrades and emergency fixes. Web enabled and IVR applications shall also be
available on a 24/7 basis.
12.04 The hosting services provider shall provide a minimum of a guaranteed 99.9% uptime.
12.05 The application shall be scalable to easily allow for additional capacity to be added in the
future.
12.06 The solution shall be able to initially support up to 2,500 internal end users as well as (and
concurrently with) an unspecified number of self-service Citizen users, and shall be
designed to scale in order to meet future demand.
Performance and Scalability Standards and Requirements
Response Time Requirements
Back-up Policies
Monitoring, Downtime and SLA
Scalability
Page 18 9/22/2014
Solution
Supports
Requirement
13.01 The solution shall include Organizational Change Management support as detailed in
section 3 of the Statement of Needs.
13.02 The solution shall include Training support as detailed in section 3 of the Statement of
Needs.
13.03 Context sensitive help screens shall be available to users on each screen.
13.04 All help screens should open in a separate window so the current screen does not have to
be reloaded.
13.05 The Offeror shall provide Implementation and End User Help Desk services Monday
through Friday from 7am to 7pm EST and emergency services after normal working hours,
during weekends and holidays.
13.06 For off-hours and emergency situations, the City requires phone access and a 2 hour call
back period to address problems.
13.07 The Help Desk shall operate from a central location providing a toll free number for the City.
13.08 Specific problem resolution Service Level Agreements (SLAs) in accordance with industry
best practices, will be determined based on Offeror responses to the RFP, and finalized
during contract negotiations.
Support Standards and Requirements
Change Management Support
Training Support
Internal End User Documentation (Manuals, Cheat Sheets, etc.)
Help Desk Support
Prepared by 9/22/2014 Page 19
Solution
Supports
Requirement
14.01 The system shall have the ability to support the Open311 initiative (http://open311.org)
open standards for civic issue tracking.
14.02 The system shall have the ability to support such social media functions as tagging,
bookmarking, etc.
14.03 The system shall have the ability to export knowledgebase articles for use as postings on
the Facebook social media platform, preferably on an automated basis.
the Twitter social media platform, preferably on an automated basis.
other social media platforms, preferably on an automated basis.
14.06 The system shall have the ability to create RSS feeds of knowledgebase articles to which
users can subscribe.
Social Media Integration
Integration with Leading Social Media Communities
Support for Social Media Functions (Social Tagging, Social Bookmarking, etc.)
Ability to Export Knowledgebase Articles
Ability to Create RSS Feeds
Page 20 9/22/2014
Solution
Supports
Requirement
15.01 The CRM system architecture will be based on Service Oriented Architecture (SOA)
principles, so that the appropriate web services will be incorporated within the system
architecture to facilitate the development of required interfaces.
15.02 The system shall provide such external application programming interfaces (APIs) and
toolkits as are necessary to enable the integration of the system with external applications
without the need for extensive interface design or coding.
15.03 The system shall provide the ability to create and display a link to open/launch an external
application, and pass such parameters to the external application as necessary to deep
link to the relevant function and data.
15.04 The application shall provide robust bi-directional (two-way) integration with other
applications. The CRM application must be able to easily integrate with other applications
that are currently in use within the City.
15.05 Since the City is implementing an internal and public-facing Service-Oriented Architecture
(SOA) solution based on Microsoft BizTalk, the CRM solution shall utilize Microsoft BizTalk
as the means of communication with "back end" departmental systems via City's Enterprise
Service Bus.
15.06 The system shall have the ability to interface with the CIS departmental system (DPU),
receiving service requests for specified request types, and returning updated status
information.
15.07 The system shall have the ability to interface with the CityWorks departmental system
(DPW), receiving service requests for specified request types, and returning updated status
information.
15.08 The system shall have the ability to interface with the SeeClickFix Citizen-facing system,
receiving service requests for specified request types, and returning updated status
information.
15.09 The system shall have the ability to interface with the future permitting and land
management system (PDR), receiving service requests for specified request types, and
returning updated status information.
15.10 The system shall have the ability to interface with existing PDR departmental systems (e.g.,
CAPS, Code Enforcement and Cornerstone), receiving service requests for specified
request types, and returning updated status information.
15.11 The system shall have the ability to interface with Finance department systems (primarily
MUNIS; possibly DMV and Clancy).
15.12 The system shall have the ability to interface with other City of Richmond systems as may
be specified, receiving service requests for specified request types, and returning updated
status information.
Integration to External (Departmental) Systems
External APIs and Toolkits
Bi-directional (two-way) Interfaces
Support for Interfaces to/from City of Richmond Departmental Systems
Page 21 9/22/2014
Solution
Supports
Requirement
16.01 The system shall be capable of providing interfaces to both internal and external users on
various mobile devices including "iPhone/iOS" through a native application, maintaining the
appropriate levels of security and access to functionality as defined by the City.
various mobile devices including "Android" through a native application, maintaining the
various mobile devices including ""HTML/WAP-enabled mobile devices," maintaining the
16.04 The system shall be capable of providing notifications to internal City employees via
Blackberry device.
16.05 Access to the internal employee / CSR portal will be secured so that only authorized
personnel are able to access it, and the same function and data access restrictions will
apply as for the web-based portal.
16.06 Access to the external citizen portal will be restricted so that the same function and data
access restrictions will apply as for the web-based portal.
Accessibility via Mobile Devices
Types of Mobile Devices Supported
Internal Mobile Accessibility
External Mobile Accessibility
Page 22 9/22/2014
Solution
Supports
Requirement
17.01 The application shall provide broad reporting tools with numerous pre-configured or
standard reports including service request aging reports, call center statistics, and CRM
user performance statistics.
17.02 The application shall provide an ad-hoc reporting tool that allows for reporting on all data
elements within the system.
17.03 The application shall provide robust reporting and analysis tools. Various reports are
needed to track the performance of each 311 agent/CSR and the status of citizen service
requests.
17.04 The system shall provide an advanced analytics capability to include incorporation of best
practices Key Performance Indicators (KPIs) and predictive analytics / forecasting
capabilities based on historical data.
17.05 The CRM system should provide a robust reporting and analytics capability through
integration with the Citys existing Oracle Business Intelligence (OBIEE) and Oracle
strategic management and performance reporting applications, and also provide the ability
to import and export information to and from external sources.
Reporting, Metrics and Analytics
Canned Reporting
Ad-Hoc Reporting
Metrics and Key Performance Indicators
Advanced Analytics
Page 23 9/22/2014
Solution
Supports
Requirement
18.01 The hosting solution shall provide data encryption on transfer this implies that data is
encrypted while in transit from the CoR (City) network to the cloud provider.
18.02 The hosting solution shall provide data encryption at rest this implies that data is
encrypted on servers using encryption technologies such as 256 bit AES.
18.03 All CoR (City) data will be segmented from other customer data unless the data is
designated by the CoR (City) agency as being public.
18.04 All CoR (City) data will be e-discoverable for litigation and FOIA requests.
18.05 The hosting services provider must conduct and if needed restore backups of CoR (City)
data should data become corrupted or accidentally deleted.
18.06 All hosting servers containing CoR (City) data, including backup servers, shall be located
within the United States of America.
18.07 The solution hosting provider shall be SAS 70 Type II Certified Statement on Audit
Standards widely recognized auditing standard developed by the American Institute of
Certified Public Accountants (AICPA). This certification represents that a service
organization has been through an in-depth audit of their control objectives and activities,
which includes information technology controls and related processes.
18.08 All systems of the hosting services provider shall be continually monitored for intrusion,
malware, viruses, etc
18.09 The hosting services provider shall conduct on-going vulnerability assessments, scans and
penetration tests.
Solution Hosting Standards and Requirements
Data
Audit
Vulnerability
Page 24 9/22/2014

RFP N12079-1 CRM Requirements

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RFP N12079-1 CRM Requirements

Uploaded by

Copyright:

Available Formats

The City of Richmond, Virginia

Customer Relationship Management (CRM) Requirements

You might also like