Make the procurement question concrete
An effective request for proposal describes a service problem that suppliers can demonstrate against. State who will use the assistant, where they will encounter it, and which institution-owned information it may use. Identify the first release's supported tasks, such as explaining admissions steps or finding the right support office. Separate those from future ambitions so every bidder estimates the same boundary.
Include representative source documents and a small, sanitised question set. Avoid sharing actual student records just to obtain a quote. Ask suppliers to explain assumptions and dependencies, including institution staff time. The RFP should make it possible to distinguish a polished generic demonstration from a working implementation of the institution's own workflow.
Ask for evidence about content and answers
Require a process for approving sources, identifying their owners, recording review dates, and retiring obsolete material. Ask how the system distinguishes a current policy from an old prospectus, how it handles conflicting documents, and what it does when no supported answer exists. Request visible source links or an equivalent traceable explanation for factual institutional answers.
An illustrative test could place an older fee schedule beside a current one and ask for the relevant fee. The supplier should show version selection and the exact source used, or decline to answer when authority remains unresolved. Treat any invented figure or unsupported assurance as a failed case requiring investigation. A statement that the model is accurate is not acceptance evidence.
Specify the student experience
Ask for clear AI disclosure, understandable error messages, accessible navigation, and an obvious route to a person. Include keyboard use, screen-reader behaviour, mobile layouts, and the experience when the assistant is unavailable. W3C's WCAG documentation offers an accessibility reference; suppliers should identify the requirements they will implement and the evidence they will provide.
If multiple languages are required, request testing in each supported language with institutional terminology and realistic mixed-language questions. Define whether the assistant can answer from translated content and what happens when a source exists only in one language. For child-facing use, involve the appropriate safeguarding and educational stakeholders in reviewing the proposed experience before the pilot begins.
Define permissions, data handling, and handoff
Ask suppliers to diagram the flow of prompts, retrieved content, account identifiers, logs, and staff tickets. The diagram should name each system involved and identify which data is retained where. Ask which providers process information, what configuration choices are available, and how deletion, access changes, and incident investigation work. Institutional specialists should evaluate applicable obligations for the intended setting.
Define escalation as an operational workflow. State which questions must reach staff, what information accompanies them, which team receives them, and how the student sees progress. The assistant should not claim that a message was delivered without confirmation from the destination. Include failures such as a closed queue, unavailable connector, or invalid contact details.
Use a structured supplier response
A consistent response format makes review easier for procurement, teaching, student services, and IT. Ask suppliers to mark each requirement as included, optional, dependent on discovery, or unsupported. Require an explanation where a feature relies on institution-provided content or external platform access.
| RFP area | Evidence to request |
|---|---|
| Scope | Supported tasks, exclusions, users, and launch channels |
| Quality | Sample answers, source trace, evaluation approach, and failure cases |
| Integration | Required permissions, test environment, administrator tasks, and rollback |
| Operations | Content ownership, incident route, monitoring, and support responsibilities |
| Commercials | Milestones, acceptance gates, recurring assumptions, and change control |
Evaluate the whole service journey
Use a moderated demonstration where bidders receive the same realistic cases. Include normal questions, incomplete details, requests for exceptions, an inaccessible source, and an explicit request for staff. Have the service owner judge correctness, IT judge access boundaries, and intended users judge whether the next step is clear. Record reasons for scores instead of relying on a single impression.
For a custom development engagement, the contract should identify delivered artefacts, configuration ownership, documentation, and the process for maintaining the system after launch. White Storm Technologies can scope an institutional assistant around that brief. The strongest starting point is a narrow workflow with named owners and demonstrable acceptance criteria.
Sources & further reading
Primary references checked for this article. Practical examples are illustrative, not client results.
Apply this to your project.
Discuss a student-support chatbot that uses approved institutional information and connects unresolved questions to staff, with clear confirmation when a support request is created.
Explore Education Chatbot Development
