Introduction: the objective of a use‑centred RFP
Drafting an RFP for a reception AI avatar requires balancing technical requirements, operational constraints, legal obligations and objective evaluation criteria. The document must enable diverse vendors to reply in a comparable way and allow the client to rank responses without ambiguity.
This guide provides a structured checklist, sample contractual clauses and SLAs, a weighted evaluation grid and a mapping to verify common technical differentiators (RAG, multi‑LLM, integrations, document formats, hardware compatibility, accessibility, 24/7 support).
Why structure the RFP from the start
A structured RFP reduces the risk of incomplete comparisons, prevents omissions on sensitive topics (data protection, accessibility, continuity) and clarifies expected interfaces with business systems. It also eases the contract negotiation phase by listing technical and operational obligations up front.
The operational aim is simple: obtain homogeneous, measurable and verifiable responses to select, on documented criteria, the vendor best suited to the deployment context (sites, audiences, regulatory constraints).
Structured RFP checklist – mandatory sections
Include the following sections as minimum requirements: contract subject, scope of sites, description of priority use cases, accessibility constraints, language expectations, interaction formats (voice, touch), and expected operating modes.
Specify essential technical elements: compatibility of screens/kiosks with OS families (Tizen, Android, Windows) according to existing infrastructure, network and security constraints, multi‑site deployment capabilities and centralized knowledge base update modalities.
Project subject and scope
Priority use cases and exclusions
Accessibility constraints (voice modes, subtitles, sign language (LSF), touch)
Supported languages and multilingual capability
Hardware compatibility and OS families (Tizen, Android, Windows) - specify existing setup
Target architecture and network/security requirements
RFP checklist – operational and governance sections
Request clarifications on content governance: who edits the knowledge base, the business answers validation process, update tools and the granularity of editing rights.
Specify operational expectations: maintenance procedures, expected availability (service may need to operate 24/7), support modalities, team training and incident recovery. Also indicate deliverables expected for the pilot phase and the move to production.
Governance model and roles (editor, approver, administrator)
Business content update process
Pilot deployment plan and acceptance criteria
Training modalities and documentation
Operational support and 24/7 on‑call arrangements
Legal and data security sections to request
Require a clear description of data processing, the scope of data collected and the security measures in place. Ask for details on data hosting and the option for deployment on a dedicated infrastructure if needed.
Specify contractual legal requirements: liability, intellectual property of prompts/personas, confidentiality, backup and restoration conditions, end‑of‑contract conditions and data takeover. Frame these clauses as eligibility criteria rather than optional items.
Description of processing and purposes
Hosting location and infrastructure options
Technical and organizational security measures
Ownership of content and persona adaptations
Data return or deletion procedures at contract end
Sample contract clauses and SLA structure (to customise)
Providing sample clauses facilitates comparison. Here are the essential elements the RFP should present for vendor response: availability guarantee, support levels, scheduled maintenance, recovery after incident, confidentiality and audits. Make clear that numeric values will be negotiated and inserted in the final contract.
Example SLA structure to include in the RFP: definition of severity levels, initial response commitment by severity, resolution commitment, notification and escalation procedures, planned maintenance and reporting. Also specify the requirement for a support organisation capable of operating 24/7 if the service is exposed continuously.
Definitions: availability, scheduled interruption, critical incident
Severity levels and expected responses (initial response, resolution)
Notification and escalation procedures
Scheduled maintenance and work windows
Periodic reporting and service review
Weighted evaluation grid and scoring example (illustrative)
An evaluation grid helps compare offers objectively. Present the main criteria (technical, security, accessibility, integrations, governance, total cost) and explain the internal weighting chosen. It is important to adapt weighting to the business context and project priorities.
Illustrative example: weight technical and integration criteria more heavily if the project requires connections to business systems, or prioritise accessibility if the audience is predominantly vulnerable. The following is illustrative and must be adapted to needs.
Technical criteria: architecture, multi‑LLM support, RAG, document formats
Security and compliance: technical measures, hosting, audits
Accessibility: voice/touch modes, subtitles, sign language (LSF)
Operational: governance, training, 24/7 support
Cost and economic model: licences, integration costs, maintenance
Practical mapping to verify technical differentiators
To verify vendors' technical claims, request reproducible evidence: demonstrations on real cases, access to a test environment to validate RAG answer quality, multilingual tests and integration scenarios with mock APIs or sandboxes.
Ask each vendor to detail supported document formats and volumes for ingestion, version management, and compatible or orchestratable LLM engines. Verify planned compatibility with screen/kiosk families (Tizen, Android, Windows) and the ability to operate in voice, touch or hybrid modes depending on configurations.
Requested evidence: demonstration, sandbox environment, business test cases
Document formats supported for RAG (PDF, DOCX, XLSX, TXT, CSV, NDJSON) - request details
Multi‑LLM support and orchestration strategy
Hardware compatibility and multi‑site deployment modalities
Accessibility tests and user validation evidence
Operational caution points and common mistakes to avoid
Do not neglect content governance: leaving sole responsibility for answers to the vendor without defining an internal validation process often leads to quality drift. Specify who is responsible for updating business information.
Do not skip the pilot phase. A pilot validates integrations, answer quality, voice and touch interaction ergonomics, and user acceptance. Also clarify in the RFP the scope of tests acceptable for final acceptance.
Explicitly define content governance
Plan representative test scenarios and a formal pilot
Verify the vendor's ability to provide a test environment
Do not confuse promised availability with operational on‑call arrangements
In practice: questions to ask vendors during interviews
To complement the written dossier, prepare a set of questions around sensitive points: how the vendor handles data confidentiality, guarantees on backups and restores, how multilingual tests are conducted, and which back‑office tools are provided to edit the knowledge base.
Also request targeted demonstrations on interruption handling, bulk content updates, and the ability to customise persona and voice within rights and image constraints. These elements assess operational maturity beyond written answers.
Example questions: incident management, recovery, data localisation
Demonstration scenarios to request: document import, RAG query, multilingual voice test
Evaluate the ergonomics of the editing back‑office
Conclusion: formalise to reduce risk and ease selection
A complete and structured RFP enables comparing vendors on objective grounds and reduces risks related to security, accessibility and operations. By structuring mandatory sections, offering sample clauses and an evaluation grid, you facilitate documented decision‑making.
SANIA can illustrate some of the operational differentiators mentioned here: a reception AI avatar designed for screen or interactive kiosk, available 24/7 and capable of communicating in many languages. To assess the fit of this approach for your context and receive a customisable RFP example, you can request a demonstration and an RFP kit.