RFI 27-05706 for Customer and Relationship Platform Questions and Answers.xlsx
XLSX spreadsheet 42 KB Posted
- Solicitation number
- BD-27-1060-ITD00-ITD00-133583
- Issued by
- Suffolk County, Massachusetts
About this file
This file is a Question and Answer document from the Executive Office of Technology Services and Security (EOTSS) for the Commonwealth of Massachusetts responding to 113 questions submitted regarding RFI 27-05706 for an Enterprise Customer and Relationship Platform. The RFI solicits industry feedback on products and solutions delivering enterprise capabilities for customer and organizational relationship management, sales and account processes, service interactions, engagement, workflow automation, data analytics, legal case management, security, and accessibility across Commonwealth agencies. The solicitation is intended to inform a future procurement rather than issue a formal award at this stage. EOTSS has not established a specific initial implementation agency, business process, or use case, nor has it identified fixed user counts, data volumes, or deployment timelines. Responses are expected to address functional capabilities, five-year total cost of ownership (TCO), security and compliance posture, integration approaches, implementation methodologies, and commercial models using reasonable Small, Medium, and Large environment scenarios with clearly stated assumptions. The RFI responses will become public records, with information labeled confidential still subject to public disclosure.
EOTSS has not established a specific budget range, platform strategy, or procurement timeline at the RFI stage and has made clear it has no preference for any particular CRM or enterprise platform. No fixed pricing, licensing model, or set-aside provisions are specified in this document. EOTSS currently operates over 60 CRM instances across the Commonwealth, which spans more than 125 state agencies and 43,000 employees, though the RFI contemplates both internal and external-facing use cases at enterprise scale. The future solicitation will likely use ITS86 as the contract vehicle and may procure platform licensing and implementation services together or separately; no final determination has been made. Respondents should not assume that existing Commonwealth enterprise agreements, statewide contracts, or agency-specific licenses will reduce TCO estimates and should provide transparent commercial packaging distinguishing platform licensing from implementation, migration, integration, training, managed services, and agency onboarding. Any AI integration must be vetted through the Commonwealth's AI Center of Excellence and comply with the EOTSS Enterprise Use and Development of Generative Artificial Intelligence Policy. The Commonwealth is seeking an enterprise service offering with centralized governance and delegated administration that supports hierarchical Parent-Child-Sub Account structures, logical data separation, and integration with existing identity, ERP, financial, data platform, document management, contact center, and middleware systems.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| RFQ 27-05706 for Enterprise Customer and Relationship Platform 09.17.26.docx | DOCX document |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Q&A
| EOTSS RFI 27-05706 for Customer and Relationship Platform | |||
| Question # | Topic | Question | EOTSS Response |
| 1 | Benefits Administration | As EOTSS evaluates an enterprise customer and relationship platform that may ultimately support multiple Commonwealth entities and business processes, would the Commonwealth consider specialized platforms for complex benefit-related use cases where purpose-built functionality may extend beyond a general CRM platform? For example, would a solution focused specifically on benefits administration - including eligibility, enrollment, life events, member self-service, communications, case management, billing, decision support, reporting, workflow and HR/payroll/carrier integrations - be considered either as a component of the future enterprise architecture or in conjunction with a broader CRM/customer relationship platform? In short would the Commonwealth entertain an RFP response for just Benefits Administration? | Yes. For purposes of this RFI, EOTSS is interested in understanding the full range of enterprise offerings, including specialized platforms that may address complex benefits-administration requirements not typically provided by a general CRM. A future solicitation could address specialized capabilities either as part of the broader enterprise architecture or as a complementary solution. Respondents should describe the scope of their benefits-administration capabilities, integration model, dependencies, and commercial structure so EOTSS can evaluate how such a solution could fit within the enterprise service offering. |
| 2 | Budget for Enterprise Customer and Relationship Platform (EOTSS RFI 27-05706) | Regarding the Enterprise Customer and Relationship Platform (EOTSS RFI 27-05706), could you please provide the anticipated budget range or estimated funding allocated for this initiative? | No specific budget range has been established at this RFI stage. One purpose of the RFI is to understand the available marketplace offerings, implementation approaches, licensing models, and associated cost drivers so that EOTSS can develop an informed budget for a potential future procurement. Respondents should provide sufficient commercial detail, assumptions, and five-year TCO information to support that analysis. |
| 3 | Procurement structure | Does EOTSS anticipate that a future solicitation will procure the enterprise platform and implementation services under one award, or could platform licensing and implementation services be procured separately? | EOTSS has not determined at this RFI stage whether platform licensing and implementation services would be procured under a single award or through separate procurements. Respondents should describe the delivery and commercial models they support, including any dependencies between the platform publisher, implementation partner, and managed services. ITS86 would likely be the contract vehicle for a future procurement, subject to final procurement decisions. |
| 4 | Respondent structure | For this RFI, does EOTSS prefer a coordinated response from the platform publisher and implementation partner, or may an implementation partner respond independently based on a proposed enterprise platform? | EOTSS would expect an implementation partner responding to the RFI to do so with input from the platform publisher, particularly for publisher-specific capabilities, licensing, security, certifications, service levels, and roadmap information. The response should clearly identify the respective roles, responsibilities, dependencies, and any areas that are provided directly by the publisher versus the implementation partner. |
| 5 | Platform strategy | Is EOTSS evaluating the selection of one preferred enterprise customer and relationship platform for Commonwealth-wide use, or is it considering multiple qualified platforms that agencies could select based on their individual requirements? | EOTSS has not established a requirement for a single Commonwealth-wide platform or for multiple independently selected platforms through this RFI. The objective is to understand what enterprise platforms and delivery models are available and how they could support a service offering for Commonwealth entities. Respondents should describe how their solution can support centralized governance, agency-level administration and separation, and enterprise-scale adoption across varied business requirements. |
| 6 | Adoption scope | Does EOTSS envision adoption across the full Executive Branch, or will the initial scope focus on a defined group of Secretariats, agencies, or business functions? | The intended service offering should be available to all Executive Department Agencies and all Eligible Entities under OSD contracts. The RFI is therefore intended to inform an enterprise capability rather than a narrowly defined initial agency deployment. Respondents should consider a range of scenarios, from simple internal-facing use cases to larger external-facing services and shared enterprise capabilities. |
| 7 | Initial implementation | Has EOTSS identified an initial agency, business process, or use case that may serve as the first implementation following platform selection? | No specific initial agency, business process, or use case has been identified for a first implementation at this RFI stage. EOTSS is using the RFI to understand available capabilities, implementation approaches, and the options for establishing an enterprise service offering. Respondents should describe practical approaches for selecting and onboarding representative initial use cases and agencies. |
| 8 | Volume assumptions | Can EOTSS provide preliminary assumptions for the Small, Medium, and Large pricing scenarios, including internal users, external users, agencies, cases, transactions, data volumes, storage, integrations, and environments? | EOTSS is not providing fixed Small, Medium, and Large planning assumptions at this RFI stage. Respondents should use their expertise to define reasonable and comparable scenarios and clearly state the assumptions used. With hundreds of business units in the Commonwealth, all scenarios should be considered, including simple internal-facing deployments, larger external-facing services, and integrations with contact centers, data repositories, and other enterprise platforms. User types, transactions, data and storage, integrations, environments, and consumption-based services should be identified as material TCO drivers. |
| 9 | User licensing | For five-year TCO modeling, should vendors distinguish among full users, limited-function users, occasional users, administrators, developers, external authenticated users, and public or anonymous users? | Yes. For five-year TCO purposes, respondents should distinguish the major user and access categories that materially affect licensing, including full-function users, limited-function or occasional users, administrators, developers or builders, authenticated external users, and public or anonymous users. Respondents should explain which license or access model applies to each category, any minimums or entitlements, and the associated commercial and functional implications. |
| 10 | Current environment | Will EOTSS provide an inventory of CRM, case-management, workflow, customer-service, legal case-management, engagement, analytics, and low-code platforms currently used across Commonwealth agencies? | EOTSS is not providing a complete inventory of current CRM, case-management, workflow, customer-service, legal case-management, engagement, analytics, and low-code platforms at this RFI stage. EOTSS currently supports more than 60 CRM instances, and certain entities use their own solutions. Additional detail on current use cases and incumbent systems may be provided as part of a future procurement. Respondents should describe how their platforms support coexistence, integration, modernization, migration, and replacement scenarios. |
| 11 | Existing agreements | Should respondents assume that applicable Commonwealth enterprise agreements, statewide contracts, or existing agency licenses may be used when developing five-year TCO estimates? If so, will EOTSS provide relevant pricing or contract assumptions? | Respondents should not make assumptions that existing Commonwealth enterprise agreements, statewide contracts, or agency-specific licenses will reduce the five-year TCO for purposes of this RFI. The objective is to understand the complete commercial model for the proposed solution. Respondents should identify any optional or potentially reusable existing investments separately from products, licenses, services, or capacities that would be required for the proposed solution. |
| 12 | Contract vehicle | If this RFI leads to a future procurement, does EOTSS anticipate using an existing Statewide Contract, conducting an open competitive solicitation, or establishing a new enterprise contract vehicle? | Yes. ITS86 would likely be the contract vehicle for a future procurement, subject to final procurement decisions. This RFI is intended to inform the scope, commercial model, and delivery approach before a final solicitation structure is established. Respondents should identify any assumptions about contract structure, licensing, implementation services, partner participation, or other commercial dependencies that materially affect their proposed approach. |
| 13 | Migration strategy | Does EOTSS anticipate migrating existing agency CRM and case-management applications to the selected platform, or primarily using the platform for new applications and future modernization initiatives? | EOTSS has not established a final migration strategy at this RFI stage. The desired platform is intended to provide a durable enterprise foundation and integrate with the broader Commonwealth technology ecosystem, while migration of existing agency applications may be considered as future use cases. EOTSS currently supports more than 60 CRM instances and certain entities use their own solutions. Respondents should describe both coexistence/integration and migration approaches, including dependencies, sequencing, data considerations, and cost implications. |
| 14 | Platform architecture | Is EOTSS considering a shared enterprise instance with logical agency separation, separate agency instances under centralized governance, or a hybrid model? Should respondents evaluate and price more than one architecture? | EOTSS has not selected a specific shared-instance, separate-instance, or hybrid architecture at this RFI stage. The desired platform should support a durable enterprise foundation with hierarchical administration and billing, logical separation of agency information, centralized governance, enterprise integration, security, accessibility, and scalable administration. Respondents should describe the architecture options available, including the associated licensing, isolation, governance, integration, operational, and TCO implications of each option. Where material, respondents should provide more than one architecture scenario. |
| 15 | Data governance | Should the future platform support a shared Commonwealth customer or constituent record across agencies, or should agency data remain separated unless a specific legal and programmatic basis permits sharing? | The desired account model is a Parent-Child-Sub Account hierarchy with controlled visibility. A Sub Account should be able to access only its own information; a Child should be able to access its own information and the information of its associated Sub Accounts; and the Parent should be able to access its own information and the information of associated Child and Sub Accounts. Independent entities that choose to use the service through the Commonwealth contract would be treated as separate Child accounts. Respondents should explain how these relationships and visibility rules can be implemented and audited. |
| 16 | Security scope | Which regulated data categories listed in SEC-001 are expected in the initial implementation? Should respondents price a platform environment capable of supporting every listed category, or identify separate architectures and costs based on data classification? | There is no defined initial implementation scope of agencies or data types at this RFI stage. For planning purposes, respondents should assume that the platform may need to support data classified at the highest applicable levels, including CJIS, PII, HIPAA/PHI, and other regulated or sensitive data sets. Respondents should therefore describe the applicable security, hosting, isolation, certification, encryption, key-management, and licensing implications for higher-assurance deployments and identify when separate architectures or products may be required. |
| 17 | FedRAMP | Does Active FedRAMP Certification represent a mandatory qualification for the proposed platform, or is EOTSS requesting it as one component of the platform's security and compliance posture? | Active FedRAMP authorization is not stated as a universal mandatory qualification in this RFI. FedRAMP capability is highly favorable and may be mandatory for certain future implementations or data classifications. Respondents should identify the current FedRAMP status and authorization level of each applicable product, SKU, hosting environment, and region, including scope, inherited controls, customer responsibilities, limitations, and any incremental costs. |
| 18 | Integrations | Can EOTSS identify the principal enterprise systems and services with which the platform would be expected to integrate, including identity, ERP, data platforms, document management, contact center, email, payment, GIS, and integration middleware? | EOTSS has not identified a single fixed set of enterprise integrations for this RFI. Respondents should assume that integrations may be required with identity services, ERP and financial systems, enterprise data platforms, document and content repositories, contact-center platforms, email, payment services, GIS, middleware, and other Commonwealth systems. Responses should describe supported API, event, messaging, webhook, batch, file, identity, and middleware patterns, along with relevant limits, monitoring, failure handling, versioning, premium connectors, licensing, and customer responsibilities. |
| 19 | Integration standards | Does EOTSS have preferred enterprise integration platforms, API-management tools, event or messaging services, identity services, or data-exchange patterns that respondents should assume? | No specific enterprise integration platform, API-management tool, event or messaging service, identity provider, or data-exchange pattern is mandated by this RFI. Respondents should describe the integration patterns their solution supports and identify any preferred or required middleware, connectors, identity services, messaging infrastructure, or other components. Any future solicitation may establish specific enterprise standards or required integrations based on the information gathered through this RFI. |
| 20 | Artificial intelligence | For the five-year TCO, should AI capabilities be included as a baseline component, presented as separately priced options, or modeled using multiple adoption and consumption scenarios? | AI capabilities should be highlighted as part of the RFI response and included in the overall five-year TCO. EOTSS has not prescribed a single AI commercial model at this stage. Respondents should distinguish between included capabilities and separately licensed or consumption-based services and identify material drivers such as capacity, per-action usage, model consumption, storage, and other AI-related charges. Any AI integration within the Commonwealth will need to be vetted through the AI COE and comply with the EOTSS Enterprise Use and Development of Generative Artificial Intelligence Policy. |
| 21 | Implementation schedule | Does EOTSS have a preliminary target date for platform selection, foundational implementation, or onboarding of the first participating agency? | EOTSS does not have a finalized target date for platform selection, foundational implementation, or onboarding of a first participating agency at this RFI stage. The RFI is intended to help EOTSS understand the marketplace, solution architecture, implementation approaches, and commercial models before establishing a detailed procurement schedule. Respondents should identify realistic implementation timelines and key dependencies based on comparable enterprise deployments. |
| 22 | Delivery model | Would EOTSS consider a phased model consisting of an enterprise foundation followed by agency onboarding through separate statements of work, task orders, or competitive work orders? | Yes. A phased delivery model is consistent with the enterprise nature of the initiative and may include an enterprise foundation followed by agency onboarding through statements of work, task orders, competitive work orders, or other mechanisms established by a future procurement. EOTSS has not selected a specific mechanism or wave structure at this RFI stage. Respondents should describe practical phased delivery options, governance, dependencies, and the associated implementation and TCO implications. |
| 23 | Partner ecosystem | Does EOTSS anticipate that existing Commonwealth implementation partners may participate in agency onboarding, or is the future platform procurement expected to establish a limited pool of qualified implementation partners? | EOTSS expects that implementation partners may participate in agency onboarding and enterprise implementation activities. The RFI is intended to understand the range of delivery and partner models available rather than establish a final pool or structure at this stage. Respondents should identify the roles that could be performed by the platform publisher, implementation partners, managed-service providers, and Commonwealth resources, including any certification, staffing, or commercial dependencies. |
| 24 | TCO scope | Should five-year TCO estimates include implementation, migration, integration, organizational readiness, training, managed services, and agency onboarding, or should respondents separate platform licensing from each professional-services category? | Yes. Respondents should address the complete five-year TCO needed to understand the enterprise service, while clearly separating platform licensing from implementation, migration, integration, organizational readiness, training, managed services, and agency onboarding. All material products, services, environments, storage, consumption, premium connectors, partner services, and customer resource requirements should be identified so EOTSS can evaluate both recurring and one-time costs. |
| 25 | Past performance | May implementation partners use Commonwealth agency projects as supporting experience when the underlying platform publisher is submitting a coordinated response? | Yes. An implementation partner may use relevant Commonwealth agency experience as supporting evidence when the platform publisher is submitting a coordinated response. The response should clearly identify the implementing organization, the scope of its role, the underlying platform, the nature of the work performed, and the relevance of the experience to the proposed enterprise solution. Publisher and partner claims should be distinguishable so that responsibilities and evidence are clear. |
| 26 | Supplier diversity | Does EOTSS anticipate including Supplier Diversity Program participation or utilization goals in a future solicitation, and would EOTSS consider structures that encourage certified Massachusetts diverse businesses to participate in implementation and agency onboarding? | Future procurements will follow applicable OSD guidelines and the requirements of the underlying statewide contract or other contract vehicle selected for the procurement. This RFI does not establish specific Supplier Diversity Program goals or participation requirements. Respondents may describe delivery structures that support participation by certified Massachusetts diverse businesses, including subcontracting or agency-onboarding roles, provided those structures are consistent with applicable Commonwealth procurement requirements. |
| 27 | Evaluation approach | Has EOTSS identified the likely evaluation priorities for a future procurement, such as functional capability, five-year TCO, security, accessibility, implementation approach, existing Commonwealth adoption, or vendor experience? | EOTSS has not established a final evaluation or scoring methodology through this RFI. The information sought is intended to inform future procurement criteria. Respondents should provide factual information relevant to functional capability, value and five-year TCO, security and compliance, accessibility, scalability, integration, implementation complexity, vendor and partner capabilities, enterprise adoption, and long-term supportability. A future solicitation will define the applicable evaluation methodology and priorities. |
| 28 | Demonstrations | Does EOTSS anticipate requesting platform demonstrations, agency-specific scenarios, technical proofs of concept, or oral presentations after reviewing RFI responses? | EOTSS has not committed at this RFI stage to demonstrations, agency-specific scenarios, technical proofs of concept, or oral presentations. The Commonwealth may request additional information or formal presentations after reviewing responses. Respondents should therefore provide sufficiently detailed, factual descriptions and supporting evidence to allow EOTSS to understand the capabilities, dependencies, assumptions, and limitations of the proposed solution. |
| 29 | Response format | Is there a preferred page limit for the narrative response and appendices, or may respondents determine the length needed to address the 30 requirement categories and supporting evidence? | No specific page limit has been established for the narrative response or appendices in this RFI. Respondents should use the space needed to provide a concise, point-by-point response to the Requirement IDs and supporting evidence, while avoiding unnecessary promotional material. Any future solicitation may establish more detailed response-length or formatting requirements. |
| 30 | Public records | Because RFI responses will become public records, may respondents provide commercially sensitive licensing assumptions in a separate attachment, and how does EOTSS recommend handling information that a platform publisher considers proprietary? | The RFI states that the RFI and all responses will become public records and that information labeled confidential will still be considered public record. Respondents should therefore provide commercially sensitive information only to the extent necessary to support the response and should present pricing, licensing assumptions, and proprietary details factually within the requested materials. Any future solicitation will establish the applicable public-record and response requirements. |
| 31 | Current platform preference | Does EOTSS currently have a preference for, or strategic alignment with, a particular CRM or enterprise platform? If so, please identify the platform or describe the existing enterprise technology standards that may influence platform selection. | EOTSS has no stated preference for a particular CRM or enterprise platform through this RFI, and respondents should not assume alignment to an incumbent platform. The purpose of the RFI is to understand what is available and how it could be offered as an enterprise service. Any future platform selection would be informed by the Commonwealth's functional, security, accessibility, integration, scalability, commercial, and operational requirements and would be addressed through the applicable procurement process. |
| 32 | Selection criteria | What criteria does EOTSS expect to use when comparing platforms, including license and consumption costs, five-year total cost of ownership, functional breadth, configurability, integration capability, security, accessibility, scalability, existing Commonwealth adoption, implementation complexity, vendor viability, and availability of qualified implementation partners? | The criteria identified in the question are relevant considerations for the RFI and for development of a future procurement, including functional breadth, configuration and extensibility, integration, security and compliance, accessibility, scalability, five-year TCO, implementation complexity, vendor viability, and availability of qualified implementation resources. EOTSS is also focused on value, ease of procurement, ease of implementation, security, and the ability to integrate with the broader Commonwealth technology environment. A final evaluation methodology has not yet been established. |
| 33 | FedRAMP | SEC-001 asks respondents to state their active FedRAMP authorization status and level. Does the Commonwealth anticipate that active FedRAMP authorization will be mandatory, preferred, or not required in any subsequent solicitation? If applicable, what FedRAMP authorization baseline would be required (Low, Moderate, or High) | Active FedRAMP authorization is not mandated at a specific level by this RFI. FedRAMP capability is highly favorable and may be mandatory for certain implementations. Respondents should state the current authorization level, scope, applicable products/SKUs and hosting environments, inherited controls, customer responsibilities, limitations, and any incremental costs. A subsequent solicitation may establish a specific FedRAMP baseline where required by the final solution scope. |
| 34 | General Instructions, Response Format; | Are standardized response values defined for Section II answers? If so, what standardized response values should respondents use for each Requirement ID? | No standardized response values are defined in the current RFI beyond the instruction to provide a point-by-point response using the Requirement IDs. The RFI asks respondents to distinguish among generally available, configured, low-code, custom, third-party, roadmap, and unsupported capabilities and to identify associated evidence, dependencies, limitations, and commercial impacts. Respondents should use those categories to the extent applicable to their response. |
| 35 | SEC-001, Security, Risk, and Compliance | SEC-001 identifies Criminal Justice Information and Criminal Offender Record Information among the data types that may need to be accommodated. Does the Commonwealth anticipate that compliance with the FBI CJIS Security Policy will be required for the proposed platform? If so, which agencies, business functions, or data sets are expected to be in scope? | EOTSS has not identified a specific agency, business function, or data set as the initial CJIS scope for this RFI. For planning purposes, respondents should assume that the solution may need to accommodate data classified at the highest applicable levels, including CJIS/CORI, PII, HIPAA/PHI, and other regulated or sensitive data. Respondents should describe how their proposed solution supports CJIS-related requirements, including applicable authorization boundaries, security controls, hosting options, customer responsibilities, and any additional products or costs. |
| 36 | SEC-001, Security, Risk, and Compliance | Which of the regulated or sensitive data types listed in SEC-001, including PII, payment card information, FERPA data, PHI, Federal Tax Return Information, CJI/CORI, and SSA data, are expected to be in scope for the initial deployment, and which, if any, are anticipated for later phases? | No final initial or later-phase data scope has been established at this RFI stage. Respondents should assume that the platform may need to support the full range of regulated or sensitive data identified in the RFI, including PII, payment card information, FERPA data, PHI, Federal Tax Return Information, CJI/CORI, and SSA data. Responses should identify the applicable compliance and hosting options, data-segregation controls, certifications or authorizations, customer responsibilities, and incremental costs associated with higher-assurance data. |
| 37 | COM-001, Commercial Model and Total Cost of Ownership; | COM-001 asks respondents to model Small, Medium, and Large environments. Could the Commonwealth define these scenarios in terms of approximate numbers of agencies or entities and users by type, including employee or agent users, administrators, developers or builders, external users, and mobile users? Please also indicate whether user counts should be modeled as named or concurrent. | EOTSS is not providing fixed Small, Medium, and Large thresholds at this RFI stage and would look to respondent expertise to define meaningful enterprise sizing scenarios. With hundreds of business units, any combination of internal and external-facing use cases may be in play. Respondents should define scenarios using user types, agency or entity counts, cases and transactions, data and storage, integrations, environments, and other material cost drivers, and should state whether licensing assumptions are based on named, concurrent, consumption-based, or other access models. |
| 38 | UX-001, User Experience; SVC-001, Service and Customer Support | What are the Commonwealth's anticipated requirements for external-user portal capabilities? Please clarify the expected user populations, key functions such as request submission, status tracking, document upload, and knowledge access, the intended external identity and authentication approach, whether a single enterprise portal or agency-specific portals are envisioned, and approximate external-user volume? | The RFI anticipates both internal and external-facing use cases, but EOTSS has not defined a single enterprise portal model or fixed external-user population at this stage. Respondents should address portal and self-service capabilities such as request submission, status tracking, document upload, knowledge access, authentication, and integration with service operations where supported. Responses should explain options for enterprise versus agency-specific experiences, supported identity models, user volumes, security, and the resulting licensing and TCO implications. |
| 39 | CAP-001, Business Capability Scope; SVC-001, Service and Customer Support | What document and file management capabilities are expected within the proposed business processes? Please clarify requirements for document generation, versioning, retention and disposition, electronic signature, redaction, and integration with existing Commonwealth content or records repositories. | The RFI identifies document and content capabilities as part of the broader enterprise scope and specifically calls for consideration of content, data, workflow, service, and legal case management. EOTSS has not established a single enterprise document-management standard or detailed functional baseline at this RFI stage. Respondents should describe document generation, versioning, retention and disposition, electronic signature, redaction, permissions, audit, and integration with existing Commonwealth content or records repositories, and identify any third-party products or services required. |
| 40 | DTR-001, Data Onboarding and Transition; DAT-001, Data Architecture | What document and file volumes should respondents assume for solution sizing and data transition planning? Please include, where available, initial storage to be migrated, expected annual growth, typical and maximum file sizes, approximate documents per case or record, and required retention periods. | EOTSS has not established fixed document or file volumes, annual growth assumptions, file-size distributions, documents-per-record, or retention periods for this RFI. Because the Commonwealth environment includes hundreds of business units and varied use cases, respondents should define reasonable Small, Medium, and Large scenarios using storage, document volume, growth, file size, retention, and migration assumptions. Those assumptions should be stated clearly and their effect on architecture, licensing, implementation effort, and five-year TCO should be identified. |
| 41 | Future platform specification | If EOTSS identifies a preferred CRM or enterprise platform through this RFI process, will a future RFR or RFQ name that platform, require solutions based on it, permit equivalent platforms, or remain platform-neutral? | Any subsequent RFR or RFQ would remain platform-agnostic based on the current RFI direction. The purpose of this RFI is to understand available capabilities, architectures, delivery models, and commercial approaches before a future procurement is defined. No specific platform should be assumed to be preselected or required as a result of the RFI alone. |
| 42 | Future procurement timing | Does EOTSS have an anticipated timeframe for issuing a future RFR or RFQ, selecting a platform, and beginning the initial implementation? If firm dates are not available, please provide the current planning assumptions or expected fiscal year. | Not at this time. EOTSS has not established a firm timeframe for a subsequent RFR or RFQ, platform selection, or initial implementation. The RFI is being used to inform future planning, scope, procurement structure, and budget. Respondents should provide realistic timing assumptions and implementation dependencies that EOTSS can consider when developing a future procurement schedule. |
| 43 | Enterprise Vision & Platform Strategy | 1. What specific business challenges led EOTSS to initiate this statewide CRM and relationship platform evaluation? 2. Is the goal to consolidate existing CRM platforms, replace legacy systems, or establish a net-new enterprise platform? 3. Which Commonwealth agencies are expected to participate initially? 4. Which agencies are expected in future phases? 5. Is EOTSS envisioning a single enterprise instance or a multi-tenant agency model? 6. What are the top five success measures for the program? 7. What executive offices are sponsoring the initiative? 8. How will agency adoption be mandated or encouraged? 9. Are there target operational efficiencies or cost reductions being sought? 10. What lessons have been learned from previous statewide shared-services programs? | EOTSS is evaluating an enterprise service model intended to provide Commonwealth entities with access to capable solutions that offer value, ease of use, ease of procurement, ease of implementation, security, and integration. The RFI does not establish a final consolidation-versus-replacement strategy, initial agency list, or required instance model. The intended service should be available to Executive Department Agencies and Eligible Entities under OSD contracts, with centralized governance and appropriate agency-level administration and data separation. EOTSS is also seeking to understand potential operational efficiencies, cost drivers, and lessons from prior shared-services experience, particularly where complexity and integrations can increase implementation effort and ongoing cost. A future solicitation will establish the final success measures, sponsorship, adoption approach, and procurement requirements. |
| 44 | Agency and Use Case Discovery | 1. Which business functions are currently using CRM solutions today? 2. How many agencies currently maintain customer records? 3. How many independent customer databases exist today? 4. What are the highest-volume citizen-facing programs? 5. What agency-specific use cases must be supported? Examples: * Constituent services * Benefits administration * Licensing * Permitting * Taxpayer support * Public health programs * Workforce services * Transportation * Legal case management 1. Which use cases require inter-agency collaboration? 2. What customer lifecycle processes span multiple agencies? 3. Are there statewide constituent profiles envisioned? 4. Will organizations, businesses, vendors, nonprofits, municipalities, and residents be managed as separate customer entities? 5. How should cross-agency relationship ownership be governed? | EOTSS currently supports more than 60 CRM instances, and certain entities use their own solutions. For RFI purposes, EOTSS is not providing a detailed inventory of agency-specific use cases, customer databases, transaction volumes, or cross-agency lifecycle processes. Respondents should consider a broad enterprise scope that may include constituent services, benefits administration, licensing, permitting, taxpayer support, public health, workforce services, transportation, and legal case management, as well as use cases that cross agency boundaries. The desired account model is Parent-Child-Sub Account with controlled visibility, and independent entities using the service through the Commonwealth contract would be treated as separate Child accounts. Future procurement materials may provide more detailed use-case and agency information. |
| 45 | Customer 360 and Relationship Management | Citizen and Organization Modeling 1. What defines a customer within the Commonwealth? 2. What entities must be represented? Examples: * Resident * Business * Vendor * Municipality * Healthcare Provider * Educational Institution * Nonprofit Organization 1. Should a citizen have one universal profile across agencies? 2. How should duplicate individuals be managed? 3. What identity resolution technologies currently exist? 4. How should family, household, employer, and organization relationships be represented? 5. Is a Master Data Management platform already in place? 6. What constitutes a golden customer record? 7. What data stewardship processes exist? 8. What customer attributes require special protection? | For this RFI, EOTSS is not defining a single universal customer identity model or a Commonwealth-wide golden record. Identity details are not the primary focus of the current RFI, and agency-specific identity and data-management practices vary. Respondents should nevertheless describe how the platform can represent residents, businesses, vendors, municipalities, providers, educational institutions, nonprofits, and other organizations; support relationship and affiliation modeling; resolve or manage duplicates; protect sensitive attributes; and integrate with existing identity-resolution or master-data capabilities where required. For additional context on Commonwealth constituent-facing services, see https://www.mass.gov/orgs/mymassgov. A future procurement may establish more detailed customer-360 and identity requirements. |
| 46 | Contact Center and Service Experience | Citizen Support Operations 1. Which contact centers currently integrate with agency systems? 2. Is there a statewide CCaaS strategy? 3. What contact center platforms are currently deployed? Examples: * Amazon Connect * Genesys * NICE CXone * Five9 * Cisco * Avaya 1. How many agents statewide could require CRM integration? 2. Is screen-pop functionality required? 3. Is omnichannel routing required? 4. Are there shared-service contact centers today? 5. What service-level agreements are expected? 6. What knowledge management tools currently exist? 7. Is citizen self-service a primary objective? | The Commonwealth's MassVoice offering uses Five9 as its contact-center platform. Certain entities within the Commonwealth have also chosen to use Amazon Connect. CRM users may or may not require connectivity to these contact-center environments depending on the use case. Respondents should therefore describe supported integrations for screen pop, routing, telephony and digital channels, knowledge, case and request handling, and self-service, as applicable, without assuming that a single statewide contact-center platform is required for every deployment. Respondents should also identify integration dependencies, licensing, and implementation considerations for Five9, Amazon Connect, and other contact-center platforms. |
| 47 | Legal Case Management | 1. Which agencies require legal case management? 2. Is litigation management in scope? 3. Is administrative hearing management required? 4. Must chain-of-custody controls exist? 5. Are evidentiary records managed today? 6. What document repositories support legal processes? 7. Is role-based segregation required? 8. Are judicial system integrations anticipated? 9. What retention requirements exist? 10. What audit requirements apply? | EOTSS has not finalized the agencies, business processes, or detailed scope for legal case management in this RFI. Legal case management is identified as a capability area, but specific requirements such as litigation management, hearings, evidence, chain of custody, legal document repositories, judicial integrations, retention, and audit remain to be defined. Respondents should describe the legal case and matter-management capabilities available in the proposed platform, including security and segregation controls, document handling, workflow, audit, reporting, and any specialized products or services required to support legal use cases. |
| 48 | Workflow & Process Automation | 1. Which business processes are most frequently cited as inefficient today? 2. Which approval processes should be automated? 3. Is statewide workflow standardization a goal? 4. Are process mining tools in use today? 5. Should workflows cross agency boundaries? 6. What BPM platforms currently exist? 7. Are human-in-the-loop approvals mandatory for AI-generated outcomes? 8. What volume of automated transactions is expected? 9. How are workflow exceptions handled today? 10. What governance is required for citizen-impacting decisions? | EOTSS has not identified a single prioritized set of inefficient processes, statewide workflow standard, or required process-mining platform for this RFI. Respondents should describe how their solution supports workflow design, human approvals, exception handling, cross-functional or cross-agency processes, monitoring, versioning, testing, deployment, recovery, and audit. Where workflows may affect customers or other consequential decisions, respondents should explain available governance, human-in-the-loop controls, and administrative oversight, including any transaction, licensing, or automation limits. |
| 49 | Enterprise Integration Architecture | 1. What enterprise platforms must integrate with the new solution? Examples: * ERP * Financials * HR Systems * Identity Platforms * Data Lakes * GIS * Document Management * CCaaS * Case Management 1. What middleware standards exist today? 2. Is MuleSoft, Boomi, Azure Integration Services, Informatica, IBM, or another iPaaS already enterprise-standard? 3. Are event-driven architectures currently used? 4. What API standards are mandated? 5. What legacy systems lack APIs? 6. How many systems require bi-directional synchronization? 7. What are integration SLAs? 8. What monitoring tools exist today? 9. What integration patterns are preferred? | EOTSS has not identified a single mandated enterprise integration stack for this RFI. With hundreds of business units, respondents should assume that integrations may be required across ERP and financial systems, HR, identity, data platforms, GIS, document management, contact centers, case-management systems, legacy applications, and other enterprise services. Respondents should describe supported middleware and iPaaS patterns, APIs, event-driven integration, bi-directional synchronization, batch/file interfaces, monitoring, failure handling, SLAs, and versioning, and should identify any required products, premium connectors, licensing, or customer resources. The RFI is intended to understand the capabilities available before final enterprise standards are established. |
| 50 | Enterprise Data | 1. What systems currently own customer data? 2. Is there an enterprise data lake? 3. Is there an existing MDM platform? 4. What data quality challenges exist today? 5. What historical data must be migrated? 6. How much unstructured data exists? 7. What archival requirements exist? 8. Are there agency-specific data sovereignty requirements? 9. What reporting repositories exist today? 10. What is the data retention strategy? | EOTSS does not have a single enterprise data architecture or fixed set of assumptions for all business units at this RFI stage. Data ownership, quality, retention, reporting, historical data, and repository practices vary across the Commonwealth environment. Respondents should describe how their solution can operate within varied master-data and system-of-record patterns, support data quality and lineage, integrate or federate with enterprise data platforms, handle structured and unstructured content, support archival and retention requirements, and provide data and metadata portability. Respondents should state the assumptions and dependencies that materially affect migration, storage, reporting, analytics, security, and five-year TCO. |
| 51 | AI Discovery | 1. What AI use cases are currently approved? 2. Which AI use cases are prohibited? 3. Is citizen-facing generative AI permitted? 4. What human review requirements exist? 5. Must model outputs be explainable? 6. Can AI access regulated data? 7. Are there approved model providers? 8. What AI governance board exists today? 9. What auditing requirements apply to AI recommendations? 10. How should AI-generated content be retained? | At this RFI stage, EOTSS has not established a definitive list of approved or prohibited AI use cases, approved model providers, or a single set of AI-specific retention and explainability requirements. AI capabilities should be highlighted. Any AI integration within the Commonwealth will need to be vetted through the AI COE and comply with the EOTSS Enterprise Use and Development of Generative Artificial Intelligence Policy. Respondents should describe available human-oversight, audit, explainability, data-access, retention, model-selection, security, privacy, and administrative controls, including how regulated data can be protected and how AI can be restricted or disabled. |
| 52 | Public Sector Security | 1. Which agencies require CJIS compliance? 2. Which agencies process FTI? 3. Which agencies manage HIPAA data? 4. Are FedRAMP High environments required? 5. Is data residency restricted? 6. What key-management requirements exist? 7. Are customer-managed keys required? 8. What SIEM platform is used enterprise-wide? 9. What cybersecurity tools are mandated? 10. What identity providers are standard? | EOTSS has not identified specific agencies, SIEM products, identity providers, key-management models, or data-residency requirements for this RFI. All responses should assume that data classification could be needed at the highest levels and should address CJIS, PII, HIPAA, and other regulated or sensitive data sets. FedRAMP capabilities are highly favorable and may be mandatory for certain implementations. Respondents should identify the applicable certifications, authorizations, inherited controls, customer responsibilities, hosting regions, encryption and key-management options, and security integrations supported by the proposed solution. |
| 53 | Organizational Readiness | 1. How many agencies will participate in Phase 1? 2. What level of process standardization exists today? 3. Will business process redesign occur before implementation? 4. What training model is preferred? 5. Are agency super-users expected? 6. What change resistance concerns exist? 7. What governance board will approve platform changes? 8. How will agency prioritization occur? 9. Are implementation waves anticipated? 10. What implementation timeline is envisioned? | No Phase 1 agency, final implementation wave structure, or target implementation timeline has been identified at this RFI stage. The intended service offering should be available to all Executive Department Agencies and all Eligible Entities under OSD contracts, and respondents should assume that hundreds of business units and a range of simple internal and larger external-facing scenarios may be in play. Respondents should describe recommended implementation waves, governance, organizational-readiness activities, training, agency prioritization, and dependencies based on their experience. Any subsequent procurement may provide more specific scope and timing. |
| 54 | Post-Go-Live Operations | 1. Does EOTSS intend to self-administer the platform? 2. Is a managed service provider desired? 3. What support tiers are expected? 4. Are 24x7 operations required? 5. What application management services are required? 6. What release management responsibilities will remain with the vendor? 7. How should agency requests be prioritized? 8. What SLAs are expected? 9. What reporting must support teams provide? 10. How will AI features be governed post deployment? | EOTSS has not finalized the post-go-live operating model, support-tier structure, or required service levels for this RFI. Respondents should describe available operating models, including Commonwealth self-administration, vendor or partner managed services, application management, release management, monitoring, incident response, support coverage, SLAs, reporting, and post-deployment AI governance. The proposed model should support centralized governance with delegated administration and should identify material customer responsibilities and recurring costs. |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .