An effective AI chatbot call for tenders rests on specifications organised into six blocks, detailed use cases and quantified metrics shared from the outset. Without this structure, you risk spending weeks deciphering bids, running requests for information (RFIs) and exchanging endlessly with suppliers. Here is a roadmap for preparing your call for tenders, also known as an RFP (request for proposal).

To go further, download our complete 10-page guide, which takes you through your RFP step by step.

Key takeaways

• A quantified objective, for example "reduce average time to resolution (TTR) by 20%", gives better direction to suppliers' answers.

• Without detailed scenarios for each use case, demos remain generic.

• Involving the IT department before the call for tenders goes out avoids unpleasant technical surprises.

Which objectives and metrics should you set in an AI chatbot call for tenders?

An AI chatbot is not just a technology trend: it is a strategic decision with measurable effects. Your call for tenders should therefore set objectives in four areas: costs, peaks in demand, customer satisfaction and the customer journey. Translate each one into a quantified metric (KPI).

• Reduce operating costs: a chatbot can handle up to 40% of simple requests.

• Smooth out peaks in demand: the chatbot handles low-value requests 24/7, with no need to hire temporary agents in high season.

• Improve customer satisfaction (CSAT, the score your customers give you): less waiting means more satisfaction. By automating factual requests (order status, opening hours, procedures), you reduce the average waiting time.

• Streamline the customer journey: beyond support, the chatbot can qualify a prospect, offer an interactive FAQ or direct users to book an appointment.

What is a generative AI chatbot?

An AI chatbot is a conversational agent built on a large language model (LLM), such as ChatGPT (United States) or Mistral AI (France). It can follow predefined customer journeys, connect to your systems to take action and answer from a knowledge base: online FAQs, PDFs, CSV files.

The five types of flow

1. Answers from a knowledge base: the agent draws on your documents to give personalised answers suited to the context.

2. Transactional (API): the agent takes action in your CRM, your ERP or your internal tools via API, meaning a direct connection between software systems (order status, invoice, authentication).

3. Scripted journeys: the chatbot follows decision trees with predefined answers. This is the technology of first-generation chatbots, which guarantees full control over every message. You can add AI to make these journeys more flexible.

4. Escalation to a human: the chatbot hands over to an agent via live chat (LiveChat), a ticket or a callback (web callback).

5. Rich media: image carousels, PDFs, videos.

Deployment channels

Web widget, mobile app (SDK or webview), WhatsApp Business, Facebook Messenger, SMS: each channel has its own technical constraints. Specify them in your RFP (section 2.3 of the guide). Section 2 of the guide covers each use case in detail, with examples and diagrams.

AI chatbot specifications are organised into six blocks

To get clear, comparable answers, structure your technical specifications (the CCTP, in French public procurement) into six blocks. Each one has a role: aligning your teams, guiding suppliers or securing your decision. For each block, here is its purpose, its content and a tip.

1. Project overview and objectives

Why: context avoids generic bids. Your volumes also let suppliers adjust their commercial offer and calculate a reliable return on investment (ROI).

Content: your support organisation, your current volumes (web traffic, emails, calls, existing chatbot) and clear objectives (cost reduction, satisfaction, scaling up).

Tip: a quantified objective gives better direction to the answers, for example "reduce TTR by 20%".

2. Functional requirements

Why: defining precisely what your chatbot must do prevents scope creep.

Content: the use cases, with detailed scenarios (FAQ, authentication, invoices, ticket search, escalation), their key steps and the systems involved, and the types of flow expected.

Tip: illustrate each use case with a concrete example journey.

3. Technical requirements: hosting, GDPR, APIs

Why: to check feasibility and compliance at the call for tenders stage.

Content:

• Hosting: a GDPR-compliant online solution (SaaS) or installation on your own servers (on-premise), and server location.

• Security and GDPR: encryption (TLS/AES), consent, retention period, data processing agreement (DPA).

• Integration with your information system: APIs (REST, GraphQL, SOAP), authentication (OAuth2, JWT), access to specifications (Swagger/Postman).

• Independence from AI models: an architecture that can switch model or provider without a major overhaul.

Tip: involve the IT department from the drafting stage to validate connections to internal systems.

4. Selection criteria and scoring grid

Why: to make the comparison objective and limit arbitrary choices.

Content:

• Functional: use case coverage, answer quality, handling of context over several exchanges.

• Technical and user experience: native connectors, no-code editor, dashboards.

• Support and guidance: service level agreements (SLAs) on response time, training, customer follow-up (Customer Success).

• Costs: set-up (configuration, testing), licence, total cost of ownership (TCO) over 3 years.

Tip: weight each criterion in an Excel grid, for transparent scoring.

5. Methodology and schedule

Why: to standardise the format of the answers and make evaluation easier.

Content: response outline (contents, introduction, functional, technical, schedule, budget), submission format, key dates (RFI, demos, closing date), selection panel.

Tip: ask for a demo schedule.

6. Appendices and templates

Why: to provide ready-to-use resources and standardise the documentation.

Content: glossary, conversation diagrams (Visio, Draw.io), Excel scoring grid, DPA template, technical checklist.

Tip: attach a sample diagram to make the expected format clear.

Four pitfalls can skew your tender

Four pitfalls weaken a chatbot tender: vague use cases, metrics that are not shared, sovereignty overlooked and an IT department involved too late. Each one has a cost: generic demos, unrealistic prices, dependence on a single supplier or unpleasant technical surprises.

Not defining use cases precisely

Without detailed scenarios, the scope remains vague: demos stay generic and you risk making the wrong choice or facing surprises on set-up costs.

Solution: detail each journey so that you can clearly state what you expect to see in the demo. Map them with tools such as Draw.io or Whimsical, or use the simple, universal template provided in the appendix to our guide.

Not sharing your metrics from the outset

Share your ticket and web traffic volumes, your average time to resolution (TTR), your escalation and containment rates, and your CSAT. Without these figures, suppliers can offer neither a realistic price nor a reliable ROI calculation.

Overlooking sovereignty and GDPR compliance

Require hosting in France or the European Union, and an architecture that can use several AI model providers. You could, for example, move from a cloud-based language model API to a model hosted on your own infrastructure (self-hosted), without starting over.

This way, you avoid dependence on a single supplier, keep your costs under control and stay compliant as regulations evolve. The other points are covered in section 3.2 of our guide.

Involving the IT department too late

API integrations that have not been validated lead to unpleasant technical surprises. Involving the IT department before the call for tenders goes out ensures that connectors are available and that the network is compliant.