Two vendors can answer “yes” to CRM integration while proposing different work: a standard connector, a custom build, or another supplier’s service. The difference affects price, delivery, and who fixes failures after launch. A useful request for proposal (RFP) makes those differences visible before selection, before they become implementation costs, security exceptions, or production failures.
This conversational AI RFP checklist connects each requirement to a supplier response, evidence, and an acceptance test. It covers customer-facing chat and voice, with additional controls for agents that change business records. Use the requirement IDs throughout evaluation and contracting so a promising answer can be traced to demonstrated behavior and an agreed commitment.
Conversational AI RFP checklist at a glance
A conversational AI RFP should cover business fit, conversation quality, knowledge and models, integrations and actions, security and data, operations, delivery, and commercial terms. Each category should specify what the buyer needs to decide and what evidence the supplier must provide.
| Category | Decision to make | Evidence to request |
|---|---|---|
| Business fit | Does the scope deliver the intended outcomes? | Journey map and metric definitions |
| Conversation quality | Can users complete the interaction? | Representative transcripts and recordings |
| Knowledge and models | Are answers supported and changes controlled? | Source traces and regression results |
| Integrations and actions | Are reads and transactions correctly restricted? | Permission matrix and transaction logs |
| Security and data | Does the deployment meet applicable requirements? | Data-flow map and scoped assurance evidence |
| Operations | Can the service be monitored and recovered? | Load results and incident runbook |
| Delivery | Who builds, approves, and maintains each component? | Delivery plan and responsibility matrix |
| Commercials and exit | What will operation and transition cost? | Itemized quote and export inventory |
Use the framework in six stages: define the deployment, standardize supplier responses, apply mandatory gates and score the evidence, run a shared pilot, compare total cost of ownership, and carry the selected commitments into the contract.
The questions, weights, and tests below are an editable editorial framework. NIST’s Generative AI Profile, a companion to its voluntary AI Risk Management Framework, supports evaluating systems under deployment-relevant conditions and checking whether cited sources support outputs; it does not prescribe this scorecard.
Core applies across the selected deployment; Voice applies to audio; Chat applies to text interfaces; Actions applies to system writes or consequential transactions. A mandatory gate is a buyer-approved qualification condition, such as enforcing the required transaction permissions. Scored preferences distinguish qualified suppliers; a high score cannot compensate for a failed gate.
Define your deployment before asking vendors to quote
Give every supplier the same scope sheet. Otherwise, differences in staffing, traffic assumptions, and permitted workflows can make bids incomparable.
- Use cases: [journeys], [exclusions], [business owner], and [observable completion event].
- Channels: [voice/chat entry points], [languages/locales], [accessibility needs], and [operating hours].
- Workload: [monthly contacts and eligible tasks], [turns], , and [peak concurrent interactions]. Mark forecasts separately from measured traffic.
- Architecture: [deployment model], [native, third-party, and custom components], [hosting boundaries], [data flows], and [component owners].
- Systems: [telephony and contact center as a service (CCaaS)], [customer relationship management (CRM)/helpdesk], [identity], [backend versions], and [sandbox access].
- Knowledge and data: [sources], [owners], [update frequency], [access restrictions], and [sensitive information].
- Authority: [permitted reads/writes], [transaction limits], and [required approvals].
- Delivery: [internal staffing], [managed-service expectations], [rollout stages], and [ongoing ownership].
- Measurement and commercials: [eligible population], [evaluation and repeat-contact windows], [currency], and [contract term].
For example, define appointment-change completion as the confirmed new booking appearing in the scheduling system for an eligible customer during the evaluation window. Specify whether cancellations, repeat attempts, and human-assisted completions belong in that measure.
| Deployment type | Procurement emphasis |
|---|---|
| Answer-only assistance supplies information | Supported answers, appropriate refusal, and routing |
| Human agent assistance suggests responses to staff | Staff workflow and review responsibility; standalone agent-assist procurement is outside this checklist’s main scope |
| Transactional agents initiate business-system changes | Authorization, confirmation, verified results, and recovery |
Also distinguish buying platform access from commissioning a managed implementation. Assign knowledge preparation, integration work, and maintenance explicitly in either case.
A real example is Haryana Kaushal Rozgar Nigam Limited’s issued communication-system RFP, which includes WhatsApp chatbot integration, training, security audit, and user acceptance testing (UAT). Its implementation and payment tables include UAT-related stages. This illustrates procurement scope and acceptance mechanics, not a reported deployment outcome or a universal delivery schedule.
Questions to include in a conversational AI RFP
Require one response record per ID. Use a primary status of available as standard, configurable, custom development, third-party dependency, roadmap, or unavailable, with dependency notes where several apply.
Each record should also contain the explanation, limitations, incremental cost, accountable party, delivery date where relevant, evidence reference, and feature maturity: generally available, preview, or beta. Keep documentation review, pilot status, and proposed contract location in separate fields. A roadmap promise remains a future commitment; configuration and custom development require their own delivery evidence.
1. Business outcomes and reporting
Ask how results are calculated before comparing percentages. Microsoft’s Copilot Studio documentation explains that a conversation can contain multiple analytics sessions and that resolved outcomes can include confirmed or implied success. That product-specific definition shows why buyers need to reconcile a reporting label with their own completion event.
| Question | Proof to request | Evaluation note |
|---|---|---|
| B01 · Core — Which use cases, boundaries, and exceptions does the proposal cover? | Journey map showing supported steps | Which steps require people or another service? |
| B02 · Core — How are resolution, transfers, abandonment, and repeat contacts counted? | Formulas, denominators, exclusions, and windows | Does “resolved” include inferred success or a timeout? |
| B03 · Core — Can we reproduce reported outcomes independently? | Export linking reports to event-level records | Reconcile a sample figure against the underlying events. |
No human transfer does not, by itself, establish resolution. If using containment, define it as a routing measure and separately assess whether the customer’s issue was resolved, including repeat contacts within the agreed window.
2. Voice, chat, and human handoff
Test complete journeys in the intended channels. For a web chat interface, WCAG 2.2 includes keyboard operation, freedom from keyboard traps, visible focus, and programmatically determinable status messages. Request evidence for the deployed interface and chosen criteria; the standard’s existence does not establish a particular deployment’s legal obligations.
| Question | Proof to request | Evaluation note |
|---|---|---|
| C01 · Core — How are context and corrected information retained across turns? | Transcripts and resulting system values | Does the final correction reach the backend? |
| C02 · Core — How well does each required language and locale work? | Results by locale and relevant user variation | Distinguish tested performance from nominal support. |
| C03 · Voice — How are noise, pauses, accents, interruptions, and letters or numbers handled? | Recordings and timing from the intended call path | Does playback stop and the new input survive? |
| C04 · Chat — Does the complete chat journey meet our accessibility and channel requirements? | Assessment scope, findings, and journey tests | Which surfaces, criteria, version, and level were assessed? |
| C05 · Core — How does escalation work, including when staff are unavailable? | Context transfer, acknowledgement, and fallback demonstration | What happens when the receiving queue rejects transfer? |
For this evaluation, define voice latency as the time from actual end of user speech to first audible response at the user endpoint. Record speech-end detection delay separately where available. For chat, measure submission to first visible response and to completed response. These are proposed measurement boundaries, not universal targets; report conditions and percentile results consistently.
3. Knowledge quality and model changes
Evaluate source support, freshness, and access restrictions separately. As of September 10, 2026, Azure AI Search documentation distinguishes access-control approaches, includes preview features, and notes permission-change synchronization lag. Ask suppliers to identify the maturity and revocation timing of the actual configuration they propose.
| Question | Proof to request | Evaluation note |
|---|---|---|
| K01 · Core — How are answers supported by authorized sources? | Answer-to-source traces using identities with different access | A related citation must actually support the answer. |
| K02 · Core — When do updates, deletions, and revoked permissions take effect? | Timed tests across indexes, caches, and ongoing conversations | What is the maximum exposure window and who monitors it? |
| K03 · Core — What happens with missing, stale, conflicting, or malicious material? | Exception tests and refusal/escalation policy | Show when the assistant clarifies or declines to answer. |
| K04 · Core — How are model, provider, and prompt changes controlled? | Inventory, notices, version policy, and regression results | Can we compare versions, defer changes, or roll back? |
Retrieval-augmented generation (RAG) is one approach to supplying source material, not an acceptance result. OWASP’s 2025 prompt-injection guidance explicitly notes that RAG and fine-tuning do not fully mitigate prompt injection. Test retrieved malicious instructions as well as ordinary missing information.
4. Integrations and actions in business systems
Start with the complete proposed architecture, including which components are native, third-party, or custom and where hosting and support responsibilities sit.
Require authorization enforced by system logic independently of generated text. This aligns with the excessive-agency guidance in OWASP’s 2026 LLM report, which addresses scoped permissions and approval for high-impact actions.
| Question | Proof to request | Evaluation note |
|---|---|---|
| A00 · Core — What deployment and integration architecture is proposed? | Architecture and data-flow diagram identifying native, third-party, and custom components, hosting boundaries, telephony/CCaaS, orchestration, models, retrieval, identity, and business APIs | Which party owns and supports each component and interface? |
| A01 · Core; Actions for writes — Which required read/write operations are supported? | Connector/API versions, owner, and sandbox demonstration | Identify custom work and additional licenses per operation. |
| A02 · Actions — How are identity and permitted actions enforced? | Permission matrix, action classes, transaction and rate limits, and allowed-versus-blocked tests | Where is independent authorization enforced, when is human review required, and how can actions be suspended? |
| A03 · Actions — How is approval tied to the exact transaction? | Approval record linked to transaction parameters | Can a changed amount or destination reuse approval? |
| A04 · Actions — How are timeouts, repeats, and partial completion recovered? | Transaction traces and reconciliation tests | Distinguish an unknown outcome from a confirmed failure. |
For higher-impact actions, make the operating limits explicit: permitted action classes, transaction ceilings, rate limits, conditions requiring human review, and an emergency disable control.
Consider an illustrative appointment-change test. An authenticated customer may change only their own booking. The agent proposes a slot, obtains the required confirmation, and submits the change. If the backend commits but its response times out, the agent must reconcile the booking state before retrying. An unavailable slot should trigger alternatives; switching to someone else’s booking should trigger denial.
Record identity, approval, old and new state, and transaction ID. Stripe’s engineering explanation of idempotency illustrates how a repeated request with the same key can avoid a duplicate charge after a network error. Whether the selected API supports that pattern, and how a multi-step workflow repairs partial completion, still requires integration-specific evidence. Define compensation or manual repair where rollback is unavailable.
5. Security, privacy, and regulatory evidence
Separate legal duties, buyer policy, and voluntary assurance. AICPA describes SOC 2 as reporting on an examination of service-organization controls; ISO/IEC 27001:2022 concerns information-security management systems. Ask what the evidence covers, rather than treating a badge as proof of answer quality or deployment-wide compliance.
| Question | Proof to request | Evaluation note |
|---|---|---|
| S01 · Core — Where does data travel, and who can access it? | Data-flow map, subprocessors, locations, support access, and transfer routes | Include audio, transcripts, model calls, logs, and backups. |
| S02 · Core — What are the retention, deletion, and training-use terms? | Schedules and contractual terms across the supplier chain | Address storage and human review separately from training. |
| S03 · Core — Which access and security controls cover this deployment? | Scoped assurance, security tests, and remediation status | Check environment, period, exceptions, and malicious-instruction tests. |
| S04 · Core — Which jurisdictional, sector, and disclosure requirements apply? | Applicability matrix with responsible party and test | Identify the basis: law, buyer policy, or voluntary assurance. |
Have the relevant reviewers address recording, sensitive data, international transfers, AI interaction notices, and sector requirements for the actual use case. Assign each applicable obligation to a delivery artifact, operating owner, and contract term. A generic international checklist cannot determine those obligations without the deployment’s location, roles, and data flows.
6. Reliability and production operations
An available infrastructure endpoint and a completed customer task measure different things. Google’s service-use guidance distinguishes latency guidance from service-level agreement (SLA) commitments. Define the boundary behind each proposed commitment, including dependencies and exclusions.
| Question | Proof to request | Evaluation note |
|---|---|---|
| O01 · Core — How does the service behave under peak load and dependency failure? | Load, regional failover, recovery time objective (RTO), recovery point objective (RPO), and recovery tests | What happens when the model, carrier, region, or backend fails, and who owns recovery? |
| O02 · Core — How are availability, quality, and latency measured? | Definitions, distributions, sample counts, and exclusions | Does the SLA cover the measured customer experience? |
| O03 · Core — Can we trace failures and coordinate incidents? | Privacy-controlled logs, alerts, export, support coverage, escalation paths, and incident runbook | Can a failed journey be traced across model, source, and tool events, then escalated to an accountable responder? |
| O04 · Core — How are releases approved, reversed, or disabled? | Comparison tests and rollback/disable demonstration | Can actions stop while safe information service continues? |
Require latency units, timing boundaries, workload, and p50/p95/p99 results together. Where applicable, define RTO, RPO, regional failover, reduced-function behavior, and business-continuity responsibilities. A degraded mode should not silently count as successful completion of the original task.
7. Implementation and ongoing ownership
Put one accountable owner against each deliverable and maintenance activity. A runtime support subscription may leave knowledge review, connector changes, and evaluation work to another team, so make the allocation explicit. Also establish whether the supplier can support the deployment across the proposed contract term, operating region, and escalation model.
| Question | Proof to request | Evaluation note |
|---|---|---|
| D01 · Core — What must be delivered and accepted at each stage? | Plan with dependencies, buyer inputs, and approvers | Which dates assume completed content, identity, or API work? |
| D02 · Core — Who owns each component before and after launch? | Buyer/vendor/integrator responsibility matrix | Name the ongoing connector and knowledge owners. |
| D03 · Core — What maintenance, training, and change work is included? | Priced activities, staffing assumptions, and change process | Identify work outside the support subscription. |
| D04 · Core — What evidence shows the supplier can support this deployment throughout the proposed term? | Relevant-scale customer references, regional support coverage, escalation model, continuity plan, and roadmap/change communications | Are the references comparable in scope, channels, volume, and operating region? |
8. Pricing, contract terms, and exit
Ask suppliers to translate the shared workload into their billable units. Keep requests, messages, minutes, tokens, and completed tasks distinct throughout the comparison.
| Question | Proof to request | Evaluation note |
|---|---|---|
| P01 · Core — What is the full price for our workload? | Itemized quote with units, tiers, inclusions, minimums, and overages | Include testing, retries, dependencies, and services. |
| P02 · Core — Which material answers become contractual commitments? | Map to scope, acceptance, service, data, and change terms | Identify remedies and unresolved qualifications. |
| P03 · Core — What can we export and what does transition require? | Asset inventory, formats, sample export, support fees, and restrictions | Test independent use; do not assume vendor IP transfers. |
Score vendor responses after applying mandatory gates
First resolve the gates approved for this deployment. Record failures and outstanding evidence separately, with an owner and any authorized remediation decision. A supplier with an unresolved gate remains unqualified under this method, regardless of its aggregate score.
Then score qualified suppliers using agreed anchors: 0 unavailable or unanswered; 1 assertion without sufficient evidence; 2 partial coverage or documented gaps; 3 meets the requirement with reviewed evidence; 4 meets a predefined, valuable higher target with reviewed evidence. Keep pilot verification separate from these document-review scores.
The following weights and supplier scores are illustrative, not industry standards.
| Category | Weight | Example score out of 4 | Contribution |
|---|---|---|---|
| Business fit | 10% | 3 | 7.50 |
| Conversation quality | 20% | 3 | 15.00 |
| Knowledge and models | 15% | 4 | 15.00 |
| Integrations and actions | 15% | 2 | 7.50 |
| Security and data | 15% | 3 | 11.25 |
| Operations | 10% | 3 | 7.50 |
| Delivery | 5% | 4 | 5.00 |
| Commercials and exit | 10% | 2 | 5.00 |
| Total | 100% | 73.75 out of 100 |
Category contribution equals its weight in percentage points multiplied by its score and divided by four. Conversation quality therefore contributes 20 × 3 ÷ 4 = 15 points. Use the average of applicable question scores for each category unless different question weights were agreed in advance.
Agree applicability and redistribute weights before issuing the RFP. Removing voice questions does not remove chat or handoff evaluation; excluding writes does not remove integration reads. Do not award automatic points for “not applicable” or let suppliers exclude difficult requirements themselves. Retain reviewer notes and evidence IDs, and avoid scoring the same benefit repeatedly across categories. Apply the decision method permitted by your procurement rules.
Validate the shortlist with a shared pilot test plan
The pilot checks whether shortlisted suppliers deliver the behavior their responses describe. Give them the same authorized material and workload, retain a buyer-held evaluation portion, and log preparation differences. Freeze the rubric and record model, configuration, and dataset versions. Choose sample coverage for operating diversity and risk, repeat variable cases, and document where the sandbox differs from production.
The matrix below is an illustrative test design. Set each threshold before testing; bracketed values are buyer inputs. For every row, record conditions/version, threshold, owner, evidence, pass/fail/not run, remediation owner and due date, and retest outcome.
| Test and requirement IDs | Expected behavior and retained evidence | Metric and acceptance entry |
|---|---|---|
| T01 · B02, K01 — Normal answer and permitted task | Use the authorized policy; verify transactions in backend state. Keep source trace and state record. | Supported answers / assessed answer cases; completed tasks / eligible attempts. Targets [ ]; CX/system owner. |
| T02 · K02, K03 — Missing or conflicting source | Clarify, qualify, or decline under policy; apply deletion. Keep timed source and response records. | Correct exceptions / exception cases; propagation time. Targets [ ]; knowledge owner. |
| T03 · C01, C02 — Corrected intent | Use the final confirmed value across tested locales. Keep transcript and resulting values. | Correct interpretations / correction cases, by locale. Target [ ]; CX/language owner. |
| T04 · C03, O02 — Noisy interrupted call | Stop appropriately and retain the new request on the specified call path. Keep recording and timing. | Correct interruptions / trials; speech-to-audio percentiles. Targets [ ]; telephony owner. |
| T05 · K01, A02, A03, S03 — Prohibited access or action | Block cross-user access, approval bypass, and malicious retrieved instructions. Keep permission and event traces. | Unauthorized disclosures/actions / prohibited attempts, with counts. Gate [ ]; security owner. |
| T06 · A04, O01 — Timeout or repeated request | Reconcile ambiguous state and prevent unintended duplication. Keep transaction and recovery records. | Duplicates / retry trials; correct reconciliation / ambiguous cases. Targets [ ]; integration owner. |
| T07 · C04, C05 — Human help or unavailable staff | Transfer context with acknowledgement or give agreed fallback; test accessible chat completion. Keep journey evidence. | Correct handoff/fallback / escalation attempts; accessible completions / tested journeys. Targets [ ]; contact-center/accessibility owners. |
| T08 · O01–O04 — Peak load and outage | Recover under specified concurrency and dependency failures. Retain traces and load profile. | Completed tasks / eligible attempts; availability, latency, recovery time. Separate targets [ ]; operations owner. |
For an illustrative read-only case, ask whether a delivered item is still eligible for return. Supply an approved policy and authenticated order details. A correct general citation with an incorrect order-specific conclusion fails. Report supported answers separately from abstentions so selective answering cannot hide limited coverage.
For the appointment-change case, verify the booking itself. The agent saying “done” is insufficient. Likewise, a transfer request is not proof that a human received it; test unavailable staff and the user-visible fallback explicitly.
A buyer may designate any observed unauthorized action as release-blocking and require zero unintended duplicates in the retry suite. Those are policy choices for the tested scope. Zero observed failures does not establish zero future risk; retain the failed cases and rerun them after remediation and relevant changes.
Compare total cost and carry commitments into the contract
Calculate total cost of ownership (TCO) over the same term and currency for low, base, and high workloads. Apply each supplier’s actual unit rules to those workloads, then reconcile the resulting consumption against pilot measurements.
Term TCO = implementation + recurring platform and usage + separately billed dependencies + internal operations + included human handling + transition + consistently treated taxes. Sum recurring costs over the selected term, applying inclusions, minimums, tiers, and rounding before comparing totals.
| Cost input | Common low/base/high assumptions | Supporting record |
|---|---|---|
| Term and currency | Same [months], [currency], tax and exchange-rate treatment | Quote validity and term |
| Workload | Scenario-specific contacts, tasks, turns, audio duration, and concurrency | Forecast and pilot consumption |
| Implementation | Same interfaces, migration, knowledge preparation, evaluation, and training scope | Fixed quote or labeled estimate |
| Platform and usage | Supplier-specific units applied to shared traffic | Rates, tiers, minimums, rounding, overages |
| Dependencies | Separately billed telephony, speech, models, retrieval, storage, and logging | Inclusion/responsibility reconciliation |
| Internal operations | Review, engineering, incident work, and retained human handling | Estimated hours and loaded labor rates |
| Transition | Export, assistance, parallel operation, and decommissioning | Inventory and priced obligations |
Keep quoted amounts separate from estimates. Avoid adding charges already bundled into another line; record credits, renewal increases, and price-adjustment assumptions. If using cost per verified successful task, use the same period, workload, and completion definition. Include human costs and human-completed tasks consistently. Label forecast-based ratios as modeled; with zero successful tasks, the ratio is undefined.
Carry the selected requirements into the statement of work, acceptance plan, data terms, service commitments, change controls, and exit obligations. Have the relevant reviewers resolve contract precedence and exceptions for the actual procurement.
Finish with a selection record containing the deployment and version, gate outcomes, evidence IDs, score, pilot results, TCO assumptions, unresolved conditions and owners, business/security/legal reviewers, contract locations, implementation owner, and next review date. That record should explain what was accepted, what remains conditional, and who is accountable when the service moves into production.
Conversational AI RFP checklist FAQs
What should a conversational AI RFP include?
It should define the deployment and require comparable vendor responses across business outcomes, conversation quality, knowledge and models, integrations and actions, security and data, operations, delivery, and commercial terms. Each requirement should have an ID, an accountable response, requested evidence, and an acceptance method.
How should conversational AI vendors be scored?
Apply buyer-approved mandatory gates first. Score only qualified suppliers against predefined 0-4 evidence anchors, use agreed category weights, retain reviewer notes and evidence IDs, and keep pilot results separate from document-review scores.
How should an RFP evaluate an agentic AI system differently from a chatbot?
An answer-only assistant is evaluated mainly on supported responses, appropriate refusal, routing, and conversation quality. A transactional or agentic system also needs independently enforced authorization, exact approvals, action and transaction limits, verified backend results, recovery from ambiguous outcomes, and an emergency way to suspend actions.
What should be tested in a conversational AI vendor pilot?
Give shortlisted suppliers the same authorized material, workload, and acceptance thresholds. Test ordinary journeys as well as missing or conflicting knowledge, corrected intent, noisy voice interactions, prohibited access or actions, retries, unavailable staff, peak load, and dependency failures, then verify the retained source, event, and backend records.
Who should evaluate conversational AI RFP responses?
Use a cross-functional evaluation team. Business and customer-experience owners define outcomes; IT and integration teams review architecture and system behavior; security, privacy, and legal reviewers assess applicable controls and obligations; operations and contact-center owners test production readiness; procurement and finance compare commitments and total cost.
References
Sources below support the factual examples and guidance cited in the article. Product documentation was reviewed on September 10, 2026; supplier terms and proposed capabilities require confirmation for the purchase.
1. NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1. July 2024. https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
2. Haryana Kaushal Rozgar Nigam Limited. RFP for Selection of Agency for Design and Development of Integrated Communication Management System. Publication date not established; scope and UAT tables, PDF pages 23, 31, and 46. https://hkrnl.itiharyana.gov.in/pdf/RFP%20for%20WhatsApp%20chatbot%20integration.pdf
3. Microsoft. Measure agent outcomes. Updated June 4, 2026. https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/measuring-outcomes
4. W3C. Web Content Accessibility Guidelines (WCAG) 2.2. Live recommendation reviewed September 10, 2026. https://www.w3.org/TR/WCAG22/
5. Microsoft. Document-level access control in Azure AI Search. Updated August 12, 2026. https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview
6. OWASP. LLM01:2025 Prompt Injection. 2025 edition, retained for its specific discussion of mitigation limits. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
7. OWASP. Top 10 for LLM Applications 2026. Excessive Agency, LLM03:2026, PDF pages 23–26. The linked PDF retains unfinished publication-date metadata. https://genai.owasp.org/download/56857/?tmstv=1785822482
8. Stripe, Brandur Leach. Designing robust and predictable APIs with idempotency. February 22, 2017. Technical pattern example, not a current API contract. https://stripe.com/blog/idempotency
9. AICPA & CIMA. System and Organization Controls: SOC Suite of Services. https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services
10. ISO. ISO/IEC 27001:2022 — Information security management systems. Public overview. https://www.iso.org/standard/27001
11. Google Cloud. Service use best practices. https://docs.cloud.google.com/dialogflow/cx/docs/concept/best-practices
