EOED OneStop Grant Management RFR Final v3 Amended Final DATE ONLY CHANGE~1.docx

REQUEST FOR RESPONSE

EOED OneStop Grant Management System RFR RFR #131710/ COMMBUYS Bid# BD-27-1100-EED01-EED01-131710

ISSUE DATE: 7/24/2026

V2 7/30/20226 V3 8/20/2026:

The deadline to submit bids is extended from Friday August 21 until Wednesday August 26.

1. Description or Purpose of Procurement:

The Massachusetts Executive Office of Economic Development (EOED) is responsible for advancing economic growth, job creation, and equitable development across the Commonwealth. EOED works in partnership with state agencies, quasi-public entities, municipalities, regional organizations, and the private sector to strengthen the Commonwealth’s economy and support communities of all sizes.

EOED has two flagship grant initiatives include the Community One Stop for Growth (“One Stop”) and the Business Front Door (“BFD”). The EOED portfolio also includes various grant programs run through the Executive Office, agencies and quasi-public agencies.

The primary users of this new system will be the flagship initiatives of the One Stop and the BFD. These teams run coordinated, cross-agency efforts to streamline access to state economic development, business and community investment programs for municipalities, not for profits, businesses and other eligible applicants. The initiatives provide a unified application and review process across multiple state agencies and authorities, enabling applicants to submit a single application for consideration across a range of funding programs. EOED manages the overall processes, including application intake, interagency coordination, review, and award recommendations, while participating agencies retain responsibility for program-specific requirements and grant administration. These initiatives are currently supported by a legacy grants management systems (IGX and Salesforce, respectively) that have become increasingly constrained as the program has grown, highlighting the need for a more flexible, scalable solution with enhanced user experience, reporting, and integration capabilities.

In addition to the One Stop and the BFD, EOED administers a diverse portfolio of grant, incentive, and other support programs that advance a wide range of economic development activities, including business growth and workforce development. These programs serve a broad set of applicants and stakeholders, including municipalities, businesses, and nonprofit organizations, and are delivered through multiple divisions, partner agencies, and engagement channels. These engagement channels further underscore the need for systems that support coordinated intake, data sharing, and seamless user experiences across EOED programs.

Despite these coordinated entry points, programs across EOED’s portfolio vary in structure, scale, and statutory requirements, and often operate with distinct application processes, eligibility criteria, timelines, and reporting requirements. While these approaches reflect program-specific needs, they also create opportunities to improve consistency, efficiency, and coordination across EOED’s portfolio, particularly in how applicants and businesses access, navigate, and engage with available resources.

EOED seeks a solution to serve as a full-lifecycle grants management system for EOED, establishing a new platform for the One Stop and the BFD while also supporting other grant and investment programs across EOED’s portfolio. The solution is intended to reduce fragmentation across systems, improve data consistency, and enable enterprise-wide reporting, coordination, and strategic decision-making. It must support diverse program structures and user groups within a unified platform while enabling flexible, program-specific workflows, interfaces, and entry points as appropriate, and ensuring interoperability with existing and future EOED and Commonwealth systems.

a. Procurement Overview EOED is issuing this RFR to solicit proposals from qualified Bidders to provide and implement a vendor-supported, cloud-based grants management system, including all required software licenses, maintenance and support, training, and documentation (collectively, the “Software”). For the purposes of this RFR, EOED seeks a productized software solution that is purpose-built for grants management, maintained and supported by the vendor, and capable of being delivered through a standardized and repeatable implementation model across multiple customers.

The Software will serve as a full-lifecycle, enterprise grants management platform for EOED, supporting the One Stop, the BFD, as well as additional grant and investment programs across the agency’s broader portfolio. The selected solution must be capable of accommodating diverse program structures, statutory requirements, and user groups, while enabling program-specific configurations, workflows, and user experiences, including distinct portals or entry points where appropriate.

EOED seeks a solution that supports configurable workflows, advanced automation, robust data analytics, and a modern, intuitive interface for both applicants and staff. The system must enable seamless coordination across agencies and programs, reduce fragmentation across existing tools, and improve consistency in application intake, review, award management, and reporting. This procurement reflects EOED’s commitment to continuous improvement and to ensuring that the technology supporting the One Stop, BFD, and EOED’s broader portfolio aligns with current best practices and Commonwealth’s long-term digital strategy.

EOED will consider commercial-off-the-shelf, configurable SaaS, and other vendor-supported product models, provided the proposed solution includes core grants management functionality as part of the existing product offering and is not primarily dependent on substantial custom development, bespoke application buildout, or time-intensive configuration of a general-purpose application platform to meet EOED’s core grants management needs. Solutions requiring substantial custom development or implementation approaches that rely primarily on building grants management functionality from a general-purpose application platform will be considered less responsive to this RFR and may receive lower evaluation scores.

b. Initial Use Cases EOED expects the selected Software to support multiple program-specific use cases within an enterprise grants management framework. At launch, EOED anticipates two primary implementation tracks: the Community One Stop for Growth and the Business Front Door.

1. Community One Stop for Growth For the Community One Stop for Growth, EOED seeks a system that will serve as the primary end-to-end grants management platform for applicants, grantees, EOED staff, partner agency staff, and reviewers. External users must be able to access the system directly to register for the One Stop, manage organization and user information, submit applications, receive communications, and manage grant awards.

The system will also serve as the primary tool for program staff to review applications, coordinate across agencies and programs, manage award recommendations, communicate with applicants and grantees, and administer grant awards. Award management activities may include, but are not limited to, processing contracting documents, submitting and reviewing reimbursement requests, submitting required reports, responding to EOED or partner agency requests, uploading supporting documentation, tracking compliance, and completing other activities associated with managing a grant award EOED also expects the Software to be capable of integrating with the One Stop Expression of Interest tool, an externally hosted AI agent built on AWS, so that users may access the tool from the grant portal and relevant feedback may be returned to the grant system for reference.

2. Business Front Door For the Business Front Door (BFD), EOED expects the selected Software to support a grant application experience initiated from the existing BFD platform, which is hosted on Salesforce. Unlike the Community One Stop for Growth, where the grants management system will serve as the primary applicant portal, BFD will remain the primary point of engagement for businesses seeking Commonwealth resources and grant opportunities.

EOED anticipates that BFD users will discover grant opportunities, initiate applications, and access grant-related information through the Business Front Door, with the grants management system providing the underlying grant application and administration capabilities. EOED's objective is to provide businesses with a consistent, intuitive, and seamless experience across both platforms while minimizing unnecessary navigation and duplicate data entry.

EOED expects the proposed solution to support this experience through secure, standards-based integration and configurable capabilities that can be reused across current and future EOED programs without requiring substantial custom development.

c. Functionality and Business Requirements The selected Software will support the end-to-end administration of grants and related program processes, including application intake, review and scoring, award decisions, contracting, grant administration, reporting, and closeout. EOED seeks a solution that improves the usability and accessibility of its programs for applicants while increasing efficiency, consistency, and transparency for EOED staff and participating agencies.

The Software must provide an intuitive applicant experience and configurable tools for staff to manage applications, reviews, awards, contracts, and grant data. EOED seeks a scalable, vendor-supported solution that reduces manual processes, drives efficiencies through artificial intelligence, and can adapt to evolving program needs.

Specifically, EOED seeks a solution that includes the following capabilities:

· Portal Interface

· Software must allow EOED staff to configure most, if not all, portal components, workflows, and user-facing content within a configuration-driven, not development-driven, environment.

· Software must comply with the Commonwealth’s Enterprise Digital Accessibility Policy.

· Note: This includes compliance with Vendor Digital Accessibility Testing Obligations

· Software must use a custom domain that is compliant with the Commonwealth’s Website Domain Policy.

· Software must meet all applicable Commonwealth and EOED security standards.

· Software must adhere to the Commonwealth’s design standards.

· Software must have an intuitive, user-centered, and easy to navigate interface for both external applicants and internal staff.

· Software must support responsive design across modern browsers and devices.

· Software must support program-specific portal experiences, entry points, branding, content, workflows, and user journeys within an enterprise grants management framework.

· Software must support both direct access to the grant portal and user-initiated access from external EOED platforms, including through secure links, buttons, embedded components, APIs, or similar mechanisms.

· Software must support program-specific portal experiences, entry points, branding, content, workflows, and user journeys within an enterprise grants management framework, including distinct experiences for One Stop, BFD, and other EOED programs where appropriate.

· Software must support workflows initiated from external EOED platforms, including BFD, while preserving relevant user, organization, program, and application context, minimizing duplicate data entry, and returning users to the originating platform when appropriate.

· Application Configuration

· Software must allow EOED to configure the application content, workflows, and validation rules within a configuration-driven, not development-driven, environment, with support for advanced configurations when requested.

· Software must support complex conditional logic based on single or multiple prior responses.

· Software must support data-driven logic, including configurable data table lookups and rule-based triggers.

· Software must allow EOED staff to manage the custom data tables.

· Software must allow EOED staff to open and close application submission periods without additional support.

· Application User Experience

· Software must support automatic draft saving and collaborative drafting by multiple users within the same organization.

· Software must allow upload of multiple and large file attachments.

· Software must generate clean, formatted PDF or export versions of submitted applications.

· Software must allow external users to register, manage account and organization information, submit applications, respond to requests for additional information, and access application and award-related materials.

· Software must allow users to manage post-award activities through the system, including contracting documents, reimbursement requests, required reporting, supporting documentation, and other grant management activities.

· Software must support the ability to initiate an application or related workflow from an external system while maintaining a coherent applicant experience.

· Software should support pre-population of application fields using trusted data from external systems, with appropriate user review and confirmation before submission.

· Software must support bi-directional integration with the Business Front Door to enable application initiation, status updates, requests for additional information, and other applicant actions to be surfaced within BFD where appropriate.

· Application Review

· Software must allow program staff to create configurable review forms, scoring criteria, and weighting methodologies.

· Software must support assignment of applications to specific reviewers and/or reviewer groups.

· Software must support assignment of a single application to multiple programs.

· Should support automated routing and assignment to programs, with the ability for manual override.

· Software must allow program staff to assign applications to individual reviewers within their respective groups.

· Software must support the creation of sub-groups within review structures, as needed.

· Software must enable reviewers to view the application and associated review form side by side within a single interface.

· Software must automatically aggregate scores by program, maintaining separate scoring records where multiple programs review the same application.

· Application Approval

· Software must support configurable, multi-level approval workflows (e.g., Program Review → Agency Review → Secretariat Review → Governor Approval).

· Software must provide administrators with a comprehensive, real-time view of recommendations and approval status across all levels.

· Software must allow EOED to create and send automated award decision notifications with customizable, data-populated templates.

· Grant Award Management

· Software must allow programs to create grant agreement templates within the system that can then be populated with applicant information to send for execution.

· Software must allow EOED to create, manage, and track contract amendments.

· Software must include legally binding electronic signature capability for award letters, grant agreements, and other documents.

· Software must allow the grantee to upload reimbursement requests and other required documents directly through the system.

· Software must allow EOED to create workflows to manage disbursement requests.

· Software must allow for budget, payment, reimbursement, and disbursement tracking at both the grant and portfolio levels.

· Software must allow for direct connection between grant awards and outcomes reporting, allowing impact metrics to be associated with individual grants.

· Account Registration and Management

· Software must support applicant authentication through MyMassGov, the Commonwealth’s enterprise single sign-on solution for constituent identity and authentication, via OpenID Connect (OAuth 2.0). MyMassGov provides authentication and does not manage authorization, so software built by the vendor must manage authorization and permissions.

· Software must support internal user authentication through integration with Azure Entra ID as an identity provider for SSO.

· Software must support organizational account structures with configurable, role-based permissions and security controls.

· Software must allow organization profiles to be configured by organization type.

· Software should allow for organizations and user accounts from the legacy system to be prepopulated and later claimed by users.

· Software must support distinct user experiences for different external users and internal roles.

· Software must include a configurable account/organization registration process that is intuitive and easy to use for users.

· Software must include duplicate organization and user detection functionality.

· Software must have an intuitive process to allow applicant organization administrators to add new members to an organization.

· Software must include secure user account emulation capability for authorized administrators for troubleshooting purposes.

· Software must support standards-based identity and access integration patterns that allow user and organization context to be securely transferred between the Business Front Door and the grants management system. Software should minimize the need for users to re-authenticate when transitioning between platforms, where technically feasible and consistent with Commonwealth security standards.

· CRM Capabilities

· Software must allow EOED to configure and manage comprehensive organization profiles within a configuration-driven, not development-driven, environment.

· Software must provide a consolidated, 360-degree view of each organization, including:

· Current and historical applications

· Awards and amendments

· Spending and reimbursement requests

· Reporting status and compliance history

· Communications history

· Software must allow staff to track total funding awarded to an organization across programs and fiscal years.

· Software must allow direct communication with organizations through the portal and keep a record of all correspondence.

· Software must allow authorized staff to create and maintain internal notes associated with organization records.

· Software must allow documents to be uploaded to organization profiles, including external email correspondence.

· Software should support the ability to import application data from the legacy system and tie that data to the respective organization profile.

· Software must support role-based access controls to manage visibility of organization data across programs and agencies, as appropriate.

· Interoperability and Data Standards The Software must support seamless, secure, and scalable integration with external systems, enabling real-time data exchange and coordinated user experiences across EOED platforms and partner systems. The solution should align with the Commonwealth’s enterprise architecture principles and support both current and future integration needs. Specifically, EOED seeks a solution with the following capabilities:

· Standards-Based Integration Architecture

· Software must provide robust, well-documented, and versioned RESTful APIs (and/or equivalent modern integration methods) to support secure, real-time data exchange.

· Software must support industry-standard data formats and integration protocols.

· Software must be designed with extensible architecture that allows for integration with additional systems without significant custom development.

· System Integration Capabilities

· Software must support seamless workflow and data integration with existing EOED and Commonwealth systems, including but not limited to Salesforce, Submittable, AWS-based tools, and Microsoft platforms.

· Software must support data integration with Commonwealth data platforms and reporting tools (e.g., Snowflake, Power BI, ArcGIS, Tableau).

· Software must support user experience and data integrations with EOED and Commonwealth systems, including the One Stop Expression of Interest Tool (built on AWS) and the Business Front Door platform (hosted on Salesforce).

· Software must support secure integration with externally hosted tools and platforms, including the ability to launch external tools from within the grant portal and receive results, feedback, status updates, or other relevant data back into the grants management system.

· Software must support secure integration with Salesforce to allow BFD users, organization records, application records, application statuses, submitted data, and related information to be exchanged between Salesforce and the grants management system.

· Software must support integration patterns that allow EOED to determine whether a user experience is best implemented through direct portal access, secure handoff between systems, embedded components, APIs, or other modern integration methods.

· Software shall provide secure, standards-based, bi-directional integration with Salesforce to support a seamless Business Front Door experience, including application initiation, field pre-population, status synchronization, and ongoing exchange of application data.

· Software must support users returning to the appropriate Business Front Door experience following completion of grant-related workflows while preserving user context where technically feasible.

· Identity and Access Interoperability

· Software must support secure exchange of authenticated user attributes with external systems, enabling trusted user identity to be recognized across platforms.

· Software should support industry-standard identity federation protocols.

· Software must support secure transfer of authenticated user and organization context between systems, subject to applicable Commonwealth security, privacy, and identity management requirements.

· Software should support single sign-on, federated identity, or equivalent methods that reduce the need for users to separately authenticate across EOED systems, where technically feasible and appropriate.

· Cross-System Workflow Initiation

· Software must support the ability for external systems to initiate specific user workflows (e.g., application intake processes) through secure, parameterized links, API calls, or embedded components.

· Software must support the passing of contextual parameters (e.g., user, organization, or program identifiers) to enable continuity of user experience across systems.

· Software must maintain appropriate session continuity or re-authentication handling consistent with Commonwealth security standards.

· Software must support the ability for users authenticated in an external platform, including Salesforce, to initiate a specific application, intake process, or other workflow in the grants management system.

· Software should support the ability for users authenticated in the grant portal to initiate a workflow in an external tool, including the One Stop Expression of Interest tool.

· Data Exchange and Pre-Population

· Software must support the secure ingestion of data from external systems to pre-populate application forms and other records.

· Software must allow configurable field mapping between external data sources and system data fields.

· Software must include validation controls to ensure data integrity and allow user review and confirmation prior to submission.

· Software must support receipt of information generated by external tools, including feedback or results from the One Stop Expression of Interest tool, and make that information available within the grants management system to authorized users.

· Software must support configurable field mapping between Salesforce, externally hosted tools, and grants management system records.

· Software must support appropriate controls to ensure that externally provided or pre-populated information is reviewed, confirmed, validated, and stored in accordance with EOED and Commonwealth requirements.

· Software must support the exchange of application information with Salesforce, including application initiation, field pre-population, submission status, key milestones, requests for additional information, submitted application data, and related metadata.

· Outbound Data Sharing and Synchronization

· Software must support real-time or near real-time sharing of application data, status updates, and key record information with external systems.

· Software must support both event-driven (e.g., webhooks) and request-based (API) data exchange mechanisms.

· Software must allow EOED to configure which data elements are shared with external systems and under what conditions.

· External System Alignment

· Software must support bi-directional data exchange with external CRM platforms, including synchronization of organization records, application data, and status updates.

· Software should support standard CRM integration patterns and tools to minimize custom development and ensure maintainability.

· Data Management and Standards

· API capabilities must support the programmatic creation, retrieval, update, and deletion (CRUD) of core system entities, including organizations, users, applications, grants, and reports.

· Software must support consistent data structures and standards to enable reliable integration and reporting across systems.

· Software must support bulk data import and export capabilities.

· Security and Governance

· All integrations must comply with Commonwealth security standards, including encryption of data in transit and at rest.

· Software must enforce role-based access controls governing data access and system interactions.

· Software must maintain detailed audit logs of all integration activity, including inbound and outbound data exchanges.

· Software must maintain detailed, immutable audit trails capturing user actions, including system activities, record changes, workflow actions, approval history, and integration activity.

· Audit logs must support reporting, filtering, export, and retention consistent with Commonwealth recordkeeping and security requirements.

· Scalability and Future Integration

· Software must be capable of supporting additional integrations with future systems and platforms without requiring significant re-architecture.

· Software should support modular integration approaches to allow EOED to incrementally expand its technology ecosystem.

· Security and Governance

· All integrations must comply with Commonwealth security standards, including encryption of data in transit and at rest.

· Software must enforce role-based access controls governing data access and system interactions.

· Software must maintain detailed audit logs of all integration activity, including inbound and outbound data exchanges.

· Software must maintain detailed, immutable audit trails capturing user actions, including system activities, record changes, workflow actions, approval history, and integration activity.

· Audit logs must support reporting, filtering, export, and retention consistent with Commonwealth recordkeeping and security requirements.

· Scalability and Future Integration

· Software must be capable of supporting additional integrations with future systems and platforms without requiring significant re-architecture.

· Software should support modular integration approaches to allow EOED to incrementally expand its technology ecosystem.

· Automation & AI Capabilities

· Software must support AI integration.

· Software must include AI capabilities to summarize application and other information.

· Software should support AI-assisted tagging of organization or grant records

· Software should support configurable AI tools to assist reviewers in comparing applications against scoring criteria.

· Software should allow tagging, categorization, and auto-classification of organizations and applications.

· Software must clearly identify AI-generated outputs and allow human review and override.

· Software must include configurable workflow automation tools.

· Software should support ongoing AI model updates and performance improvements without disrupting system operations.

· Communications

· Software must allow both mass communications as well as direct communications through the system.

· Software should allow for automated emails to be sent through Commonwealth (mass.gov) email addresses and domains.

· Software must have ability to save and reference communications at the organization level.

· Software must have ability to create automated notifications to alert users of upcoming due dates and other critical reminders.

Reporting & Dashboards

· Software must include built-in reporting tools and configurable dashboards.

· Software must allow for both simple and complex data reporting without external integration or complex programming.

· Software must allow data to be represented through a variety of graphs and charts.

· Software should support drill down functionality within graphs and charts.

· Software must allow Ad hoc reporting capabilities for authorized users.

· Software must allow dashboards to be configured for different roles.

· Software must allow for aggregate KPI/outcomes reporting across programs.

· Software must allow customized downloads of reports into multiple formats (i.e., PDF, XLSX, CSV, etc.).

As indicated above, the Software will be used by both internal, administrative users as well as external applicants and grantees. EOED estimates the following volumes of users:

Internal Admin Access

External Grantee Access

2. Scope of Work The scope of this procurement includes the initial implementation and ongoing maintenance, support, and enhancement of the Software, including all required software licenses, hosting, maintenance and support, training, and documentation. The selected Contractor will be expected not only to deploy the Software, but to provide sustained operational and development support to ensure the platform continues to evolve in alignment with EOED’s programmatic, technical, and regulatory needs.

This includes:

· Professional services associated with implementation, including installation, configuration, system design, development, quality assurance, testing, data conversion and migration, integration, and other related services necessary to achieve a fully operational production environment.

· Managed services associated with ongoing hosting, storage, security management, help desk operations, troubleshooting, system upgrades, and performance monitoring.

· Ongoing development and configuration support to accommodate complex enhancements, evolving business requirements, new program additions, cross-agency coordination needs, reporting modifications, automation improvements, and other iterative system refinements. EOED anticipates that the Software will require periodic reconfiguration and structured enhancement releases to support continuous improvement of program processes.

· The Contractor shall collaborate with the Business Front Door implementation team throughout design, implementation, testing, deployment, and ongoing operations to ensure successful integration and coordinated delivery.

Additionally, EOED is seeking comprehensive training services and materials for both internal and external users, including the training of at least two internal staff members to deliver future training and support. Ongoing help desk services must provide timely technical assistance to applicants during application submission and to EOED and participating agencies in connection with review, reporting, compliance, and data extraction activities.

3. Project Timeline The project is expected to follow the timeline below:

Community One Stop for Growth:

· Grant Portal fully configured, with required design components incorporated

· Custom Mass.gov domain assigned

· Accessibility requirements met

· Organization profiles configured

· MyMass.gov SSO integration

· Expression of Interest integration 01/15/2027

4. Technical Requirements

The Bidder's proposed Software should meet all the requirements specified in:

1. SaaS Terms: Attachment G-1 for Bidders on ITS60, or Attachment G-2 for Bidders on ITS75 or partnering with ITS75 Resellers

2. The Commonwealth’s Enterprise Information Security Standards and Policies

3. The Commonwealth’s Vendor Digital Accessibility Contract Language

Additionally, Bidder Software should support:

1. Mobile Ready Design and Access Software should be mobile-ready and user-friendly via web browsers on phones, tablets, and other devices in addition to personal computers and laptops. The Software should be able to be accessed through today's leading web browsers, including, but not limited to Google Chrome, Safari, and Microsoft Edge.

2. Enterprise Services The Commonwealth is transitioning from siloed, application-centric, and agency-centric IT investments to an enterprise approach. The Software should implement an extensible, flexible, scalable, and secure architecture on a platform that uses industry standards and standardized integration points. To promote the reuse and sharing of services across the Commonwealth, the Software effort may leverage existing and emerging components and services.

5. Applicable Procurement Law

Executive Branch Goods and Services

6. Acquisition Method:

7. Whether Single or Multiple Contractors are Required for Contract:

Check One (“X”):

a. Estimated Number of Awards The target maximum number of Contractors is one the Purchasing Department may award more or fewer contracts, if it is in the best interests of the Commonwealth to do so.

b. Adding Contractors after initial Contract Award If, over the life of the contract, the Purchasing Department determines that additional Contractors may be added, these may be drawn from qualified companies that responded to this Solicitation and not awarded Contracts. If necessary to meet the requirements of the Commonwealth, the Solicitation may be reopened to obtain additional Bids.

8. Entities Eligible to Use the Resulting Contract:

· Office of Consumer Affairs

9. Expected Duration of Contract (Initial Duration and any Options to Renew):

Initial Duration

From the Effective Date through June 30, 2027, estimated to be approximately nine (9) months if the contract begins on or around October 1, 2026.

Total Maximum Contract Duration

June 30th, 2031, if all renewal options are exercised.

10. Contract Performance and Business Specifications:

a) Scope of Services: The scope of this procurement includes the initial implementation and ongoing maintenance, support, and enhancement of the Software, including all required software licenses, hosting, maintenance and support, training, and documentation. The selected Contractor will be expected not only to deploy the Software, but to provide sustained operational and development support to ensure the platform continues to evolve in alignment with EOED’s programmatic, technical, and regulatory needs.

This includes:

· Professional services associated with implementation, including installation, configuration, system design, development, quality assurance, testing, data conversion and migration, integration, and other related services necessary to achieve a fully operational production environment.

· Managed services associated with ongoing hosting, storage, security management, help desk operations, troubleshooting, system upgrades, and performance monitoring.

· Ongoing development and configuration support to accommodate complex enhancements, evolving business requirements, new program additions, cross-agency coordination needs, reporting modifications, automation improvements, and other iterative system refinements. EOED anticipates that the Software will require periodic reconfiguration and structured enhancement releases to support continuous improvement of program processes.

Additionally, EOED is seeking comprehensive training services and materials for both internal and external users, including the training of at least two internal staff members to deliver future training and support. Ongoing help desk services must provide timely technical assistance to applicants during application submission and to EOED and participating agencies in connection with review, reporting, compliance, and data extraction activities.

b) Project Timeline The project is expected to follow the timeline below:

Community One Stop for Growth:

· Grant Portal fully configured, with required design components incorporated

· Custom Mass.gov domain assigned

· Accessibility requirements met

· Organization profiles configured

· MyMass.gov SSO integration

· Expression of Interest integration 01/15/2027

Business Front Door:

c) Technical Requirements The Bidder's proposed Software should meet all the requirements specified in:

1. SaaS Terms: Attachment G-1 for Bidders on ITS60, or Attachment G-2 for Bidders on ITS75 or partnering with ITS75 Resellers

2. The Commonwealth’s Enterprise Information Security Standards and Policies

3. The Commonwealth’s Vendor Digital Accessibility Contract Language

Additionally, Bidder Software should support:

· Mobile Ready Design and Access Software should be mobile-ready and user-friendly via web browsers on phones, tablets, and other devices in addition to personal computers and laptops. The Software should be able to be accessed through today's leading web browsers, including, but not limited to Google Chrome, Safari, and Microsoft Edge.

· Enterprise Services The Commonwealth is transitioning from siloed, application-centric, and agency-centric IT investments to an enterprise approach. The Software should implement an extensible, flexible, scalable, and secure architecture on a platform that uses industry standards and standardized integration points. To promote the reuse and sharing of services across the Commonwealth, the Software effort may leverage existing and emerging components and services.

Fiscal Terms:

BILLS MUST BE PAYABLE IN ACCORDANCE WITH CTR’S BILL PAYMENT POLICY);

COMMONWEALTH IS TAX EXEMPT, PROMPT PAYMENT DISCOUNTS AND/OR NET TERMS ARE REQUIRED)

11. Small Business Purchasing Program Program Background The Massachusetts Small Business Purchasing Program (SBPP) was established pursuant to Executive Order 599to increase state contracting opportunities with small businesses having their principal place of business within the Commonwealth of Massachusetts. Pursuant to the SBPP, it is the intention of the issuing department to award this Small Procurement to one or more SBPP participating business(es) as described below.

SBPP Award Preference While all businesses, no matter the size or principal place of business, may submit responses to this solicitation, should an SBPP participant respond and meet the best value criteria as described in this solicitation, the SBPP participant shall be awarded the contract. The Strategic Sourcing Services Team (SSST) will not evaluate submissions from non-SBPP participants unless no SBPP Bidder meets the SSST’s best value evaluation criteria.

SBPP Participation Eligibility To be eligible to participate in this procurement as an SBPP participant, an entity must meet the following criteria, and be marked as an SBPP-registered business in COMMBUYS:

1. Have its principal place of business in the Commonwealth of Massachusetts;

2. Been in business for at least one year;

3. Employ a combined total of 50 or fewer full-time equivalent employees in all locations, or employees work less than a combined total of 26,000 hours per quarter; and

4. Have gross revenues, as reported on appropriate tax forms, of $15 million or less, based on a three-year average.

Non-profit firms also must be registered as a non-profit or charitable organization with the MA Attorney General’s Office and be up to date with all filings required by that office and be tax exempt under Section 501(c) of the Internal Revenue Code.

SBPP Compliance Requirements It is the responsibility of the Bidder to ensure that their SBPP status is current at the time of submitting a response and throughout the life of any resulting contract. Misrepresentation of SBPP status will result in disqualification from consideration, and may result in debarment, contract termination, and other actions. To learn more about the SBPP, including how to apply, visit the SBPP Webpage.

Program Resources and Assistance Bidders and Contractors seeking assistance regarding SBPP may visit the SBPP webpage, http://www.mass.gov/sbpp, or contact the SBPP Help Desk at sbpp@mass.gov.

12. Supplier Diversity Plan (SDP) Plan Program Background Pursuant to Executive Order 599 the Commonwealth’s Supplier Diversity Program (SDP) promotes business-to-business relationships between awarded Contractors and diverse businesses and non-profit organizations (“SDP Partners”) certified or recognized (see below for more information) by the Supplier Diversity Office (SDO).

All Bidders and Contractors are strongly encouraged to create a profile on the SDO’s Supplier Diversity Hub to access the Commonwealth’s supplier diversity resources and tools.

Financial Commitment Requirements All Bidders responding to this solicitation are required to make a significant financial commitment (“SDP Commitment”) to partnering with one or more SDO-certified or recognized diverse business enterprise(s) or non-profit organization(s). This SDP Commitment must be expressed as a percentage of contract sales resulting from this solicitation that would be spent with the SDP Partner(s).

After contract award (if any), the Total SDP Commitment shall become a contractual requirement to be met annually on a Massachusetts fiscal year basis (July 1 – June 30) for the duration of the contract. The minimum acceptable Total SDP Commitment in response to this solicitation shall be 1%. Bidders shall be awarded additional evaluation points for higher SDP Commitments.

No contract shall be awarded to a Bidder without an SDP Commitment that meets the requirements stated herein. This requirement extends to all Bidders regardless of their own supplier diversity certification. Eligible SDP Partner Certification Categories SDP Partners must be business enterprises and/or non-profit organizations certified or recognized by the SDO in one or more of the following certification categories:

· Minority-Owned Business Enterprise (MBE)

· Minority Non-Profit Organization (M/NPO)

· Women-Owned Business Enterprise (WBE)

· Women Non-Profit Organization (W/NPO)

· Veteran-Owned Business Enterprise (VBE)

· Service-Disabled Veteran-Owned Business Enterprise (SDVOBE)

· Disability-Owned Business Enterprise (DOBE)

· Lesbian, Gay, Bisexual, and Transgender Business Enterprise (LBGTBE) Eligible Types of Business-to-Business Relationships Bidders and Contractors may engage SDP Partners as follows:

· Subcontracting, defined as a partnership in which the SDP partner is involved in the provision of products and/or services to the Commonwealth.

· Ancillary Products and Services, defined as a business relationship in which the SDP partner provides products or services that are not directly related to the Contractor’s contract with the Commonwealth but may be related to the Contractor’s own operational needs. These may include but are not limited to the following examples: professional services (e.g., IT, legal, advertising, HR, accounting etc.), maintenance services (e.g., cleaning, landscaping, tradespersons services, etc.), office expenses (e.g., office supplies, furniture, IT supplies, etc.). Anything declared as a business expense in which a certified vendor is used would qualify.

Other types of business-to-business relationships are not acceptable under this contract. All provisions of this RFR applicable to subcontracting shall apply equally to the engagement of SDP Partners as subcontractors.

Program Flexibility The SDP encompasses the following provisions to support Bidders in establishing and maintaining sustainable business-to-business relationships meeting their needs:

· SDP Partners are not required to be subcontractors.

· SDP Partners are not required to be Massachusetts-based businesses.

· SDP Partners may be changed or added during the term of the contract, provided the Contractor continues to meet its SDP Commitment.

SDP Plan Form Requirements All Bidders must complete the SDP Plan Form included in this solicitation and attach it to their bid response. In addition to proposing an SDP Commitment, each Bidder must propose one or more SDP Partner(s) to utilize to meet its SDP Commitment. Certified diverse Bidders may not list their own companies, their subsidiaries, or affiliates, as SDP Partners and may not meet their SDP Commitment by spending funds internally or with their own subsidiaries or affiliates.

Bidders may propose SDP Partners that are:

· Certified or recognized by the SDO: Such partners appear in the SDO Directory of Certified Businesses or in the SBA Veteran Small Business Certification (VetCert) directory. After contract award (if any), spending with such partners will contribute to meeting the Contractor’s SDP Commitment.

· Certified by one of SDO’s recognized third-party certification bodies but not yet listed in the SDO Directory of Certified Businesses: Such partners must be certified in eligible categories by one of SDO’s recognized third-party certification bodies, which include the City of Boston, the Greater New England Minority Supplier Development Council (GNEMSDC), the Center for Women & Enterprise (CWE), Disability: IN, National LGBT Chamber of Commerce (NGLCC), or the National Veteran Owned Business Association (NaVOBA) but have not yet opted to be listed in the SDO Directory of Certified Businesses. In order to opt into SDO’s Directory of Certified Businesses, the SDP partner must follow the applicable expedited instructions on SDO’s Apply for Recognition as a Third-Party Certified Business webpage. Self-certification is not acceptable. While Bidders may list such proposed SDP Partners on their SDP Plans, spending with such partners will not contribute to meeting the Contractor’s SDP Commitment unless they apply for and are granted SDO supplier diversity certification or recognition. If proposed SDP Partners do not receive SDO supplier diversity certification or recognition, the Contractor must find alternative SDP Partners to meet the SDP Commitment.

· Not yet certified or recognized by the SDO or one of SDO’s recognized third-party certification bodies: Such partners must be certified in eligible categories by other third-party certification bodies that are not yet recognized by the SDO, such as another city or state supplier diversity certification office, the National Minority Supplier Development Council, or the Women Business Enterprise National Council, but are not listed in the above-mentioned directories. Self-certification is not acceptable. While Bidders may list such proposed SDP Partners on their SDP Plans, spending with such partners will not contribute to meeting the Contractor’s SDP Commitment unless they apply for and are granted SDO supplier diversity certification or recognition. If proposed SDP Partners do not receive SDO supplier diversity certification or recognition, the Contractor must find alternative SDP Partners to meet the SDP Commitment.

It is the responsibility of the Contractor to ensure that their proposed SDP Partners obtain such certification or recognition by the SDO after contract award (if any). The issuing department and the SDO will not conduct outreach to proposed SDP Partners to ensure their certification. Furthermore, no guarantee may be made that a proposed SDP Partner will be certified, or regarding the time it may take to process a proposed SDP Partner certification. Contractors may direct partners to the SDO’s homepage, www.mass.gov/sdo and the Certification Self-Assessment Tool for guidance on applying for certification.

It is desirable for Bidders to provide a description of supplier diversity businesses practices. Specifically, listing contact information for the individual or unit responsible for establishing and maintaining supplier diversity relationships, and including a written policy for establishing and maintaining supplier diversity relationships.

It also is…