AI LMS RFP Template for Universities | Mentron

A Request for Proposal (RFP) is the formal document that universities use to solicit, evaluate, and select an AI LMS vendor. A well-crafted RFP does three things at once: it communicates the university's requirements clearly, it gives the vendor a structured format to respond in, and it gives the evaluation committee a fair basis to compare the responses. A poorly crafted RFP produces vague responses, mismatched expectations, and post-contract surprises. An AI LMS RFP template for universities is the structured framework that ensures the procurement is thorough, the comparison is fair, and the selection is defensible — and the template is as important as the technical evaluation that follows.

This guide covers the RFP process, the 12 sections of a complete RFP, the evaluation criteria, the vendor response format, the scoring framework, the pricing structure, the contractual terms, the negotiation checklist, and the common pitfalls. For the broader vendor evaluation framework, see vendor evaluation checklist for AI LMS. For the TCO comparison that supports the financial decision, see total cost of ownership for AI LMS. For the implementation playbook that follows the procurement, see AI LMS implementation checklist for 90 days.

The RFP Process

The RFP process is the structured workflow that the university follows from the decision to procure through to the contract signature. The process has 7 phases.

Phase 1 — Decision to Procure (Weeks 1-4)

The university decides to procure an AI LMS. The decision is typically driven by a strategic priority (improve learning outcomes, modernize the technology, support new pedagogical models) or a specific trigger (end of life of the current LMS, a major accreditation requirement, a competitive necessity). The decision is documented with the rationale, the budget envelope, and the timeline.

Phase 2 — Requirements Gathering (Weeks 5-10)

The university gathers the requirements from all the stakeholders: faculty, students, IT, registrar, library, accessibility services, academic affairs, and finance. The requirements are categorized into: must-haves, should-haves, and nice-to-haves. The requirements are documented in a structured format that becomes the foundation of the RFP.

Phase 3 — RFP Drafting (Weeks 11-14)

The university drafts the RFP. The drafting is led by a small team (typically the IT lead, the procurement officer, and a faculty representative) with input from the stakeholders. The draft is reviewed by the legal team for the contractual sections and by the accessibility team for the accessibility sections.

Phase 4 — RFP Issuance (Week 15)

The RFP is issued to the longlist of vendors. The issuance is typically through a procurement portal (e.g., the university's procurement system, a third-party platform like Bonfire or BidNet). The issuance is accompanied by a pre-bid conference call (typically 1-2 weeks after issuance) where the vendors can ask clarifying questions.

Phase 5 — Vendor Responses (Weeks 16-22)

The vendors respond to the RFP within the specified deadline (typically 4-6 weeks). The responses are submitted in the format specified in the RFP. The university may issue a clarification or addendum during this period if new information emerges.

Phase 6 — Evaluation and Selection (Weeks 23-28)

The university evaluates the responses against the scoring framework. The evaluation is typically done by a committee of 5-8 stakeholders. The committee scores the responses, discusses the scores, and shortlists 2-3 vendors for the pilot and the reference checks. The committee then makes a final recommendation to the procurement officer.

Phase 7 — Negotiation and Contracting (Weeks 29-36)

The university negotiates the contract with the selected vendor. The negotiation covers: the pricing, the terms, the SLAs, the data privacy, the AI governance, and the exit provisions. The contract is reviewed by the legal team and signed by the authorized signatory. The procurement is complete.

The 7 phases of the RFP process take 8-9 months from the decision to procure to the contract signature. Compressed timelines (3-4 months) are possible for urgent needs but increase the risk of a flawed procurement.

The 12 Sections of a Complete RFP

The 12 sections are the structure of the RFP document. Each section has a specific purpose, and the sections are presented in a logical order.

Section 1 — Executive Summary

The executive summary provides an overview of the university, the procurement, and the desired outcomes. The summary is typically 1-2 pages and includes: the university's mission and size, the current LMS state, the desired future state, the procurement timeline, and the contact information for questions.

The executive summary is the first impression for the vendor. A clear summary signals a well-organized procurement; a vague summary signals a procurement that may be challenging to work with.

Section 2 — University Background

The university background provides the context for the procurement. The background includes: the institution's history, the academic structure (schools, colleges, departments), the student demographics, the faculty demographics, the technology landscape, and the strategic priorities. The background is typically 3-5 pages.

The background helps the vendor tailor the response to the university's context. A vendor that understands the university is a vendor that can propose a relevant solution.

Section 3 — Current State

The current state describes the existing learning technology stack. The description includes: the current LMS, the SIS, the lecture capture, the video conferencing, the assessment tools, the content repositories, and the integrations. The description also includes the known pain points and the desired improvements.

The current state gives the vendor a baseline. A vendor that understands the current state is a vendor that can propose a migration path.

Section 4 — Scope of the Procurement

The scope of the procurement defines what is being procured. The scope includes: the platform itself, the implementation services, the training, the support, the integration, the data migration, the customization, and the optional add-ons. The scope also defines the user populations (students, faculty, staff, parents, alumni) and the geographic scope (single campus, multi-campus, multi-country).

The scope is the boundary of the procurement. A clear scope prevents scope creep during the negotiation.

Section 5 — Functional Requirements

The functional requirements are the must-haves and should-haves that the platform must meet. The requirements are organized into categories: AI capabilities (content generation, adaptive learning, AI tutoring, personalization), traditional LMS features (course management, assessment, reporting, mobile), accessibility (WCAG 2.1 AA, assistive technology), integration (LTI 1.3, SAML, SIS sync, grade passback), security (encryption, access controls, audit logging), and compliance (FERPA, GDPR, accessibility).

The functional requirements are the evaluation criteria. The requirements should be specific enough to be testable (e.g., "the platform must support LTI 1.3 Advantage for all integration types") and not vague (e.g., "the platform must integrate with our systems").

Section 6 — Technical Requirements

The technical requirements define the non-functional aspects of the platform. The requirements include: the deployment model (cloud, private cloud, on-premise), the browser and device support, the performance requirements (page load time, concurrent user capacity, uptime), the scalability (peak load during registration, mid-term, finals), the API capabilities, the data export format, and the backup and disaster recovery.

The technical requirements are the operational criteria. The requirements should be specific, measurable, and aligned with the university's IT standards.

Section 7 — AI-Specific Requirements

The AI-specific requirements cover the AI features in depth. The requirements include: the AI model documentation, the data usage restrictions (no training on university data), the bias testing and the audit rights, the model pinning and the update notification, the AI explainability, the AI safety guardrails, the AI incident response, and the regulatory compliance (EU AI Act, where applicable).

The AI-specific requirements are the new layer. The requirements are increasingly important as AI regulations evolve.

Section 8 — Security and Compliance Requirements

The security and compliance requirements define the security and compliance posture the university requires. The requirements include: the certifications (SOC 2 Type II, ISO 27001, FERPA documentation), the data residency, the encryption (in transit, at rest, customer-managed keys), the access controls (RBAC, ABAC, SSO, MFA), the audit logging, the incident response, the breach notification, and the sub-processor approval.

The security and compliance requirements are the trust criteria. The requirements are typically reviewed by the university's CISO or IT security lead.

Section 9 — Implementation and Support Requirements

The implementation and support requirements define the implementation services, the training, and the ongoing support. The requirements include: the implementation methodology, the implementation timeline, the implementation team (university and vendor), the training (format, content, audience, schedule), the support (channels, SLAs, response times), the customer success (the designated CSM, the QBR cadence), and the community (the user community, the developer community).

The implementation and support requirements are the operational criteria. The requirements are typically reviewed by the IT lead and the L&D lead.

Section 10 — Pricing Structure

The pricing structure defines how the vendor should present the pricing. The structure should require: the pricing model (per user, per course, per seat, site license), the pricing tier (the features included at each tier), the pricing for the AI features (included, add-on, metered), the implementation cost, the support cost, the customization cost, the contract term, the pricing growth cap, and the exit cost.

The pricing structure is the financial framework. The structure should enable the TCO comparison across the vendors.

Section 11 — Contractual Terms

The contractual terms define the legal and commercial framework. The terms include: the master service agreement, the data processing agreement, the service level agreement, the security exhibit, the AI exhibit, the acceptable use policy, the warranty, the indemnification, the limitation of liability, the termination, the data return and deletion, and the dispute resolution.

The contractual terms are the legal foundation. The terms should be reviewed by the university's legal counsel.

Section 12 — Evaluation Criteria and Process

The evaluation criteria and process define how the responses will be evaluated. The criteria include: the scoring framework (the weights for each section), the scoring scale (0-3, 0-5, 0-10), the evaluation committee (the members and the recusal rules), the evaluation timeline, the pilot criteria, the reference check criteria, and the final selection criteria.

The evaluation criteria and process are the selection framework. The criteria should be transparent to the vendors and applied consistently.

The Evaluation Criteria

The evaluation criteria translate the RFP requirements into the scoring framework. The criteria should be weighted to reflect the university's priorities.

The AI Capability Weight (30%)

The AI capability weight is typically 25-35% of the total score. The weight reflects the importance of the AI features to the university's strategic priorities. The sub-criteria include: content generation, adaptive learning, AI tutoring, personalization, skill inference, content recommendations, and analytics.

The Traditional LMS Weight (15%)

The traditional LMS weight is typically 10-20% of the total score. The weight reflects the importance of the foundational features. The sub-criteria include: course management, assessment, reporting, mobile, offline, and accessibility.

The Integration Weight (15%)

The integration weight is typically 10-20% of the total score. The weight reflects the importance of the platform's fit with the existing technology stack. The sub-criteria include: SIS integration, SSO, LTI 1.3, grade passback, video conferencing, and custom APIs.

The Security and Compliance Weight (15%)

The security and compliance weight is typically 10-20% of the total score. The weight reflects the importance of the platform's security and compliance posture. The sub-criteria include: certifications, data residency, encryption, access controls, audit logging, incident response, and AI governance.

The Implementation and Support Weight (10%)

The implementation and support weight is typically 5-15% of the total score. The weight reflects the importance of the implementation experience and the ongoing support. The sub-criteria include: implementation methodology, training, support SLAs, customer success, and community.

The Pricing Weight (10%)

The pricing weight is typically 5-15% of the total score. The weight reflects the importance of the financial decision. The sub-criteria include: the TCO over 3 years, the pricing growth cap, the pricing transparency, and the exit cost.

The User Experience Weight (5%)

The user experience weight is typically 5-10% of the total score. The weight reflects the importance of the user adoption. The sub-criteria include: learner experience, instructor experience, administrator experience, and accessibility.

The Total Weight (100%)

The total weight sums to 100%. The weights should reflect the university's strategic priorities. A university that is buying primarily for the AI capabilities should weight the AI capability higher; a university that is buying primarily for the integration should weight the integration higher.

The Vendor Response Format

The vendor response format defines how the vendor should structure the response. The format should be standardized across all vendors to enable the comparison.

The Response Template

The response template should include: a cover letter, the executive summary, the company's overview, the product overview, the response to each functional requirement (with the question, the response, and any supporting documentation), the response to each technical requirement, the response to the AI-specific requirements, the response to the security and compliance requirements, the implementation plan, the support model, the pricing (in the structure specified), the case studies (3-5 references), and the proposed contract (with the university's redlines).

The Response Length

The response length should be specified to prevent excessive verbosity. A typical response: 50-100 pages for the main response, plus appendices for the detailed documentation. The appendices may include: the product demo screenshots, the architecture diagrams, the security certifications, the sample reports, and the case study details.

The Response Deadline

The response deadline should allow the vendor sufficient time to prepare a quality response. A typical deadline: 4-6 weeks from the RFP issuance. The deadline should be firm, with a clear process for extension requests.

The Response Submission

The response submission should specify the format (PDF, Word, both), the number of copies, the submission portal, and the contact for questions. The submission should be acknowledged by the university within 24-48 hours.

The Pre-Bid Conference

The pre-bid conference is a 1-2 hour call held 1-2 weeks after the RFP issuance. The conference is an opportunity for the vendors to ask clarifying questions. The conference is recorded and the questions and answers are shared with all vendors (anonymized if necessary) to ensure fairness.

The Scoring Framework

The scoring framework defines how the responses are scored. The framework should be objective, consistent, and transparent.

The Scoring Scale

The scoring scale should be 0-3 or 0-5, with clear definitions for each score. A typical 0-3 scale:

0 — does not meet the requirement
1 — partially meets the requirement
2 — meets the requirement
3 — exceeds the requirement

A typical 0-5 scale:

0 — does not meet the requirement
1 — partially meets the requirement, with significant gaps
2 — partially meets the requirement, with minor gaps
3 — meets the requirement
4 — exceeds the requirement
5 — exceeds the requirement with strong evidence

The Scoring Process

The scoring process is typically:

Each committee member scores the responses independently
The committee meets to discuss the scores
The committee agrees on the consensus score for each requirement
The consensus scores are aggregated to produce the total score
The total scores are used to rank the vendors

The independent scoring prevents the influence of dominant committee members. The consensus discussion surfaces the disagreements and allows for the resolution.

The Pilot Verification

The pilot verification is a separate step after the initial scoring. The vendors in the top 2-3 are invited to a pilot demo on the university's content. The pilot demo is scored separately and the score is added to the initial score. The pilot verification is the most reliable signal in the evaluation.

The Reference Check

The reference check is another separate step. The vendors in the top 2-3 are asked to provide 3-5 references. The references are contacted and the responses are scored. The reference check is the most reliable qualitative signal in the evaluation.

The Final Selection

The final selection is based on the total score (initial scoring + pilot verification + reference check), the pricing (TCO), the contractual terms, and the qualitative judgment of the committee. The selection is documented with the rationale, the assumptions, and the risks.

The Pricing Structure

The pricing structure defines how the vendor should present the pricing. The structure should enable the TCO comparison across the vendors.

The Pricing Components

The pricing components should include:

The platform license or subscription (per user, per course, per seat, site license)
The AI features (included in the base, add-on, metered)
The implementation services (one-time, included, professional services)
The training (included, additional cost)
The support (included in the license, tiered, premium)
The integration (included, additional cost)
The customization (included up to a cap, additional cost)
The data migration (included, additional cost)
The annual price escalation (cap, none, specific percentage)
The contract term discounts (multi-year, prepay)
The exit costs (data export, transition support, contract termination)

The pricing components should be itemized to enable the comparison. A vendor that provides only a single number is a vendor that does not enable the comparison.

The Pricing Assumptions

The pricing assumptions should be specified. The assumptions include: the user count (current and projected), the course count, the integration count, the customization hours, the support tier, and the contract term. The assumptions should be the same for all vendors to enable the comparison.

The Pricing Examples

The pricing examples should include: the year 1 cost, the year 2 cost (with the escalation), the year 3 cost, the 3-year TCO, and the cost per user per year. The pricing examples should use the university's actual inputs, not the vendor's defaults.

The Pricing for AI Features

The pricing for AI features should be specified explicitly. The options include: included in the base price (the most common for AI-native challengers), add-on price (the most common for established vendors), metered usage (the most common for AI features with high variable cost), or unlimited usage with a fair use policy. The pricing model should be transparent and predictable.

The Pricing Growth Cap

The pricing growth cap should be specified. The cap is typically 3-5% per year for multi-year contracts. The cap protects the university from the pricing growth that the vendor might apply at renewal. The cap should be in the contract, not just in the proposal.

The Contractual Terms

The contractual terms are the legal framework that governs the relationship. The terms should be specified in the RFP so the vendors can respond with the proposed contract.

The Master Service Agreement

The master service agreement (MSA) is the overarching contract. The MSA includes: the scope of the services, the term and the termination, the fees and the payment terms, the warranties, the indemnification, the limitation of liability, the confidentiality, the intellectual property, the compliance with laws, the dispute resolution, and the general provisions.

The MSA should be based on the university's standard contract template, with the vendor's redlines. The university should not accept the vendor's standard contract as-is, because the vendor's contract is typically vendor-favorable.

The Data Processing Agreement

The data processing agreement (DPA) is the contract that governs the vendor's processing of personal data on the university's behalf. The DPA is required by GDPR and by FERPA's school official designation. The DPA should include: the scope and purpose of the processing, the categories of data and the data subjects, the obligations of the vendor, the obligations of the university, the sub-processor approval, the international data transfer, the data subject rights, the breach notification, the data return and deletion, and the audit rights.

The DPA should be the university's standard DPA, with the vendor's redlines. The university should not accept the vendor's standard DPA as-is.

The Service Level Agreement

The service level agreement (SLA) is the contract that specifies the performance commitments. The SLA should include: the uptime (99.9% or 99.95%), the support response time (1 hour for critical, 4 hours for high, 24 hours for medium), the resolution time, the performance metrics, the credits for breaches, and the escalation process.

The SLA should be specific, measurable, and enforceable. A vendor that does not commit to specific SLAs is a vendor that is not accountable for the performance.

The Security Exhibit

The security exhibit is the contract that documents the vendor's security commitments. The exhibit should include: the certifications, the security controls, the data processing commitments, the incident response, the audit rights, the data return and deletion, and the insurance requirements.

The security exhibit is the contract that the CISO or the IT security lead signs off on. The exhibit should be reviewed by the university's security team, not just the legal team.

The AI Exhibit

The AI exhibit is the contract that documents the vendor's AI commitments. The exhibit should include: the AI model documentation, the data usage restrictions, the data retention and the zero-retention option, the bias testing and the audit rights, the model pinning and the update notification, the AI incident response, and the regulatory cooperation.

The AI exhibit is the new contractual layer. The exhibit should be reviewed by the legal team with AI expertise, or by an external advisor.

The Negotiation Checklist

The negotiation checklist is the structured list of items to negotiate in the contract. The checklist should be prioritized by impact.

Must-Have Items

The must-have items are the non-negotiable terms. The must-haves include:

The data ownership (the university owns the data)
The data export (the university can export the data in standard formats on contract termination)
The data deletion (the vendor deletes the data within 30 days of contract termination)
The breach notification (the vendor notifies the university within 24-48 hours of a breach)
The audit rights (the university can audit the vendor's compliance)
The pricing growth cap (3-5% per year)
The termination for convenience (the university can terminate the contract without cause with 90 days' notice)
The SOC 2 Type II commitment
The FERPA / GDPR compliance commitment
The zero-retention option for AI processing

The must-haves should be in the contract. A vendor that refuses a must-have is a vendor to walk away from.

Should-Have Items

The should-have items are the important but not non-negotiable terms. The should-haves include:

The SLA credits (the credits for SLA breaches)
The data residency options (the data is stored in the approved regions)
The customer-managed encryption keys (the university holds the encryption keys)
The private connectivity (the connection to the university's network is over a private link)
The dedicated customer success manager (a CSM is assigned to the university)
The roadmap transparency (the vendor shares the roadmap with the university)
The user community access (the university can participate in the user community)
The training budget (the vendor provides an annual training budget)

The should-haves should be negotiated actively. A vendor that agrees to a should-have is a vendor that is invested in the relationship.

Nice-to-Have Items

The nice-to-have items are the bonus terms. The nice-to-haves include:

The marketing co-investment (the vendor co-invests in marketing the relationship)
The case study rights (the vendor can use the university as a case study, subject to the university's approval)
The early access to features (the university gets early access to new features)
The conference speaking (the university can present at the vendor's user conference)
The reference customer status (the university is a reference customer for new prospects)

The nice-to-haves are the relationship-builders. A vendor that agrees to the nice-to-haves is a vendor that values the relationship beyond the contract.

The Common Pitfalls

The common pitfalls are the failure modes that derail many RFP processes. The pitfalls are predictable, and the awareness of them is the first defense.

Pitfall 1 — The Vague Requirements

The vague requirements (e.g., "the platform must integrate with our systems") produce vague responses. The requirements should be specific, measurable, and testable. A requirement that cannot be verified is a requirement that will not be enforced.

Pitfall 2 — The AI Capability Overweight

The AI capability overweight (e.g., 50% or more of the score) can produce a vendor with strong AI but weak traditional LMS features. The weighting should be balanced. The AI capability is important, but the traditional features are the foundation.

Pitfall 3 — The Price-Driven Decision

The price-driven decision (selecting the lowest-priced vendor) can produce a vendor that does not meet the other criteria. The pricing is one input to the decision, not the only input. The TCO comparison is the financial framework, not the headline price.

Pitfall 4 — The Demo-Only Evaluation

The demo-only evaluation (selecting the vendor with the best demo) can produce a vendor that demos well but does not perform in production. The evaluation should include the pilot, the reference checks, the trial access, and the financial due diligence.

Pitfall 5 — The No-Pilot Shortcut

The no-pilot shortcut (selecting without testing on the university's content) is risky. The pilot is the most reliable signal in the evaluation. A procurement without a pilot is a procurement that takes the university live with unmitigated risk.

Pitfall 6 — The Vendor-Favorable Contract

The vendor-favorable contract (accepting the vendor's standard contract as-is) is a common mistake. The contract should be the university's standard contract, with the vendor's redlines. A vendor that will not accept the university's contract is a vendor that is not willing to negotiate.

Pitfall 7 — The No-Exit Plan

The no-exit plan (failing to negotiate the exit terms) is a common mistake. The exit terms are the university's insurance. A vendor that will not agree to clean exit terms is a vendor that the university is locked into.

Pitfall 8 — The Implementation Underestimate

The implementation underestimate (assuming the implementation will be fast and easy) is a common mistake. The implementation timeline and the resources required should be specified in the contract. A vendor that underestimates the implementation is a vendor that will underdeliver.

The Timeline Summary

A typical RFP timeline:

| Phase | Duration | Description | |-------|----------|-------------| | Decision to procure | 4 weeks | Internal alignment, budget approval | | Requirements gathering | 6 weeks | Stakeholder input, requirements documentation | | RFP drafting | 4 weeks | Drafting, internal review, legal review | | RFP issuance | 1 week | Issuance, pre-bid conference | | Vendor responses | 6 weeks | Vendor preparation, submission | | Evaluation | 6 weeks | Initial scoring, pilot, references, final selection | | Negotiation and contracting | 8 weeks | Contract negotiation, signature | | Total | 35 weeks (~8.5 months) | End-to-end procurement |

Compressed timelines of 3-4 months are possible for urgent needs but increase the risk. A university that follows the 8.5-month timeline reaches a defensible decision.

Conclusion

An AI LMS RFP template for universities is the structured framework that ensures the procurement is thorough, the comparison is fair, and the selection is defensible. The RFP process, the 12 sections, the evaluation criteria, the vendor response format, the scoring framework, the pricing structure, the contractual terms, the negotiation checklist, and the common pitfalls are the structure.

The university that invests in the RFP process reaches a decision that the procurement office, the legal team, the IT team, the faculty, and the administration can all support. The university that shortcuts the RFP reaches a decision that is harder to defend when the platform underperforms.

Ready to procure an AI LMS for your university? Schedule a Mentron demo and bring your requirements document, your evaluation criteria, and your procurement timeline — by the end of the call, we will walk through the RFP template and the evaluation framework.

Summary

A defensible ai lms rfp template is more than a procurement document — it is a forcing function for institutional alignment on data privacy, integration depth, accessibility, and pedagogical fit. The ai lms rfp template described in this guide is built around the assumption that buying ai lms rfp template is a 12-18 month commitment, not a quarter, and that the institution's ability to articulate what success looks like before signing matters more than the feature checklist a vendor publishes. Use this ai lms rfp template as a starting point, adapt the weighting to your institution's priorities, and budget time for a structured pilot before the contract is finalized.

References and Further Reading

The frameworks, standards, and research cited throughout this article draw on the following sources.

EDUCAUSE Review on AI in higher education — educause.edu
OECD — AI and the future of skills (OECD.AI) — oecd.org

Frequently Asked Questions

How long does a typical university AI LMS RFP take?

A typical RFP takes 8-9 months from the decision to procure to the contract signature. The phases include requirements gathering (6 weeks), RFP drafting (4 weeks), vendor responses (6 weeks), evaluation (6 weeks), and negotiation (8 weeks). Compressed timelines of 3-4 months are possible but increase the risk of a flawed procurement.

How many vendors should be in the longlist and the shortlist?

A typical longlist is 5-10 vendors. The longlist is sourced from peer institutions, industry analyst reports, and market awareness. A typical shortlist is 3-5 vendors, narrowed from the longlist based on the initial RFI responses. The pilot is conducted with 2-3 vendors. The selection is made from the pilot-verified shortlist.

What is the most common mistake in AI LMS RFPs?

The most common mistake is the vague requirements. The requirements that are vague (e.g., "the platform must integrate with our systems") produce vague responses and enable the vendor's interpretation. The requirements should be specific, measurable, and testable. A requirement that cannot be verified is a requirement that will not be enforced.

Should the AI capability be weighted more than the traditional LMS features?

The AI capability should be weighted in proportion to the university's strategic priorities, typically 25-35% of the total score. A weight of 50% or more can produce a vendor with strong AI but weak traditional features. The weighting should be balanced. The AI capability is the differentiator, but the traditional features are the foundation.

How do I handle a vendor that will not accept the university's standard contract?

The vendor's refusal to accept the university's standard contract is a red flag. The vendor that is not willing to negotiate the contract is a vendor that does not value the relationship. The university should walk away from the vendor and select a vendor that is willing to negotiate. The contract is the enforcement mechanism for the relationship.