Introduction
Launching an RFP for an AI avatar solution on an interactive kiosk requires translating business expectations into clear technical, operational and contractual requirements. This document offers a ready-to-use template to structure the RFP, define actionable selection criteria for an evaluation committee and build a proof-of-concept (POC) protocol that lets you assess candidates on realistic scenarios.
The guide covers the mandatory sections of the specification, the security and governance sections for the knowledge base, a model of contract clauses to negotiate (SLA, support, data ownership) and an operational POC protocol. It is aimed at CIOs, customer experience leads, IT procurement and project managers responsible for the pilot and vendor selection.
Recommended structure of the specification
To facilitate comparison of proposals, the RFP should follow a consistent structure. Ask candidates to complete each section and to provide documented evidence, functional demonstrations and technical references.
Provide a standardized response format with technical appendices and a scoring grid supplied to bidders to ensure objective evaluation.
Project summary and scope of pilot sites
Detailed functional requirements
Technical specifications and hardware compatibility
Security, privacy and knowledge-base governance
Operations, maintenance and operational support
POC protocol and functional and technical acceptance criteria
Functional requirements to formalize
List precisely the expected uses of the avatar on kiosk or screen: welcome, product information, wayfinding, business FAQ, escalation to a human agent. For each use, specify the expected user input (voice, touch), output channels (speech synthesis, on-screen text) and the required level of autonomy.
Document language and persona requirements. For example, indicate the priority languages in scope and expectations about persona consistency. Note that some multilingual capabilities may be provided by the vendor: SANIA can communicate in more than 100 languages, but the RFP must request the expected quality for targeted languages and the associated tests.
Interaction modes supported: touch only, voice only, or hybrid
Priority use cases to run during the POC
Expectations for visual and vocal customization (persona)
Accessibility constraints to verify on site
Technical specifications and compatibility
Describe the target infrastructure: types of screens and kiosks, system-on-chip / operating systems (e.g. Samsung Tizen, Android, Windows). State that effective compatibility must be tested during the POC, since OS availability depends on the hardware deployed at each site. Also specify network, proxy and security constraints expected.
Request clear information on the software architecture: hosting modes (cloud, edge, hybrid), the ability to use multiple LLM engines depending on configuration, and exposed interfaces (APIs, webhooks) for POS, CRM or inventory integrations. Clarify that each third-party integration is a specific integration phase that must be costed.
Compatibility with OS families to be specified site-by-site and tested in POC
Hosting options offered and operational constraints
Technical interfaces available for real-time integration
Audio requirements: ASR, TTS and handling of noisy environments
Security, privacy and knowledge-base (RAG) governance
The RFP must detail security requirements applicable to the document repository and API exchanges. Request commitments on encryption in transit and at rest, access management, multitenant data segmentation and the possibility of external audits. Also specify responsibilities related to detection, removal or anonymization of sensitive information provided as input.
Include a section on governance of the content feeding the RAG: document ingestion flows, human validation processes, update frequency and mechanisms to withdraw obsolete or incorrect information. Avoid prescribing a specific technical method; require instead evidence of processes and tools that ensure quality and traceability of changes.
Operations, SLA and key contractual clauses
Specify operational expectations without imposing arbitrary values: ask vendors to state their commitments on availability, mean time to resolve critical incidents, maintenance windows and support during updates. Also request a continuity and recovery plan after incidents.
Here are clauses to include or negotiate in the contract: definition of expected service levels, escalation and on-call procedures, support modalities and access to patches, responsibilities regarding data security, intellectual property of business content and exit conditions on termination. Provide validation modalities for POC deliverables and a clear operational acceptance process.
POC protocol and operational evaluation criteria
The POC should be designed as an assessment based on representative, repeatable scenarios. Require a duration and scope appropriate to footfall and target languages, and demand the setup of an isolated test environment reproducing the network and hardware configuration of at least one pilot site.
During the POC, evaluate the solution against concrete axes: functional fit for business cases, robustness of API integrations, multilingual behavior, voice ergonomics in real conditions, and the ability to use the provided knowledge base. Define acceptance criteria based on pass/fail tests and documented anomaly reports.
Predefined functional test suites replicated on the pilot site
Integration scenarios with simulated or real business systems
Multilingual tests on priority languages and user observation
Robustness tests in case of external service unavailability
Scoring grid and decision method (practical guidance)
Propose a grid of criteria grouped by families: functional relevance, technical quality and integrations, security and governance, operations and support, total cost of ownership and vendor maturity. For decision governance, assign greater weight to operational and security criteria if the project involves sensitive data or high-traffic sites.
To ensure a rational decision, request verifiable evidence from vendors: live demonstrations, restricted access to the back office for validation, and detailed POC results. Use a multidisciplinary committee bringing together IT, operations and business to review results and arbitrate trade-offs between functional requirements and operational constraints.
Internal preparation checklist and concrete acceptance criteria
Before sending the RFP, prepare a structured set of business contents to provide to bidders for the POC: product documents, FAQs and read-only access to necessary systems (APIs, product sheets). Clearly identify pilot sites and prepare logistics (network, hardware permissions, technical access plan).
Define clear and traceable acceptance criteria for final acceptance: validation of defined use cases, demonstration of operational integrations, proof of multilingual capability on target languages and compliance with security requirements. Also formalize the anomaly correction process and the delivery of expected outputs at the end of the POC.
Prepare business content and datasets for the POC
Ensure required network and API access for the bidder
Select at least one pilot site and define local contacts
Organize user observation and acceptance test sessions
Conclusion
A clear, structured RFP enables objective comparison of offers and reduces risks related to deploying an AI avatar on a kiosk or screen. By requiring a rigorous POC, technical evidence and contractual commitments on operations and security, you lower operational uncertainty at production rollout.
SANIA is a professional conversational AI avatar solution designed for welcome, information and wayfinding on screens or kiosks, with 24/7 availability and recognised multilingual capabilities. To test a solution's fit with your pilot sites, you can request a demonstration and build an RFP based on this template.