Addendum 1 RFP55-091826-Communications Management System-Q&AsUpdates.pdf

ADDENDUM #1: RFP55-091826_Communications Management System-Questions & Answers/RFP

Updates

STATE OF NORTH CAROLINA

Appalachian State University

Refer ALL Inquiries regarding this RFP to:

Lori Brown Email: brownlg2@appstate.edu

PH: 828-262-8130

Request For Proposal # RFP55-091826

Bids will be publicly opened: Oct. 23, 2026 @ 2:00 pm

Contract Type: Open Market

Commodity Description: Communications Management System Using Agency: Appalachian State University

This addendum is issued to:

RFP55-091826_Communications Management System RFP Updates:

Following the review of all submitted bids, Appalachian State University will reach out to selected vendors once the finalist list has been determined. Finalists and the Department will then be given the opportunity to ask additional clarifying or detailed questions.

Error in ATTACHMENT A: FINANCIAL PROPOSAL

ATTACHMENT A: FINANCIAL PROPOSAL

Please attach your Financial Proposal and label as: Attachment A: Financial Proposal (See Attached Financial Proposal Template) There is no Financial Proposal Template available. Vendors must provide a complete pricing/fee structure when submitting bids.

Questions and Answers:

RFP Section / page #

Vendor Question/Response

4.4 Vendor

Experience, Page Soc D

If the proposed Communications Management System is provided and supported by a disclosed subcontractor/technology partner, may the experience and qualifications of that subcontractor be included in the Vendor's demonstration of experience with public or private sector clients of similar or greater size and complexity?

No. App State intends to contract directly with the company that owns, provides, and supports the proposed Communications Management System. Experience used to demonstrate similar or greater size and complexity must be that of the proposing Vendor itself, not of a subcontractor, reseller, or technology partner.

Vendor Question/Response

4.5 References, Soc D

If the proposed Communications Management System is provided by a disclosed subcontractor/technology partner, may customer references for that subcontractor be submitted to satisfy the requirement for three references for which the Vendor has supplied the exact model of services offered?

No. The three references must be for clients of the proposing Vendor, for whom the Vendor has directly provided the exact model of services offered in this proposal.

References for a subcontractor or technology partner will not satisfy this requirement.

4.7 Personnel, Page 12–13

May personnel employed by a proposed technology subcontractor be identified as part of the project team and used to demonstrate the technical, implementation, integration, and professional experience required under this section?

Proposed project team members, including those used to demonstrate technical, implementation, integration, and professional experience, should be employees of the proposing Vendor.

4.10 Subcontractors, Is a Vendor permitted to propose a technology platform provider as a subcontractor that will provide the underlying software platform, implementation, integration, training, and technical support, while the proposing Vendor remains the prime contractor and retains full responsibility for contract performance?

No. App State intends to contract directly with the company that owns, provides, and supports the proposed Communications Management System. The proposing Vendor must be the owner or developer of the platform, or a wholly owned parent or subsidiary of that entity (relationship disclosed in the proposal), and must itself provide the software platform, implementation, integration, training, and ongoing technical support. Limited use of subcontractors for ancillary services (for example, SMS carrier connectivity or infrastructure hosting) must be disclosed in the proposal, and the Vendor remains fully responsible for their performance.

RFP Section 5.1, Page 14:

E 451

Appalachian State requires a "parent/child sub-account structure" and requests unlimited sub-accounts. Please describe the intended use of a sub-account. Is the University seeking separate organizational workspaces for individual colleges/departments with independently managed branding, sender configuration, data visibility, users/permissions, and reporting, or is the requirement primarily intended to provide centralized administration with role-based access for decentralized campus communicators?

Primary centralized administration with role-based sub-account access to build messages, send for approval, view data and reporting. List management is under discussion.

E 451

Should constituent data remain unified across all sub-accounts, or is App State expecting constituent records and/or audience data to be partitioned by sub-account?

Ideally, records would be partitioned by sub-account or role-based access, not allowing members in the platform to find information from other divisions

E 451

Approximately how many colleges, divisions, departments or other campus units are expected to use the system at launch?

Three

RFP Section 5.1, Page 14:

E. 451

Which existing email, SMS, or communications platforms does App State expect the selected solution to consolidate or replace?

Encora/Anthology

Vendor Question/Response

RFP Section 5.1, Page 14:

E 451

For Banner-driven dynamic audiences, which Banner populations and data objects must be available for segmentation and communications?

Banner IDs email addresses

Pages 14-15:

E 451

Does App State require near-real-time, scheduled, or both forms of Banner synchronization? Is bidirectional data exchange required, or is the principal requirement for Banner to supply and continuously update constituent and audience data in the communications platform?

1. At least one form of Banner synchronization is required - what we are asking is the cadence of synchronization - scheduled (nightly), real-time, etc

2. Bidirectional is not required

E 451

For the requested "master send calendar," is App State seeking a consolidated calendar displaying scheduled communications across all participating departments/sub-accounts and channels? If so, what information and administrative controls should be available from that calendar?

Yes, a consolidated calendar displaying scheduled communications across all participating departments/sub-accounts and channels. We may want to structure it so that only certain roles can schedule and send messages. Sub-account managers could request a specific send date.

E 451

Please describe the desired message approval workflow. Must a message be electronically submitted to an approver and prevented from sending until approval is recorded, or would role-based controls over who may create, edit, and send communications satisfy this requirement?

This may vary. Ideally, there would be role-based controls that allow different levels of abilities from content creation to sending and with those controls, a tier, for an approver level to review content before it is sent (whether the approver releases the message or allows the content creator to send)

There will be approvers who do not have system access. There needs to be a way to send a test to them, probably via email, for review/approval. In this instance, an admin would manage approval documentation.

Page 15:

E 451

For the requested development/test sandbox, does App State require an environment synchronized with production configuration and/or data, or would a separate non-production environment for configuration and integration testing satisfy the requirement?

Either would satisfy the requirement

5.1 Specifications, Page 14–16

Please identify the current Banner environment/version and the available or preferred integration method(s) for establishing the required dynamic-list integration. Will App State provide the necessary technical documentation, API/interface specifications, and access required for the awarded Vendor to develop and maintain the integration?

Banner 9. Push of data from us to them only. API or scheduled batch integration.

Please identify the current communications/email management platform(s) from which App State anticipates transitioning under this RFP.

Encora/Anthology, www.encoura.org/anthology

Vendor Question/Response

5.1 Contract

Basis, Page

App State states a preference for pricing based on email sends rather than contacts, while also requesting locked-in pricing levels of 250,000, 300,000, 350,000, 400,000, and unlimited contacts. Should vendors provide a complete-package price based primarily on email sends, with the specified contact levels provided as supplemental pricing, or is App State expecting pricing at each of the five contact levels regardless of the preferred send-based model?

App State prefers a contract priced on email sends rather than contacts. Vendors whose standard pricing model is send-based should submit a complete-package price on that basis, and are not required to provide the five contact-level prices. Vendors whose pricing model is contact-based must submit a complete-package price at each of the following locked-in levels: 250,000; 300,000; 350,000; 400,000; and unlimited contacts. A vendor may offer both models, clearly labeled, and App State will evaluate each as submitted. In all cases, pricing must be a complete package.

5.1 Contract

Basis, Page

Please provide, if available, an estimated annual volume of SMS/text messages expected under the resulting contract so that vendors can accurately develop the complete-package pricing requested by App State.

App State has not previously used SMS/text messaging and cannot provide a reliable estimate of annual volume. Vendors should include SMS in the complete-package price based on a stated assumption of usage, and must clearly document that assumption. In addition, vendors must provide a fixed per-message rate (or tiered rates by volume band) that will remain locked for the three-year initial term, so that App State can add volume without renegotiation. Vendors should state what is included in the base package, how and when additional volume is charged, and whether any carrier, registration, or compliance fees apply.

For the requested email and SMS functionality, may the proposed solution consist of an integrated combination of products/services from a prime Vendor and disclosed technology subcontractor(s), provided that the resulting solution operates as a unified communications management system meeting all RFP requirements?

App State intends to contract with a single company that owns or develops, provides, and supports the proposed Communications Management System, including both email and SMS functionality.

For the requested Banner integration, is App State seeking a one-way integration from Banner to the Communications Management System for dynamic lists, or is bidirectional data exchange required?

Bi-directional is not required

5.1 Technical

Considerations, For purposes of responding to the technical considerations, may vendors describe capabilities that are available through APIs or integrations provided by the proposed technology platform or its approved subcontractors?

Yes, with conditions. Vendors may describe capabilities available through APIs or integrations provided by the proposed platform, including integrations with third-party systems such as Banner. For each capability described, the Vendor must state whether it is native to the proposed platform or delivered through an API or integration, and whether it is included in the proposed package price or carries additional cost.

Additional subcontractor pricing would need to be included

Additional subcontractor partners may require additional security and accessibility review

Vendor Question/Response

4.3 Financial

Stability, p. 11

Does App State require the prime Vendor to demonstrate a particular minimum level of annual revenue, net worth, liquidity, bonding capacity, or other financial threshold beyond the certification required in Attachment G?

All requirements are listed in the bid document

4.9 Insurance

Requirements, p.

Please confirm the applicable insurance coverage and limits for this solicitation, given that Section 4.9 identifies the contract as being in excess of the Small Purchase threshold but up to $1,000,000.

The total contract coverage should reflect the total contract value

General Question

– no reference mentioned.

SEVRA

Please confirm whether an international software firm may participate provided it registers through the North Carolina eVP, and whether the requirement for three references must be for the exact same communications-management platform or can include comparable enterprise software/automation deployments?

• Yes. International firms may participate provided they successfully complete vendor registration through the North Carolina Electronic Vendor Portal (eVP) and meet all state legal, tax, and procurement requirements.

• We would prefer primary references be for the specific email marketing/communications platform proposed in your response. However, offerors may submit additional supplemental references for comparable enterprise software or automation deployments to further demonstrate their technical capabilities and expertise. Comparable deployments will not be accepted as substitutes for the primary product references.

5.1, Scope of Work, p.14

What solution are you currently using for SMS messaging?

• We do not currently have a widely available SMS application or routine communication via SMS

• We do not currently feel like we can accurately estimate

• If there are tiered options for this additional communication channel, provide more than one tier option in pricing

• Please describe how you handle SMS consent, opt-out management and carrier registration

5.1, Scope of Work, p.14

Is digital signage included in the initial implementation, or is it planned for a later phase?

• It could be included at a later phase, but we would like to know/understand pricing and implementation options

• We would like the option to add signage later without renegotiating if the addition is made in our first contract term

5.1, Technical considerations, p.

We can provide a test sandbox after contract execution, during implementation. Does this meet your expectations for sandbox access?

• Yes, please state the duration and any limitations

5.1, p. 14

Are built-in video captioning and color contrast checks mandatory Requirements?

• While they are not mandatory, they are advantageous if available

• The platform itself must meet WCAG 2.1 Level AA.

• Built-in tools to help content creators check alt text, captions, and contrast are strongly preferred but not required

5.1, p. 14

Users can send test emails to themselves to review rendering, including responsive layouts and light and dark modes. Would this meet your requirement for email previews?

• Yes, this would meet the minimum requirements.

• The ability to send to oneself and external approvers is preferable for the review process.

• If there is the ability to review while in edit modes within the platform, this would also meet the need and be more ideal, but not required.

5.1, Technical considerations, p.

What additional security or IT acquisition requirements will vendors need to meet? Will App State provide the applicable requirements or questionnaires and when will those reviews occur in the evaluation and implementation timeline?

• We will provide the applicable requirements and questionnaires for this stage of evaluation.

• Award is contingent on passing the IT Acquisition Review.

• Appalachian State University requires all software and cloud service acquisitions to undergo a formal IT Acquisition Review conducted by Information Technology Services (ITS) and designated IT Governance Teams.

• Applicable Requirements & Documentation Needed: Vendors will be required to demonstrate compliance with State, Federal, and University information security and digital accessibility standards. Depending on the software scope and classification of data handled, vendors may be asked to provide:

• Information Security Review: Completion/submission of a Higher Education Community Vendor Assessment Tool (HECVAT), SOC 2 Type II report, or equivalent third-party security attestation, along with proof of compliance with regulatory frameworks (e.g., FERPA, PCI-DSS, ISO 27002, where applicable).

§ Digital Accessibility Review: Documentation confirming compliance with accessibility standards (such as a Voluntary Product Accessibility Template / VPAT or ACR matching WCAG 2.1 AA guidelines).

§ Data Stewardship & Governance Review: Verification of data retention, encryption protocols, and subprocessor disclosure if sensitive or confidential University data is processed.

• Timeline & Process: Applicable questionnaires, request forms, and document requests will be provided to the top-evaluated offeror(s) following the initial proposal review phase. Formal security, accessibility, Vendor Question/Response and architectural risk assessments are conducted in tandem by specialized ITS review teams prior to final contract execution and implementation.

• To see more about our process, visit our website:

https://its.appstate.edu/acquisitions-purchases/process

5.1, Contract Basis, p.16

For purposes of pricing, can App State provide its current annual email send volume and anticipated annual email send volume over the initial three-year contract term, including both internal and external communications?

• Current annual email campaign sends:

o Estimated internal: 500 o Estimated external: 1200

• Anticipated: This is hard to predict since we will be opening the system up to areas that we have no current data on. The goal is to consolidate and reduce redundant and shadow systems across our campus and offer an Enterprise email solution, which we have not been able to do before.

• We would anticipate growth each year in the number of sends.

5.1, pp.14–16 Please provide App State’s current annual SMS/text message volume and anticipated annual SMS volume, including approximate number of recipients and messages per campaign.

• Since this is not a service we have had available previously, this is a hard figure to guesstimate.

• We would like pricing that includes options for this additional capability.

When App State states that pricing should be a “complete package of services” with “no à la carte pricing,” should vendors include email, SMS, digital signage, implementation, integrations, training, support, and ongoing services within one total price, or should optional channels such as digital signage be separately identified and priced?

• We appreciate a price with all components included but itemized to understand the breakdown of the contract.

• Proposals must include one total price for the required components.

Optional channels such as digital signage and SMS should be priced separately and clearly marked as optional.

For the requested 250K, 300K, 350K, 400K and unlimited contact levels, should vendors provide pricing for each tier for each year of the initial three-year term, or a single annual price per tier?

• A single annual price per tier is acceptable

• If any costs will increase over the course of the three-year contract based on the tier, then yes, this should also be included

• Describe your approach and pricing for each tier in your proposal.

1.1 & 5.1

Given the expected 10–15% annual growth in external contacts, how should App State expect pricing to be handled if contact volume moves from one locked-in tier to another during a contract year—at renewal, immediately upon exceeding the tier, or through another mechanism?

• Vendors submitting contact-based pricing models should identify and include their proposed growth adjustment mechanism. To ensure clear cost predictability as contact volume increases over the initial 3-year term, vendors must provide pricing across all five locked-in contact tiers (250K, 300K, 350K, 400K, and Unlimited) specified in RFP Section 5.1.

5.1, p.16 For in-development or soon-to-launch functionality, is App State requesting that all future product functionality be included at no additional charge, or only functionality associated with the capabilities/modules included in the awarded solution?

• The University expects functionality generally available within the modules and products included in the awarded solution to be included at no additional charge during the contract term, including features released during the term.

• Please identify any separately priced new products or add-on modules that are not automatically included and their pricing in your proposal.

§ 5.1, Specifications / Scope of Work,

pp. 14–15. The Banner integration requirement is on

p. 14; the technical integration questions are on

p. 15.

1. Banner Integration: Please describe the current Banner environment and integration methods available to the selected platform, including APIs, database views/extracts, file-based interfaces, middleware, or existing data feeds that App State expects the selected vendor to leverage.

a. The current system is Banner 9. Integration is a one-way data push from App State (Banner) to the communications platform via daily scheduled batch extracts or REST APIs.

§1.0, Purpose and Background, p.

5; §1.1, Contract Term, p. 5; §5.1, Specifications / Scope of Work,

p. 14.

2. Migration Scope: Please identify the communication platforms currently in use and clarify what App State expects to migrate, including contacts, preferences/subscriptions, suppression lists, templates, campaigns, historical engagement data, and reporting history.

a. Encora/Anthology i.We do not anticipate migrating templates; we will likely be rebuilding in a new platform ii.Communication, engagement, reporting and data will be in Banner, our system of record iii.Contacts are fed from Banner to our current system, and so the feed will have to be re-established with a new solution, but preferences/subscriptions, etc.

will already be on record iv.There will be no direct transfer from the previous system.

Vendor Question/Response

§5.1, Specifications / Scope of Work,

pp. 14–16, especially the email-send preference on p.

15 and Contract basis on p. 16

3. Email Volume: Please provide approximate annual email volume and, if available, peak monthly volume across the platforms App State intends to consolidate. This will help vendors respond consistently with the University's stated preference for send-based rather than contact-based pricing.

a. Annual Email campaign volume i.Current:

1. Estimated internal: 500

2. Estimated external: 1200

b. Anticipated volume – This is hard to predict since we will be opening the system up to areas that we have no current data on. The goal is to consolidate and reduce redundant and shadow systems across our campus and offer an Enterprise email solution, which we have not been able to do before.

c. Peak months: August, September, October, February, March

Financial Proposal, p. 11;

§5.1, Contract basis, p. 16;

Attachment A:

Financial Proposal, p. 19.

The financial section is §4.1 in the contents but §5.1 in the body.

4. Implementation & Services Pricing: For Attachment A, should vendors include all one-time professional services associated with implementation, integration, configuration, migration, training, testing, and go-live, or is Attachment A intended primarily to capture software/subscription costs?

a. Yes, please include and itemize for explanation of all one-time services involved in launching with your new platform and support with the contract.

b. Include what is required and what is optional

§1.1, Contract Term, p. 5; RFP Schedule, p. 6;

§5.3, Technical Approach, p. 16.

The RFP anticipates an award before the end of 2026 but gives no production go-live date.

5. Implementation Timeline: Does App State have a target production go-live date or preferred implementation window? Are there academic-calendar or institutional milestones vendors should consider when proposing implementation phases and sequencing?

a. Before Dec. 31, early Nov. for access to the platform at least is preferred, with a tiered approach to rollout for our campus.

b. Our one day of Annual giving happens in March

§1.1, Contract Term, p. 5.

6. Transition / Bridging: Does App State anticipate a period of parallel operation between its current communications platforms and the selected solution? If so, what transition period should vendors consider for planning and pricing?

a. We do anticipate some parallel operation for roughly 1, maybe 2 months

b. The transition period from one platform to the other for our core teams will take roughly 2-3 months

Vendor Question/Response

Vendor eVP# form, unnumbered page immediately after the cover;

Proposal Submittal, pp. 6– 7; Proposal Contents, p. 7.

7. North Carolina Vendor Registration: The RFP states that a company must be a North Carolina registered Vendor in good standing for a contract to be awarded. Is NC vendor registration/eVP good-standing status required at the time of proposal submission, or may an otherwise responsive vendor complete the required registration prior to contract award? Would not having the required North Carolina registration at the time of submission preclude a vendor from being evaluated or considered for award?

a. Vendor must be registered on eVP before bid submittal.

Execution, pp. 1– 2; Proposal Contents, pp. 7– 8; §7.0, Attachments, pp.

19–20.

8. Other NC Registration / Certifications: Beyond eVP registration and the certifications/forms expressly identified in the RFP, are there any additional North Carolina registrations, certificates of authority, licenses, or other state-specific qualifications that must be in place at the time of proposal submission rather than prior to contract execution/award?

a. Vendors must complete standard state business licenses and certificates of authority before final contract execution.

§5.1, Specifications / Scope of Work,

pp. 14–15.

9. Banner Data & Dynamic Audiences: What Banner data elements does App State anticipate making available to the platform, and are there specific dynamic audience use cases that should be prioritized during implementation?

a. Key data elements include Banner IDs, first/last names and email addresses, along with student/employee status and organizational qualifiers.

b. Priority dynamic audience use cases include segmented communications for internal campus groups and targeted external stakeholder outreach.

§5.1, Specifications / Scope of Work,

p. 14; Contract basis, p. 16.

10. SMS Scope: Please provide anticipated SMS use cases and estimated message volumes. Should vendors include SMS consumption within the base financial proposal or separately identify usage-based SMS costs?

a. SMS is a new channel with no historical volume. Vendors should provide fixed per-message or tiered volume rates locked for the 3-year term, with clear documentation of base assumptions.

§1.0, Purpose and Background, p.

5; §5.1, Specifications / Scope of Work,

p. 14.

11. Campus Governance: Approximately how many departments, colleges, or administrative units are expected to actively use the platform at launch, and does App State envision centralized governance with distributed content creation/sending or greater autonomy by individual units?

a. Two campus units are expected at launch.

b. We expect to onboard other campus units as soon as possible. Major campus units and academic colleges are priorities.

c. The University requires centralized administration with role-based access for decentralized campus communicators.

Vendor Question/Response

§5.1, Specifications / Scope of Work,

p. 14; Contract basis, p. 16.

12. Digital Signage: Digital signage is identified as preferred rather than required.

Should vendors include digital signage in the base proposal, or may it be identified as an optional/future capability without negatively impacting responsiveness?

a. Digital signage is preferred rather than mandatory at launch. Vendors should price digital signage separately as an optional channel without impacting the evaluation of the core proposal.

No Section Referenced

What is the intention behind the parent/child sub-account structure? What access challenges or requirements is this intended to solve?

• The parent/child structure enables centralized administrative oversight and role-based sub-accounts for campus units. Sub-accounts should be able to access shared templates, build unit-specific content, send messages for approval and access unit reporting.

• List management is under discussion. Ideally, constituent data would not cross sub-account boundaries for data privacy.

No Section Referenced

What is the purpose of the digital signage? How many venues, displays, events, etc., are included?

• Digital signage is another communications channel used across the institution for wayfinding, event promotion, and information sharing.

• We currently have 150+ screens in use.

No Section Referenced

Is the University seeking a provider to design new email templates, create new internal/external campaigns, provide campaign strategy, and write email copy? If yes, how many and what audiences are included?

• No. This will be done in-house.

Section 1.1 Section 1.1 requests details on bridging possibilities to facilitate a transition from the current system. Is there an established target go-live date or a specific overlap period required between systems during implementation?

• There is a possible overlap period of 1-2 months with our existing system and a target launch date before Dec. 31, with phased implementation happening for divisions of our campus in the first and second quarter of 2027.

No Section Referenced

Has the University previously considered or evaluated Slate for this enterprise Communications Management System? If so, please share any findings or reasons why it was or was not selected.

• Details regarding internal software evaluations or prior platform reviews are confidential to the University. All proposals submitted under RFP #55- 091826 will be evaluated strictly on their merits in accordance with the evaluation criteria in RFP Section 3.4.

Vendor Question/Response

§5.1, pp.14–16;

§4.10, p.13

Will the university accept an integrated solution comprising multiple products under one prime contractor and complete package price, or must all required capabilities be native to a single application?

• App State intends to contract with a single company that owns or develops, provides, and supports the proposed platform. While native out-of-the-box capabilities are strongly preferred to limit strain on internal IT teams, disclosed integrations or limited third-party partners for ancillary services (e.g., SMS carriers) are acceptable if delivered under one prime vendor and included in the total complete package price.

§5.1, pp.14–15 Which checklist capabilities are mandatory at go-live versus preferred, and will capabilities delivered through integrations or custom development be accepted?

• What we determined as capabilities that are a must in some fashion include o Unlimited email sends per year o Unlimited + editable sender IDs o System permissioning: Ability to restrict who can create and who can send emails o Can create branded email templates o Custom HTML capability o Calendar for cross-campus collaboration + scheduling o Message scheduling o Send to internal audiences o Send to external audiences o Unified constituent profiles (no more duplicated records) o Automated lists via Banner o Target audiences based on Banner qualifiers (role, location, supervisor, etc.)

o Ability to upload a list of email addresses or Banner IDs o Segmentation available o System is WCAG 2.1 Level AA compliant o System meets university security standards o System has a low learning curve o Robust performance and engagement metrics — more than open/click rates o Easy-to-use reporting dashboard o Key integrations (Banner, Bravura, Google, etc) o Excellent customer service

• As far as mandatory at go-live o Ability to build branded templates o Ability to use prioritized banner fed lists and CSV uploads o Ability to send to internal and external audiences o System meets security and accessibility reviews o System permissioning - ability to set roles and responsibilities in the system

Vendor Question/Response

• Some capabilities delivered through integrations or custom development are acceptable

• Custom development tends to cost time and money, which is not something we are willing to spend more of if we can find a solution with out-of-the-box capabilities that meet our needs and that put less strain or demand on our internal IT teams

§1.0, p.5; §5.1, p.14

What are the primary communication use cases—newsletters, marketing campaigns, administrative notices, transactional messages, or emergency alerts—and is inbound email or SMS response management required?

• All of the above

• Internal and external communication with employees, students, alumni, donors and community members

• Please describe how you handle SMS consent, opt-out management, communication if more than one way integration, and carrier registration

• SMS would likely be used more to push than pull for notification purposes

§5.1, pp.14, 16

What are the expected annual email and SMS volumes, largest broadcast audience for each channel, and required time to complete delivery of a broadcast?

• Current annual email campaign sends:

o Estimated internal: 500 o Estimated external: 1200

• Anticipated– This is hard to predict since we will be opening the system up to areas that we have no current data on. The goal is to consolidate and reduce redundant and shadow systems across our campus and offer an Enterprise email solution, which we have not been able to do before

§5.1, pp.14–15 Which Banner version, modules, and integration interfaces are available, and which data must synchronize, in which direction, and at what frequency?

• Data would go from Banner Advancement and Banner Student to the email marketing system daily. The constituent ID and email address(es) would be essential to synchronize, but would need the ability to update other data fields that have been changed in Banner each day.

• Data would need to be extracted from the email marketing system daily, ideally through a daily extract, but would depend on what data fields can be updated in the email marketing system.

§5.1, pp.14–15 Do all constituents have Banner IDs, and how should the platform handle external contacts without IDs, duplicate records, multiple email addresses, and individuals with multiple university roles?

• All constituents have Banner IDs, and ideally this would be the primary key, with the ability to have multiple email addresses attached to the ID. Individuals with multiple roles may need to be contacted by two different email addresses, depending on which university unit is sending the email.

Having multiple email address options for one record would resolve or prevent duplicate records on our end.

Vendor Question/Response

§5.1, pp.14, 16 Please define the required parent/child account structure, including departmental data separation, shared audiences and templates, central oversight, and the expected initial number of users and sub-accounts.

• The parent/child structure enables centralized administrative oversight and role-based sub-accounts for campus units. Sub-accounts should be able to access shared templates, build unit-specific content, send messages for approval and access unit reporting.

• List management is under discussion. Ideally, constituent data would not cross sub-account boundaries for data privacy.

• RFP Section 5.1 requests unlimited sub-accounts and campus users.

§5.1, pp.14–15 Please provide the university’s security assessment requirements and required accessibility documentation, and clarify whether WCAG 2.1 AA applies to the administrative application, generated communications, or both.

• The selected vendor must pass a formal IT Acquisition Review before award.

Required documentation includes a HECVAT, SOC 2 Type II report, and a VPAT/ACR demonstrating WCAG 2.1 Level AA compliance.

• The platform interface itself must meet WCAG 2.1 Level AA, while built-in content tools to check alt text, captions, and contrast for generated communications are strongly preferred.

§5.1, p.16 How should vendors structure complete-package pricing to accommodate unlimited email sends, users, and sub-accounts while identifying SMS allowances, channel charges, and the requested locked-in contact tiers?

• Vendors with send-based pricing must submit a single complete-package price covering unlimited sends, users, and sub-accounts. Vendors with contact-based models must submit complete-package pricing for each of the five locked-in contact tiers (250K to unlimited). Optional channels like SMS and digital signage must be itemized separately.

§1.1, p.5; §5.3, p.16

What is the required go-live date, which existing platforms are being replaced, and what migration scope and overlap period are expected for contacts, templates, consent records, and communication history?

• The solution replaces Encora/Anthology. Platform access is desired by early November 2026, with contract award before Dec 31, 2026, followed by a 1–2 month parallel operation transition period and phased campus rollout in Q1/Q2 2027. Email templates will be rebuilt in-house, contacts will re-feed from Banner, and historical engagement data remains in Banner.

RFP Section 3.6 (Proposal Contents), Page 7

There is no Attachment A (Pricing) included in the published solicitation documents. Is this a requirement or not applicable? This was left off in error - there is no Financial Proposal Template available. Vendors must provide the complete pricing/fee structure when submitting their bids.

RFP Section 5.1 (Financial Proposal), Page

There is no Attachment A (Financial Proposal) included in the published solicitation documents. Is this a requirement or not applicable? Attachment A was left off the published solicitation in error. There is no official financial template form; vendors must submit their own complete, itemized fee and pricing structure with their proposal package.

Vendor Question/Response

RFP Section 4.2 (Transportation and Identification), This section states that Vendor shall deliver FOB to any requested location within the state of North Carolina with all transportation costs and fees included in the total proposal price. Do you have a list of the actual delivery locations for this procurement? Should bidders include system equipment pricing in their proposal? Section 4.2 contains standard NC procurement boilerplate language. This procurement is for a SaaS software platform and cloud implementation services;

physical delivery locations and equipment pricing do not apply.

RFP Section 7.0 (Attachments), This section also asks for offerors to attach a financial proposal and reference a financial proposal template. Is the format from this template mandatory or made part of the evaluation? Vendors must provide the complete pricing/fee structure when submitting their bids.

RFP Section 7.0 (Attachment H), Does this EO50 apply for this procurement? Attachment H (Vendor Request for EO50 Price-Matching) is a standard North Carolina procurement document included in Section 7.0. Qualifying NC resident vendors seeking price-matching preferences under Executive Order 50 should complete and return Attachment H with their bid.

RFP Section 7.0 (Attachments), Lobbying Activity Certification for Federal Grants, Whether any portion of this acquisition is funded by Federal funds or Federal grant.

Bidders should complete and execute the Lobbying Activity Certification form in Section 7.0 and include it in their submission package to comply with standard state procurement requirements.

No Section Referenced

Please provide historical annual email volume, peak hourly or daily email volume, annual SMS message volume, and anticipated growth by channel so vendors can develop an all-inclusive package without materially different usage assumptions.

• Current annual email campaigns:

o Estimated internal: 500 o Estimated external: 1200

• Anticipated– This is hard to predict since we will be opening the system up to areas that we have no current data on. The goal is to consolidate and reduce redundant and shadow systems across our campus and offer an Enterprise email solution, which we have not been able to do before

No Section Referenced

What Banner integration methods and interfaces are currently available or preferred, such as Ellucian Ethos, REST APIs, database views, flat-file exchange, or secure SFTP, and which Banner entities and fields must be synchronized for dynamic audience lists and unified constituent profiles?

• Current environment is Banner 9. Integration requires a one-way data push from Ellucian Banner to the platform via daily scheduled batch extracts (SFTP) or REST APIs. Key fields synchronized include Banner IDs (primary key), email addresses, and demographic/role qualifiers.

Please identify the communications platforms currently in use and clarify which assets must be migrated, including templates, contact lists, consent records, suppression lists, sender domains, engagement history, scheduled campaigns, and analytics. What bridge period and target production date should vendors assume?

Vendor Question/Response

• Replaces Encora/Anthology. Email templates will be rebuilt directly in the new platform, contacts will re-feed dynamically from Banner, and historical data remains in Banner. Vendors should assume a 1–2 month parallel operation bridge period, platform access in early November 2026, and go-live/award before Dec 31, 2026.

Will the University provide its IT acquisition and security assessment requirements, including required SSO protocols, hosting or data-residency restrictions, encryption standards, retention and deletion requirements, incident-notification periods, penetration-testing evidence, and any required security certifications?

• Top-ranked vendors will undergo App State's formal ITS Acquisition Review prior to contract execution. Required documentation includes a completed HECVAT, SOC 2 Type II audit report, and a VPAT/ACR confirming WCAG

2.1 Level AA compliance.

For Section 4.5, will the University accept references for comparable multi-channel communications deployments delivered using the same underlying SaaS platform and service model, even if each client’s workflows, integrations, branding, and configuration differ?

• No. The three primary references on Attachment E must be for clients to whom the proposing vendor directly supplied the exact model/platform offered. Offerors may include supplemental references for comparable deployments to demonstrate expertise, but these will not be accepted as substitutes for the primary product references.

RFP Section 2.3, Notice to Vendors Regarding RFP Terms and Conditions, pp. 5- 6; Attachment C, North Carolina General Terms & Conditions, p. 19

Contract Terms / Services Agreement: Our Services are ordinarily provided pursuant to our standard Services Agreement. If we are selected, would the University be willing to use our Services Agreement as the basis for the parties’ contract, with the parties negotiating in good faith any necessary modifications and addressing any conflicts with the University’s General Terms and Conditions? We have identified certain provisions of the University’s terms that would be particularly important to address as part of those negotiations. Note that the following is not an exhaustive list.

• All vendors must comply with and agree to the State of N.C. Terms and Conditions.

Attachment C, North Carolina General Terms & Conditions, p. 19

Limitation of Liability: Would the University be willing to negotiate a commercially reasonable limitation of liability and exclusion of indirect, incidental, special, and consequential damages appropriate for cloud-based subscription services?

• All vendors must comply with and agree to the State of N.C. Terms and Conditions in reference to Limitation of Liability.

Attachment C, North Carolina General Terms & Conditions, p. 19

Indemnification: Would the University be willing to negotiate the indemnification provisions, including customary exclusions and a commercially reasonable limitation on liability?

• All vendors must comply with and agree to the State of N.C. Terms and Conditions in reference to Indemnification.

Vendor Question/Response

Attachment C, North Carolina General Terms & Conditions, p. 19

Termination for Convenience: For SaaS Services, would the University agree that termination for convenience would be effective as of the end of the then-current subscription term, or otherwise address fees committed for the remainder of that term?

• All vendors must comply with and agree to the State of North Carolina General Terms & Conditions (Attachment C). Termination provisions are governed by Attachment C and cannot be altered.

RFP Section 4.10, Subcontractors, p.

13; Attachment C, North Carolina General Terms & Conditions, p. 19

Subcontractors: Would the University clarify that the prior written consent requirement for subcontractors does not apply, except that we would be willing to provide a notice and consent mechanism for subprocessors?

• Section 4.10 applies as written. Vendors should identify all subcontractors and subprocessors that will have access to University data or deliver any part of the services in their proposal. The University will not waive the consent requirement.

RFP Section 4.1, Financial Proposal, p. 11;

Sections 6.6-6.7, Acceptance of Work and Invoices, pp. 17- 18; Attachment C, North Carolina General Terms & Conditions, p. 19

Acceptance and Invoicing: Would the University clarify that acceptance procedures apply to implementation services and specific deliverables requiring acceptance, and that recurring subscription fees following commencement of the subscription Services are not conditioned upon recurring inspection or acceptance?

• Formal acceptance procedures apply to implementation services and project milestones. Recurring SaaS subscription fees post-go-live do not require recurring inspection, provided the system meets agreed-upon uptime and service level requirements.

Attachment C, North Carolina General Terms & Conditions, p. 19

Assignment: Would the University permit us to assign the resulting Contract without consent in connection with a merger, reorganization, change of control, or sale of all or substantially all of our assets?

• Assignment is governed by Attachment C. The University’s consent is required. In the event of a merger, acquisition, or change of control, the vendor must notify the University promptly, and the University will review any request for assignment or novation.