Contract for an operating service, not just a launch. The items below are recommended commercial requirements; negotiate them with appropriate professional advice.
| Contract area | Buyer requirement |
|---|---|
| Scope | Exact channels, actions, integrations and prohibited decisions |
| Acceptance | Written scenarios, severity definitions and remedies for failed tests |
| Accounts and numbers | Identify the account holder, access rights and number-transfer arrangements |
| Data and configuration | Exportable records, prompts, rules, templates and workflow configurations where applicable |
| Intellectual property | Rights sufficient to continue or replace the service; distinguish supplier background IP from project-specific work |
| Support | Coverage hours, incident severity, response commitments and escalation contacts |
| Maintenance | Responsibility for application, API, model and telephony changes |
| Change control | Approval and rollback for changes affecting customer-facing behaviour |
| Charges | Unit definitions, allowances, overages, caps, indexation and change-request prices |
| Privacy | Appropriate processing terms, subprocessors, retention, security and international-transfer arrangements |
| Exit | Export formats, transition help, fees, access revocation and deletion process |
| Measurement | Access to event-level outcomes and the agreed baseline methodology |
Privacy-related terms are not optional merely because the supplier calls the product an AI assistant: the ICO’s controller/processor guidance explicitly addresses instructions, subprocessors, assistance, audit and end-of-contract provisions. Commercial ownership of accounts, code and telephone numbers should be negotiated separately rather than inferred from those data-protection rules. (ico.org.uk)
Recommended exit test before signing: ask the supplier to show what you would receive if the relationship ended, and who could operate or rebuild the workflow from it.
Sources cited on this page
- ico.org.uk ↗ico.org.uk
PUT THE RESEARCH TO WORK