Updated Response to Offeror Questions document.docx

DOCX document 57 KB Posted

Attached to
SDSU Large Language Model (LLM) Search Optimization
Solicitation number
26RFP-SDSU06252026
Issued by
Brown County, South Dakota

About this file

This is an Updated Response to Offeror Questions document for South Dakota State University's Large Language Model (LLM) Search Optimization RFP. The project seeks a tool or service to improve institutional content discovery within AI-generated search and answer systems, treating traditional SEO as a foundational layer while building LLM-driven discovery and generative AI capabilities. The solution must integrate with Drupal CMS version 10, analyze approximately 9,000 institutional web pages, and provide measurable performance data with actionable content recommendations. Proposals were due July 22, 2026 at 11:00 a.m. CDT, with questions accepted through July 7, 2026 at 11:00 a.m. CDT and responses posted by July 10, 2026 at 5:00 p.m. CDT. The anticipated award decision and contract negotiation date is August 24, 2026. The contract term is two years with an option to renew for up to three additional one-year periods. Oral presentations may be required at the offeror's expense, with scheduling to be determined.

The total contract value does not exceed $80,000 annually, with vendors required to submit one-time implementation costs and ongoing subscription or licensing fees with a clear explanation of the pricing model. Vendors must hold SOC 2 Type II or ISO 27001 certification, demonstrate data residency in the United States only, maintain FERPA compliance, and ensure accessibility compliance with ADA, Section 508, and WCAG 2.1 Level AA standards. Offerors must provide evidence of at least three previous similar contracts with client references and demonstrate financial stability and long-term viability. The solution must support role-based access controls, audit logging suitable for leadership review, and function within non-technical institutional workflows. All inquiries and responses are posted on South Dakota's e-procurement system, and offerors should direct questions to Karen Bravek at Karen.Bravek@sdstate.edu with the subject line "RFP #SDSU06252026 QUESTIONS."

View the file

Other files

File Type Posted
Response to Offeror Questions document.docx DOCX document
RFP Document.pdf PDF

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

Vendor Questions & Answers for RFP# SDSU06252026 – SDSU Large Language Model (LLM) Search Optimization July 10, 2026 & July 15, 2026

Vendor A:

1. Does SDSU currently use any SEO, content optimization, or AI-search visibility tools today? If so, which ones?

a. SDSU currently uses Siteimprove and Google Analytics for website quality, accessibility, analytics, and limited SEO monitoring. SDSU does not currently utilize a dedicated LLM Search Optimization, GEO, AEO, or AI visibility platform. This procurement seeks a new solution in that category.

2. For scope purposes, should our proposal cover the primary sdstate.edu domain only, or should we also account for any subdomains or affiliated sites (e.g., athletics, specific colleges, admissions)?

a. Initial proposal and term is for sdstate.edu domain only. Additional domains could be considered under a separate contract.

3. Which generative AI platforms is SDSU most interested in monitoring for visibility and citations (e.g., ChatGPT, Perplexity, Gemini, Google AI Overviews, Copilot)?

a. Yes, we are interested in those and would like flexibility to adapt as the technology changes.

4. Who can we expect to be the primary day-to-day users of the selected platform (marketing, IT, communications, or individual departments), so we can tailor our workflow recommendations appropriately?

a. SDSU anticipates requiring a combination of administrative, contributor, and reporting-focused user roles within the proposed solution. For proposal and pricing purposes, vendors should assume the following approximate user populations:

i. Administrative Users: Up to 10 users responsible for platform administration, configuration, governance, reporting, and oversight.

ii. Content Contributors / Editors: Approximately 250 users responsible for reviewing recommendations and managing content within their assigned colleges, departments, programs, or website sections.

iii. View-Only / Dashboard Users: Up to 10 users, including leadership and other stakeholders, requiring access to dashboards, reports, and performance metrics without content management responsibilities.

b. User counts provided above are planning estimates and may be adjusted during implementation based on institutional needs, governance decisions, and the capabilities of the selected solution.

5. Is there a budget range or not-to-exceed amount associated with this engagement?

a. See RFP Section 2.4

6. What is the anticipated initial contract term, and are renewal options expected (e.g., 1-year vs. multi-year)?

a. See RRP Section 1.12 Length of contract

Vendor B:

Contract & Legal

1. Next Steps / Demo Process Can the State clarify the next steps following proposal submission? Specifically, is the State open to a custom product demonstration, and if so, what does that process involve?

See RFP Section 1.14

2. Contract Execution / Signature Will the resulting contract or agreement need to be signed by VENDOR? Please confirm the signature and execution process.

Yes

3. Section 1.11 — Proprietary Information Section 1.11 appears to provide that proprietary information submitted by an offeror becomes property of the State upon contract award. Can the State clarify the intended scope of this provision and confirm whether it is negotiable for the successful offeror?

South Dakota Codified Law (SDCL) Ch.1-27 and 5-18A require as stated in section 1.11. Certain portions or proposals are part of proposal logs and awarded proposals as well as the contract awarded, are public records. An awarded vendor can protect certain portions of the proposal to protect personal privacy or prevent disclosure of secure, proprietary data. Refer to section 1.11 for instructions on how to identify such items within the proposal.

4. Section 1.13 — Governing Law Section 1.13 designates South Dakota as the governing law. Is the State open to negotiating an alternate governing law provision as part of contract negotiations?

No

5. Section 2.2 — Termination Section 2.2 addresses termination but does not explicitly reference termination for convenience. Can the State confirm whether termination for convenience is included in this provision, and clarify how the termination terms would interact with a vendor's standard Master Subscription Agreement (MSA)?

The RFP is subject to the RFP Standard Contract Terms and Conditions, Section 2.9, applicable State of South Dakota standard terms, laws, regulations, and procurement requirements. Any contract resulting from this solicitation will be subject to review and approval by the State and SDSU, and contractual terms will be negotiated with the selected vendor as appropriate.

SDSU and the State reserve all rights available under applicable law with respect to contract termination. Vendors should not assume that their standard Master Subscription Agreement (MSA), End User License Agreement (EULA), Terms of Service, or other standard commercial terms will automatically govern the resulting agreement.

If a vendor proposes use of a standard MSA or subscription agreement, the vendor should include that document with its proposal and clearly identify any terms that it considers material to the proposed business arrangement.

6. Section 2.6 — Workers' Compensation Insurance Section 2.6 requires Workers' Compensation Insurance. Can the State confirm the specific coverage requirements (e.g., statutory limits) so offerors can validate their certificates of insurance meet requirements?

Offerors are expected to maintain Workers' Compensation Insurance in accordance with applicable federal and state laws governing the jurisdictions in which their employees perform work.

Product & Technical Scope

7. Of the ~9,000 pages, how many domains and subdomains are in scope? Are there specific high-priority sections (e.g., Admissions, Financial Aid, Academic Programs) that should be the focus of initial optimization?

Initial proposal and term is for sdstate.edu domain only. Additional domains could be considered under a separate contract. SDSU has not established a mandatory ranking of institutional use cases; however, the University anticipates that content areas with high visibility, high user demand, or high institutional impact may warrant particular attention during implementation and prioritization activities.

8. Does SDSU currently have defined content taxonomies, content types, or a structured sitemap, or would the vendor be expected to help establish content hierarchy?

No, the vendor is not expected to develop a content hierarchy.

9. Which specific AI/LLM platforms are highest priority for SDSU to monitor (e.g., ChatGPT, Google AI Overviews/AI Mode, Perplexity, Gemini, Copilot, Claude)? Are there specific AI-driven discovery scenarios — such as prospective students asking "best ag programs in the Midwest" — that the team wants to optimize for?

Yes, we are interested in those and would like flexibility to adapt as the technology changes.

Similar to standard SEO and keyword optimization, each section of the site will have specific topic optimization goals.

10. When the RFP references "detection of inaccurate, incomplete, or conflicting AI answers," does SDSU expect the vendor to proactively monitor and alert on AI-generated content about the university? If so, how frequently (daily, weekly)?

We are looking for a solution that will provide monitoring and alerts on an ongoing basis.

11. For "peer benchmarking against similar institutions," does SDSU have a specific peer set in mind (e.g., other land-grant universities, SDCAC conference peers)? How many benchmark institutions would be expected?

SDSU anticipates benchmarking against approximately 10 peer land-grant institutions but is open to larger benchmark groups if supported by the solution.

12. What analytics platforms does SDSU currently use (e.g., Google Analytics 4, Adobe Analytics)? Is there an expectation for the vendor to integrate with and pull data from these existing analytics tools?

SDSU currently uses Google Analytics for analytics. SDSU does not require integration with existing analytics platforms as a condition of the proposal. However, vendors should describe any available integrations with analytics and reporting platforms that may enhance the functionality of the proposed solution.

13. For "zero-click behavior" analysis, is SDSU looking for data on how often AI-generated answers replace clicks to university pages, or more broadly for search-engine-level zero-click data (e.g., featured snippets)?

The primary request would be related to AI-generated answers, but we would be interested in all levels of zero-click behavior.

14. Does SDSU want to monitor how third-party sources — such as Wikipedia, Reddit, YouTube, or Rate My Professor — influence how AI platforms represent the university? Or is the scope limited to SDSU-owned web properties?

SDSU's primary focus remains the optimization and measurement of authoritative institutional content within the sdstate.edu domain. However, the University recognizes that AI systems often synthesize information from a variety of sources beyond institutional websites.

SDSU is interested in understanding how third-party sources may influence the way AI-powered search and answer systems represent the University, its programs, services, and reputation. As a result, SDSU welcomes capabilities that provide visibility into external sources that may contribute to AI-generated answers.

15. Does SDSU currently track or intend to track how digital content performance connects to enrollment outcomes, application submissions, or other institutional conversion goals? If so, what systems house that conversion data?

Please describe the solutions for this type of reporting within the tool if an integration would be possible.

16. For the "AI-readiness scoring" referenced in Section 3.6, does SDSU have a baseline understanding of what factors should contribute to that score, or would the vendor be expected to define and calibrate the scoring methodology?

SDSU has intentionally not prescribed a specific methodology, scoring model, or required point scale for "AI-readiness scoring." One of the objectives of this procurement is to evaluate the maturity and effectiveness of vendor approaches for assessing how well institutional content can be understood, summarized, cited, and surfaced by AI-driven search and answer systems.

17. How frequently does the university's web content change? Are there seasonal publishing cycles (e.g., enrollment periods, application deadlines, academic calendar changes) that would require more frequent data refreshes or re-scoring?

Content is consistently changing throughout the year.

18. What level of Drupal integration does SDSU envision — read-only content ingestion via crawling, or does the university expect in-CMS content recommendations or modules that operate within the Drupal editorial workflow?

SDSU's primary expectation is that the proposed solution will be capable of analyzing content managed within the University's Drupal environment and providing actionable recommendations to content owners and administrators.

SDSU's preference is for a solution that minimizes complexity and ongoing maintenance while preserving institutional control of content, governance workflows, and publishing processes.

19. How many content contributors/users would need platform access? Are there distinct roles (e.g., view-only dashboards for leadership, edit/action for content teams, admin for IT)?

SDSU anticipates requiring a combination of administrative, contributor, and reporting-focused user roles within the proposed solution.

For proposal and pricing purposes, vendors should assume the following approximate user populations:

· Administrative Users: Up to 10 users responsible for platform administration, configuration, governance, reporting, and oversight.

· Content Contributors / Editors: Approximately 250 users responsible for reviewing recommendations and managing content within their assigned colleges, departments, programs, or website sections.

· View-Only / Dashboard Users: Up to 10 users, including leadership and other stakeholders, requiring access to dashboards, reports, and performance metrics without content management responsibilities.

User counts provided above are planning estimates and may be adjusted during implementation based on institutional needs, governance decisions, and the capabilities of the selected solution.

20. For "department and section-based access controls," does SDSU expect role-based views per academic department/college, or is this more about general admin vs. user access?

Role-based views per academic department/college

21. Given the August 2026 go-live target, what does SDSU consider "minimum viable" functionality at launch vs. capabilities that can be phased in over the first contract year?

Please describe the standard functionality that will be available at launch vs. what additional capabilities that don't currently exist.

Vendor C:

The following questions are submitted pursuant to section 1.10 of RFP #SDSU06252026 to obtain clarification of requirements. Questions are organized by RFP section reference.

#
RFP Section
Question
Why This Matters
Response

3.2 – Foundational SEO

Q1
3.2 – Foundational SEO
Does SDSU expect the SEO audit and baseline analysis to be completed before or concurrent with the LLM optimization layer during the implementation phase?
Affects Year 1 build sequencing and resource allocation.
Concurrent and ongoing with the LLM optimization
Q2
3.2 – Foundational SEO
Are there existing SEO tools or platforms currently in use at SDSU (e.g., Google Search Console, SEMrush, Conductor) that the selected vendor must integrate with or replace?
Determines integration scope vs. greenfield build.
SDSU currently uses Siteimprove and Google Analytics for website quality, accessibility, analytics, and limited SEO monitoring. SDSU does not currently utilize a dedicated LLM Search Optimization, GEO, AEO, or AI visibility platform. This procurement seeks a new solution in that category.
Q3
3.2 – Foundational SEO
Is the SEO monitoring scope limited to the primary SDSU domain (sdstate.edu), or does it include all subdomains and affiliated microsites? If subdomains are included, how many distinct subdomains are currently active?
Directly impacts crawl infrastructure scope and pricing.
Initial proposal and term is for sdstate.edu domain only. Additional domains could be considered under a separate contract.
Q4
3.2 – Foundational SEO
Does SDSU have an existing Google Search Console or Google Analytics account that the vendor will be granted access to, or must the vendor establish independent data collection infrastructure?
Foundational SEO and zero-click analysis both depend on search performance data. GSC access vs. independent crawl is a major scope difference.
SDSU does not require integration with existing analytics platforms as a condition of the proposal. However, access to Google Analytics and other available analytics resources may be provided if supported by the proposed solution.

3.3 – LLM Search Optimization

Q5
3.3 – LLM Search Optimization
Which specific AI systems and LLM-powered search interfaces does SDSU expect the solution to monitor – for example, ChatGPT, Google Gemini, Microsoft Copilot, Perplexity, and Claude? Is there a defined minimum set of platforms required at contract start?
Each platform requires distinct probing methodology and API cost. Undefined scope creates delivery risk.
Yes, we are interested in those and would like flexibility to adapt as the technology changes.
Q6
3.3 – LLM Search Optimization
Does SDSU expect real-time LLM citation monitoring, or is periodic reporting (e.g., weekly or monthly) acceptable for LLM visibility tracking?
Real-time monitoring requires significantly different infrastructure than batch reporting.
SDSU prefers a solution that supports ongoing monitoring with the ability to provide both scheduled reporting and on-demand reporting. Real-time reporting is not required.
Q7
3.3 – LLM Search Optimization
When the RFP references 'visibility into how institutional content is used and summarized by AI systems,' does this include monitoring of AI Overviews in Google Search, or is it limited to standalone AI assistants and conversational tools?
Google AI Overviews require different technical approaches than direct LLM API monitoring.
Yes. SDSU intends the phrase "visibility into how institutional content is used and summarized by AI systems" to include both AI-enhanced search experiences and Standalone AI assistants and conversational platforms.

SDSU recognizes that visibility, citation tracking, and answer monitoring capabilities may vary across platforms based on available data, APIs, platform limitations, and vendor methodologies. Vendors should describe:

· Which AI-powered search and answer environments are supported by the solution;

· How visibility is measured across different AI platforms;

· Any differences in monitoring methodology between AI-enhanced search experiences and standalone conversational AI tools;

· Any limitations or constraints associated with specific platforms;

Recommendations regarding the most effective approach to measuring AI visibility and answer quality across the evolving AI search ecosystem.

Q8
3.3 – LLM Search Optimization
Section 3.3 asks vendors to describe how their solution adapts as LLM technologies evolve. Does SDSU expect the vendor to actively optimize how LLMs respond about the institution (proactive GEO), and if so, what methods of content intervention or structured data enrichment does SDSU consider acceptable within its governance and responsible AI policies?
Proactive GEO requires content intervention workflows with specific governance implications. Understanding acceptable methods avoids proposing approaches SDSU may not approve.
Yes. SDSU anticipates that the selected solution will support proactive optimization of institutional content for LLM-based discovery and answer systems. However, SDSU's intent is not to manipulate or attempt to control the responses of third-party AI platforms. Rather, SDSU seeks solutions that help ensure institutional content is accurate, authoritative, discoverable, well-structured, and more likely to be interpreted correctly by LLMs.
Q9
3.3 – LLM Search Optimization
Section 3.7 requires 'avoidance of vendor-exclusive or proprietary content dependencies.' Does this prohibition extend to the use of proprietary third-party AI models or APIs (e.g., OpenAI, Google, Anthropic) within the solution's core LLM monitoring and optimization pipeline?
LLM monitoring architectures depend on commercial AI provider APIs. If this clause prohibits their use, it fundamentally changes the technical architecture and feasibility of the solution.
No. The requirement to avoid "vendor-exclusive or proprietary content dependencies" is not intended to prohibit the use of proprietary third-party AI models, APIs, or services (e.g., OpenAI, Google, Anthropic) as components of a vendor's solution.

Rather, this requirement is intended to ensure that the university retains ownership and control of its content and can reasonably transition to another solution in the future without being dependent on proprietary content formats, workflows, or structures that cannot be exported, reused, or managed outside the vendor's platform.

Q10
3.3 – LLM Search Optimization
Has SDSU identified specific examples where AI-generated answers currently provide inaccurate, incomplete, or misleading information about the university that the selected solution should prioritize addressing?
Understanding known pain points allows vendors to propose targeted solutions and define measurable early wins, rather than discovering issues post-award.
SDSU has not developed a formal inventory of specific AI-generated responses that are currently inaccurate, incomplete, or misleading, nor is SDSU prescribing a list of topics that vendors must prioritize as part of this procurement.

One of the objectives of this RFP is to identify a solution that can help the University establish a baseline understanding of how SDSU is represented across AI-powered search and answer platforms and identify opportunities for improvement.

3.4 – Performance Measurement and Analytics

Q11
3.4 – Performance Measurement and Analytics
For peer benchmarking (section 3.4), which peer institutions or competitor set does SDSU expect to benchmark against – for example, other land-grant universities, regional competitors, or a custom-defined peer group?
Benchmarking requires data access or crawl permissions for third-party domains. An undefined peer set affects feasibility and scope.
SDSU anticipates benchmarking against approximately 10 peer land-grant institutions but is open to larger benchmark groups if supported by the solution.
Q12
3.4 – Performance Measurement and Analytics
Is peer benchmarking a Year 1 delivery requirement, or is it acceptable as a Year 2 roadmap feature following establishment of SDSU's own baseline metrics?
Sequencing this correctly affects Year 1 delivery scope and pricing.
Preference is Year 1
Q13
3.4 – Performance Measurement and Analytics
Does SDSU require zero-click behavior analysis at the keyword or topic level, or at the page level? Is Google Search Console data integration expected as the primary source for this analysis?
Page-level zero-click analysis requires different tooling than topic-level aggregation.
Please describe the analysis capabilities available within the tool or through standard integrations.
Q14
3.4 – Performance Measurement and Analytics
How many departmental user accounts does SDSU anticipate needing at contract start, what user personas should be supported (e.g., marketing, communications, admissions, IT, academic departments), and is there an expected growth rate over the contract term? Section 7.0 asks vendors to explain seat licensing details – this information is needed to price the solution accurately.
User volume and persona mix directly affect licensing model, role-based dashboard scope, and infrastructure sizing.
SDSU anticipates requiring a combination of administrative, contributor, and reporting-focused user roles within the proposed solution.

For proposal and pricing purposes, vendors should assume the following approximate user populations:

· Administrative Users: Up to 10 users responsible for platform administration, configuration, governance, reporting, and oversight.

· Content Contributors / Editors: Approximately 250 users responsible for reviewing recommendations and managing content within their assigned colleges, departments, programs, or website sections.

· View-Only / Dashboard Users: Up to 10 users, including leadership and other stakeholders, requiring access to dashboards, reports, and performance metrics without content management responsibilities.

User counts provided above are planning estimates and may be adjusted during implementation based on institutional needs, governance decisions, and the capabilities of the selected solution.

Q15
3.4 – Performance Measurement and Analytics
What measurable success criteria will SDSU use during implementation and contract performance to evaluate whether the solution is meeting expectations? Are there specific KPIs, accuracy thresholds, or visibility improvement targets SDSU has in mind?
Clearly defined success criteria allow vendors to align technical approach and delivery milestones with SDSU's actual performance expectations from day one.
SDSU has not established specific KPI thresholds, accuracy requirements, or visibility improvement targets for this procurement. Because LLM visibility and answer-engine optimization are evolving rapidly and institutional baselines have not yet been established, SDSU is seeking vendor expertise in defining meaningful and measurable performance indicators as part of implementation.

3.5 – Content Gap, Risk, and Quality Analysis

Q16
3.5 – Content Gap, Risk, and Quality Analysis
When the RFP references 'high-risk subject areas such as admissions, financial aid, and policies,' does SDSU have a predefined list of high-risk content categories, or is the vendor expected to identify and propose these categories as part of the engagement?
A predefined list allows precise scoping; vendor-defined categories require additional discovery and validation effort.
SDSU has not established a mandatory ranking of institutional use cases; however, the University anticipates that content areas with high visibility, high user demand, or high institutional impact may warrant particular attention during implementation and prioritization activities.
Q17
3.5 – Content Gap, Risk, and Quality Analysis
Does content health scoring (section 3.5) need to integrate with SDSU's existing content governance processes or CMS workflows in Year 1, or is a standalone scoring dashboard acceptable initially with CMS integration as a Year 2 enhancement?
CMS-integrated scoring requires deeper Drupal development than a standalone dashboard.
Preference is that all tool functionality is available year one.

3.6 – Actionable Content Optimization Recommendations

Q18
3.6 – Actionable Content Optimization Recommendations
Does SDSU expect AI-generated content drafts or rewrites as part of the optimization recommendations, or are structured recommendations and plain-language guidance sufficient for content teams to implement independently?
AI-assisted content generation is a materially different capability than recommendation delivery, with different compliance and editorial governance implications.
Structured recommendations and plain-language guidance is sufficient.
Q19
3.6 – Actionable Content Optimization Recommendations
Section 3.6 refers to 'schema markup recommendations' such as JSON-LD, FAQ schema, and Organization schema. Given the use of 'recommendations,' does SDSU expect the vendor to provide advisory guidance for SDSU staff to implement, or does SDSU expect the vendor to implement schema markup directly within the Drupal CMS environment?
Direct implementation requires deeper CMS access and development scope than advisory recommendations and has different implications for content ownership.
Request vendor to provide advisory guidance for SDSU staff to implement.

3.7 – Workflow, Usability, Governance

Q20
3.7 – Workflow, Usability, Governance
Does SDSU require integration with a specific Learning Management System (LMS) for staff training and certification, such as D2L Brightspace or Canvas? Or is a vendor-hosted training portal acceptable for the structured onboarding requirement in section 3.7?
LMS integration requires additional technical scope beyond standalone training delivery.
A vendor-hosted training portal is acceptable.
Q21
3.7 – Workflow, Usability, Governance
Does the human-review and approval workflow requirement (section 3.7) need to integrate with SDSU's existing ticketing or project management systems, or is a standalone workflow within the vendor platform acceptable?
Third-party workflow integration significantly increases scope compared to a self-contained platform workflow.
All web content edits will need to route through the approval process in Drupal.
Q22
3.7 – Workflow, Usability, Governance
Does SDSU expect the solution to be hosted by the vendor as a SaaS offering, or deployed within SDSU-managed infrastructure? If vendor-hosted, are there specific cloud provider requirements or restrictions?
Hosting model fundamentally affects architecture design, data residency compliance, security certification scope, and ongoing infrastructure costs.
SDSU anticipates a vendor-hosted SaaS solution. If that is not included as part of the platform, please include recommendations and pricing as part of the proposal.

3.9.1 – Security and Compliance

Q23
3.9.1 – Security and Compliance
Section 3.9.1e references 'security certifications or alignments such as SOC 2 Type II, ISO 27001, or NIST CSF.' Is a current SOC 2 Type II certification required at the time of proposal submission, at contract award, or within a defined period after contract start?
SOC 2 Type II audits take 6–12 months to complete. Clarifying the timing requirement is critical for vendors who are certified, in-progress, or planning certification.
SOC 2 Type II certification is required at the time of proposal submission.
Q24
3.9.1 – Security and Compliance
Section 3.9.1f and section 6.1 both reference HECVAT and VPAT as documents to be provided 'upon request.' At what point after award will SDSU formally request the HECVAT and VPAT, and what is the expected turnaround time for delivery?
Completed HECVAT and VPAT require significant documentation effort. Understanding the post-award timeline helps vendors plan accordingly.
SDSU may request HECVAT and VPAT documents at the time of proposal, and if engaged, at any time thereafter. SDSU expects these documents to be delivered, in full, within 10 business days of being requested. Preferably, these are included in the proposal.
Q25
3.9.1 – Security and Compliance
Is the FERPA compliance requirement in section 3.9.1a applicable because the platform will have direct access to student personally identifiable information (PII), or is the FERPA requirement limited to ensuring that institutional content about admissions and financial aid is accurately represented in AI-generated answers?
Direct access to student PII creates substantially different compliance obligations than content-level FERPA considerations.
The FERPA compliance requirement exists in section 3.9.1a should the solution provider be granted access to any system that has any Personally Identifiable Information as defined in SDBOR Policy 7.7.
Q26
3.9.1 – Security and Compliance
Section 3.9.1b requires U.S.-only data residency. Does this requirement apply to all data processed by the platform, including API calls made to third-party AI providers such as OpenAI or Google whose infrastructure may route through non-U.S. data centers? If so, does SDSU require executed data processing agreements with those providers prior to contract start?
Commercial LLM provider APIs may route through non-U.S. infrastructure. This directly affects which AI providers can be used in the monitoring pipeline.
The U.S.-only data residency requirement applies to institutional data processed under the contract, including data transmitted to third-party AI or machine learning providers. Vendors are responsible for ensuring that any subcontractors or downstream service providers used to process SDSU data comply with applicable data residency, privacy, and security requirements. Vendors should disclose any third-party AI providers involved in delivering the service, identify where SDSU data may be processed or stored, and be prepared to execute appropriate contractual agreements (e.g., Data Processing Agreements or equivalent protections) prior to processing SDSU data, if required by SDSU.
Q27
3.9.1 – Security and Compliance
Will SDSU provide an enterprise identity provider (e.g., Azure AD, Entra ID, Okta) for SAML/SSO integration, or is the vendor expected to support a generic SAML 2.0 implementation compatible with SDSU's existing IdP?
The specific IdP in use affects authentication integration scope, testing requirements, and whether vendor-side configuration or SDSU IT involvement is needed.
Yes, Microsoft ADFS/Entra ID.

3.9.2 – System Architecture and Integration

Q28
3.9.2 – System Architecture and Integration
Does Drupal 10 integration require a native Drupal module installable through the standard Drupal module ecosystem, or is an API-based integration between the vendor platform and Drupal CMS acceptable?
A native Drupal module and an API integration are materially different in development scope, maintenance burden, and upgrade compatibility.
An API-based integration between the vendor platform and Drupal CMS is acceptable.
Q29
3.9.2 – System Architecture and Integration
Will the vendor have direct access to SDSU's Drupal environment for integration, development, and testing, or will all Drupal-side work need to be coordinated through SDSU's internal IT or web team?
Coordinated access significantly affects implementation timeline, testing cycles, and resource requirements.
Yes, all Drupal-side work needs to be coordinated through SDSU's web team.
Q30
3.9.2 – System Architecture and Integration
Is the secure sandbox or test environment (section 3.9.2c) expected to be a full mirror of the production Drupal instance, or a lightweight staging environment? Who is responsible for provisioning, maintaining, and funding the sandbox infrastructure?
Full production mirrors require significant infrastructure investment; clarifying ownership prevents scope gaps and budget surprises.
SDSU anticipates maintaining and providing its own Drupal development and test environments. Vendors should describe how their solution supports integration with customer-managed staging, development, or test environments and identify any requirements or limitations associated with those integrations.

3.9.3 – Content Ingestion and Indexing

Q31
3.9.3 – Content Ingestion and Indexing
Are all approximately 9,000 pages publicly accessible for automated crawling, or does a portion of the site require authenticated crawl access? If authenticated crawl is needed, how will credentials be provisioned and managed securely?
Authenticated crawl requires additional security architecture and increases implementation complexity.
All pages are publicly accessible.
Q32
3.9.3 – Content Ingestion and Indexing
Section 3.9.3c requires 'real-time content updates with rapid re-scoring after changes.' Does SDSU expect webhook or event-driven integration with Drupal triggered on content publish events, or is a scheduled re-crawl within a defined window (e.g., within 24 hours of a content change) acceptable?
Event-driven real-time re-scoring requires deeper Drupal integration than scheduled crawling and materially affects the architecture.
A scheduled recrawl once every 24 hours is acceptable.

2.4 and 2.15 – Contract, Pricing, and IP Ownership

Q33
2.4 and 2.15 – Contract, Pricing, and IP Ownership
Section 2.4 states the total contract amount is 'not to exceed $80,000 annually.' Does this cap apply uniformly across all contract years including optional renewal years, or can annual amounts vary across the contract term provided no single year exceeds $80,000?
Variable annual pricing may better reflect the actual cost structure of this engagement and benefit both parties.
Vendors may propose annual pricing that varies by contract year; however, the total proposed cost for any individual contract year must not exceed $80,000 and must be clearly defined in the cost proposal.
Q34
2.4 and 2.15 – Contract, Pricing, and IP Ownership
Does SDSU require fixed pricing for all optional renewal years to be submitted at the time of proposal, or can pricing for renewal years be subject to renegotiation at the time each renewal option is exercised?
LLM monitoring infrastructure costs are likely to change significantly over a 5-year period as AI platforms evolve.
Pricing for renewal years can be subject to renegotiation at the time each renewal option is exercised.
Q35
2.4 and 2.15 – Contract, Pricing, and IP Ownership
Section 2.15 states that all software system programs, source code, and documentation provided to the State shall become the property of the State of South Dakota. Does this IP assignment apply to the vendor's pre-existing platform components, proprietary algorithms, and foundation codebase, or is it limited to work products, configurations, reports, and documentation created specifically for SDSU under this contract?
As written, section 2.15 could be interpreted to require vendors to transfer ownership of their entire platform codebase to the State. Clarification is essential before any vendor can responsibly commit to this contract.
Limited to work products, configurations, reports, deliverables, and documentation created specifically for SDSU.
Q36
2.4 and 2.15 – Contract, Pricing, and IP Ownership
What is the expected contract start date following the anticipated August 24, 2026, award decision? Section 2.2 notes that commencement dates are mutually agreed upon – understanding the expected start window is necessary for implementation planning and resource allocation.
Completely undefined in the RFP. Affects build timeline, staffing, and Year 1 delivery commitments significantly.
SDSU anticipates contract award in August 2026. The implementation start date will be negotiated with the selected vendor based on project readiness, resource availability, and agreed-upon implementation planning.

2.6 – Insurance Requirements

Q37
2.6 – Insurance Requirements
Section 2.6c requires Business Automobile Liability Insurance with a limit of not less than $1,000,000 per accident. Is this requirement applicable to a fully remote, software-only engagement with no on-site service delivery at SDSU facilities? If so, does it apply to the prime vendor only, or to all named subcontractors as well?
For a SaaS/remote engagement with no physical service delivery, automobile liability insurance is an unusual requirement. Clarifying applicability helps vendors price the engagement accurately.
The insurance requirements identified in the RFP represent the University's standard minimum insurance requirements and apply unless otherwise modified through the procurement and contracting process.

Vendors should assume that the insurance requirements stated in the RFP remain applicable for proposal purposes. If a vendor believes a specific requirement is not applicable to its proposed solution or business model, the vendor should identify that exception in its proposal and provide supporting rationale for decision making by SDSU.

5.0 – Proposal Format and Submission

Q38
5.0 – Proposal Format and Submission
Does SDSU expect prime vendors to identify all proposed subcontractors and their specific roles within the proposal submission itself to satisfy the subcontractor consent requirement in section 2.14, or is formal subcontractor disclosure required only after contract award?
Clarifies whether subcontractor identification must be included in the proposal or can follow during contract negotiation.
SDSU expects vendors to disclose, within their proposal submission, any subcontractors, teaming partners, affiliated entities, or third-party providers that are known at the time of proposal and are expected to play a material role in delivering the proposed solution or services.
Q39
5.0 – Proposal Format and Submission
Is there a recommended or maximum page limit for the Detailed Response section of the proposal (section 5.2)?
Helps vendors calibrate the appropriate depth and length of the technical narrative.
No

Total questions submitted: 39

Vendor D:

1. If selected for award, is the successful vendor required to register as a business in the State of South Dakota prior to contract execution or performance?

a. It is the responsibility of the vendor to confirm whether they are required to register with the State of South Dakota to do business.

2. Are there any local, county, or municipal business licenses, registrations, permits, or authorizations required for vendors performing services under this contract?

a. It is the responsibility of vendor to confirm these.

3. Does South Dakota State University require vendors to maintain a physical presence in South Dakota to perform this engagement?

a. No

4. The RFP references security documentation (SOC 2 Type II, ISO 27001, NIST CSF, HECVAT, VPAT, etc.). Are equivalent security controls or alternative documentation acceptable if a proposer does not maintain every listed certification?

a. Reasonable alternative documentation is acceptable but not preferred.

5. Will South Dakota State University accept a phased approach for security documentation if certain certifications are in progress or maintained by an affiliated technology provider?

a. To ensure an efficient and thorough evaluation of the proposal and vendor, we request that these documents are not provided in a phased manner.

6. Can the University provide any additional details regarding the expected technical environment, including existing CMS integrations, authentication methods, or identity management platforms that the selected vendor will be expected to support?

a. SDSU's primary web environment is based on Drupal 10, and vendors should assume that any CMS-related integrations will need to support the current production Drupal environment and future supported Drupal versions.

7. Is there an anticipated implementation timeline following contract award, including any required kickoff or deployment milestones?

a. SDSU anticipates contract award in August 2026. The implementation start date will be negotiated with the selected vendor based on project readiness, resource availability, and agreed-upon implementation planning.

8. Can the University provide additional information regarding the expected volume of content, websites, or domains to be included beyond the approximate 9,000 pages referenced in the RFP?

a. Initial proposal and term is for sdstate.edu domain only. Additional domains could be considered under a separate contract.

9. Are there any incumbent vendors currently providing these services, and if so, will transition assistance or historical data be made available to the selected vendor?

a. This is a new solution for SDSU.

10. Does SDSU currently utilize an enterprise SEO and/or AI Search Optimization platform (such as BrightEdge, Conductor, Siteimprove, SEMrush, or similar), or is the University seeking a new solution through this procurement?

a. SDSU currently uses Siteimprove and Google Analytics for website quality, accessibility, analytics, and limited SEO monitoring. SDSU does not currently utilize a dedicated LLM Search Optimization, GEO, AEO, or AI visibility platform. This procurement seeks a new solution in that category.

11. Are AI visibility monitoring, citation tracking, and AI-generated answer monitoring expected to be provided through automated platform functionality, or would managed services that include periodic monitoring, reporting, and strategic recommendations satisfy the University's requirements?

a. Batch reporting features within the tools is acceptable.

12. When referencing Drupal integration, is the University seeking a direct CMS integration, or would an external platform that analyzes and provides recommendations for Drupal-managed content be acceptable?

a. SDSU's preference is for a solution that can analyze and optimize content managed within the University's Drupal environment; however, SDSU does not require a direct CMS integration as a condition of proposal submission.

An external platform that ingests, analyzes, and provides recommendations for Drupal-managed content is acceptable, provided it meets the functional, reporting, governance, and security requirements defined in the RFP.

13. Will the selected vendor be expected to implement content recommendations and optimization activities, or is the University's expectation that the selected vendor will identify and prioritize opportunities while SDSU staff execute the content changes?

a. SDSU retains ownership and approval authority for content changes. Vendors may propose implementation assistance, consulting, or managed services; however, institutional content publishing and approval authority will remain with SDSU.

14. Which AI-powered search and answer platforms are considered in scope for optimization and reporting (e.g., Google AI Overviews, ChatGPT, Gemini, Claude, Perplexity, Microsoft Copilot, or others), and are all of these expected to be supported?

a. Yes, we are interested in those and would like flexibility to adapt as the technology changes.

15. Does the University anticipate that the selected vendor will primarily provide strategic recommendations and governance, or is the expectation that the vendor will actively manage and optimize the platform on an ongoing basis?

a. SDSU's preference is for a software platform that provides the functionality described in the RFP. However, vendors may propose professional services, strategic consulting, managed services, or hybrid approaches that enhance the University's ability to achieve its objectives.

16. Is the University seeking a software platform, professional services, or a combined solution? If a technology solution is expected, must it be a proprietary platform, or are managed services supported by industry-standard technologies acceptable?

a. SDSU's preference is for a software platform that provides the required functionality; however, vendors may propose professional services, managed services, or hybrid delivery models that enhance the University's ability to achieve the objectives of the RFP.

17. What reporting cadence does the University anticipate (e.g., monthly, quarterly, or another schedule), and are executive-level dashboards expected as part of the engagement?

a. Please describe the reporting capabilities available within the solution.

18. Will the selected vendor be provided access to existing analytics platforms (e.g., Google Analytics, Google Search Console, Bing Webmaster Tools, or other SEO reporting tools) as part of the engagement?

a. SDSU does not require integration with existing analytics platforms as a condition of the proposal. However, access to Google Analytics and other available analytics resources may be provided if supported by the proposed solution.

19. How will South Dakota State University measure the success of this engagement during the initial contract term? Are there specific KPIs or performance outcomes the University expects the selected vendor to achieve?

a. SDSU has not established specific KPI thresholds, accuracy requirements, or visibility improvement targets for this procurement. Because LLM visibility and answer-engine optimization are evolving rapidly and institutional baselines have not yet been established, SDSU is seeking vendor expertise in defining meaningful and measurable performance indicators as part of implementation.

20. Does the University have an existing baseline for SEO and AI search performance that will be shared with the selected vendor?

a. SDSU currently has access to traditional web analytics, search performance data, and content inventory information through existing institutional tools and platforms. However, SDSU has not established a formal baseline for LLM visibility, AI-generated answer performance, citation frequency, sentiment, or other emerging AI search metrics.

21. For SEO baseline metrics (e.g., crawl errors, indexation status, and page-level performance), may the selected vendor leverage existing analytics platforms such as Google Search Console and Bing Webmaster Tools, or is the University expecting these capabilities to be generated natively within the proposed solution?

a. SDSU does not require integration with existing analytics platforms as a condition of the proposal. However, access to Google Analytics and other available analytics resources may be provided if supported by the proposed solution.

22. The RFP references role-appropriate dashboards for non-technical users. Is the University seeking multiple role-based dashboards with unique user experiences, or would a configurable dashboard with exportable reporting for various stakeholders satisfy this requirement?

a. Yes, a configurable dashboard would be acceptable.

Vendor E:

1. The RFP references both a software platform and strategic consulting services. Is SDSU seeking a technology solution, a managed service, or a hybrid engagement that combines software and consulting?

a. SDSU's preference is for a software platform that provides the required functionality; however, vendors may propose professional services, managed services, or hybrid delivery models that enhance the University's ability to achieve the objectives of the RFP.

2. What are the top three outcomes SDSU hopes to achieve during the first year of this engagement (e.g., improved AI visibility, stronger SEO foundation, governance, content recommendations, staff enablement, or reporting)?

a. Improved AI visibility, through a stronger SEO foundation and content optimization recommendations.

3. Approximately how many domains, subdomains, and websites are expected to be included in the engagement? Should vendors assume only sdstate.edu or the university's broader web ecosystem?

a. Initial proposal and term is for sdstate.edu domain only. Additional domains could be considered under a separate contract.

4. Is SDSU looking for strategic recommendations only, or will the selected vendor also be expected to implement content and technical recommendations?

a. SDSU is seeking a solution that provides the capabilities described in the RFP.

5. Should vendors include content strategy only, or should pricing also include content writing, editing, and production of new AI-optimized content?

a. SDSU is seeking a solution that provides content recommendations.

6. Will SDSU have internal web development resources available to implement technical recommendations, or should vendors include technical implementation within their proposed services?

a. SDSU has internal resources that support website administration, content management, and web development; however, the availability and level of effort that can be dedicated to implementation activities may vary based on project scope, timing, and institutional priorities.

As a result, SDSU encourages vendors to clearly identify any assumptions regarding institutional staffing and technical resources required to successfully implement and maintain the proposed solution.

7. How frequently does SDSU anticipate receiving AI visibility reports and strategic recommendations (e.g., monthly, quarterly, or on demand)?

a. SDSU prefers a solution that supports ongoing monitoring with the ability to provide both scheduled reporting and on-demand reporting. Real-time reporting is not required.

8. Are there specific AI platforms SDSU considers highest priority (e.g., ChatGPT, Gemini, Google AI Overviews, Claude, Perplexity), or should vendors recommend the appropriate monitoring strategy?

a. Yes, we are interested in those and…

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it. Updated .