Scotland and Wales: retention software contract checks

Retention software contracts for Scotland and Wales need a clear service brief, not assumptions about national contract lengths or support hours. This checklist covers the customer journeys, language requirements, acceptance tests, support arrangements and exit evidence to put into the agreement.

The practical question is whether the contract supports the service you actually operate. A team serving customers across both nations may need shared reporting, separate message templates and different local workflows. Those requirements should be visible in the service schedule and demonstrated before acceptance.

For public-sector customers, applicable procurement and language duties also need attention. They do not establish a universal Scottish or Welsh subscription term, notice period or service level.

Identify the customer before applying a national label

Start by recording who is buying, who will use the software and who will receive its messages. A private business operating in Wales is not interchangeable with a Welsh public body. Nor does a Scottish office make a commercial purchase a public-sector framework call-off.

Public procurement has a separate legal context. Devolved Scottish public procurement operates under its own regime, including the Procurement Reform (Scotland) Act 2014 and the Public Contracts (Scotland) Regulations 2015. The Procurement Act 2023 governs much public procurement in Wales, subject to its scope and transitional arrangements; it does not generally replace the devolved Scottish regime.

Where a public framework is involved, record its actual name, reference and permitted scope in the contract file. Check buyer eligibility, supplier eligibility and the agreement's ordering procedure. Public Contracts Scotland is a procurement notices portal, not proof that a particular supplier or product is available through a framework.

In Wales, identify the actual buying organisation rather than using National Procurement Service as a generic label. A published notice identifies Welsh Government Commercial Delivery (WGCD) as the procuring entity for a vehicle parts framework. That notice does not establish a route for buying retention software.

Keep this administrative information separate from the service specification. An available purchasing route does not prove that the software can handle your customer communications, integrations or language requirements.

For the relationship between the order, schedules and wider terms, see the commercial contract guide. Here, the task is to make the Scotland-and-Wales service requirements explicit within those documents.

Write a service boundary that the supplier can deliver

Describe the work the platform will perform before debating contract duration. Retention software might monitor product use, flag accounts for review, generate renewal tasks or trigger customer messages. Your agreement should identify which of those activities are included, rather than treating “customer success” as a complete specification.

A useful service schedule records:

Separate customer-facing functionality from internal administration. A Welsh-language email template does not demonstrate that a customer can complete the linked journey in Welsh. Equally, a requirement for Welsh customer communications does not automatically mean every internal configuration screen must be bilingual: specify what the service requires.

For a shared operation, identify whether staff in Scotland and Wales will use the same account record. Record which team owns follow-up work and how a hand-off preserves the customer's communication preferences. Avoid a design in which moving an account between teams silently changes its language or contact settings.

Attach the agreed scope to the contract. A demonstration slide or sales email is a weak substitute for a service schedule that states what is included, how it will be tested and who is responsible for maintaining it.

Translate Welsh language duties into working requirements

The Welsh Language (Wales) Measure 2011 provides the legal framework for Welsh language duties. South Wales Fire and Rescue Service explains the requirement that Welsh should not be treated less favourably than English in its language standards guidance.

For a public-body customer, identify the applicable Welsh Language Standards and the body's compliance notice, overseen by the Welsh Language Commissioner. Do not assume that every organisation has identical obligations. Ask the customer's language lead to identify which duties affect the service being purchased.

Turn those duties into requirements the supplier can demonstrate. Depending on the service, these may include recording a person's language preference, selecting an approved message template, preserving Welsh text through an integration and routing a response to an appropriate member of staff. Specify the relevant journeys rather than asking only whether the product “supports Welsh”.

Keep the responsibilities clear. The buyer may supply approved wording while the supplier provides the template system and delivery controls. If translation or language review is part of the supplier's service, name that responsibility and the approval process in the schedule.

The same discipline applies to changes. A new renewal campaign, an updated cancellation form or a replacement integration may affect the language journey even when the underlying software subscription remains unchanged. Include a review point for changes that alter customer-facing wording or routing.

A supplier's use of machine translation is not, by itself, evidence that the agreed language requirement has been met. Ask who reviews the output, how approved wording is protected from replacement and what happens when no approved version is available.

For a private business, establish the contractual language requirements from its service commitments and applicable obligations. Do not apply public-body standards merely because customers live in Wales. Conversely, do not label a Scottish service as having “no language requirements”: record the requirements of that service rather than relying on geography alone.

Make acceptance depend on complete customer journeys

Acceptance should test the contracted service, not just confirm that staff can log in. Define the expected result, the evidence to retain and the person authorised to accept each part of the delivery. Use test accounts and suitable test data rather than copying live customer records into an uncontrolled demonstration.

The following tests turn a cross-nation service brief into practical acceptance evidence. Select those that match your scope and add the expected outcome to the contract schedule.

Agree how defects will be classified and retested. A missing Welsh template, a broken integration and an incorrect account owner may have different operational consequences. The acceptance process should make those consequences visible instead of putting every defect into an undifferentiated list.

Ask the supplier to demonstrate the agreed configuration. A feature available elsewhere in its product range is not necessarily enabled, included or supported in your order. Record any dependency on an additional module or third-party service before accepting the journey.

Keep an evidence pack containing the test results, outstanding issues and sign-off decisions. Repeat affected tests when a material change alters the customer journey. This gives both teams a shared basis for deciding whether the contracted service continues to work.

Specify what happens to customer and churn data

Retention software can bring account records, usage events, support history and inferred churn indicators into the same workflow. Identify those categories separately. A contract that mentions only “customer data” may leave important questions about derived scores and activity histories unanswered.

The UK GDPR and Data Protection Act 2018 apply across Scotland and Wales, with the Information Commissioner's Office as the UK data protection regulator. Controller and processor roles depend on the processing activities and decisions involved, not on which nation hosts the buying team.

Where the supplier acts as a processor, the agreement must contain the required processing terms. Among other duties, processors must notify the controller of a personal data breach without undue delay. That legal requirement should not be replaced by an assumed Scottish or Welsh notification window.

For the operational schedule, ask the supplier to identify:

Do not treat a broad licence to operate the service as an answer to every secondary-use question. Put any proposed AI or model-training use through the appropriate legal and operational review, and state the agreed permissions and restrictions expressly.

Distinguish contractual export rights from the UK GDPR right to data portability. The statutory right has conditions and does not guarantee a complete export of every business record or derived analysis. Your service exit needs its own specification.

Use the data protection duties guide for the wider compliance work. The contract-specific task here is to preserve the agreed data behaviour when accounts move between teams, integrations change or the subscription ends.

Set support around the service, not the postcode

Support requirements should follow the hours and consequences of your customer journeys. A renewal workflow used during office hours and a customer-facing cancellation service may need different arrangements. Neither Scotland nor Wales supplies a standard support window for all retention software contracts.

State the support channels, service hours and escalation contacts in the schedule. Define what happens outside those hours, including whether an automated alert is monitored and who can suspend a faulty campaign. If the same platform serves both teams, identify a single operational owner for incidents that cross team boundaries.

Separate acknowledgement, investigation, workaround and restoration. A promise to respond is not a promise to restore the service. Ask the supplier to explain how each commitment is measured and what evidence the buyer can obtain.

Language defects also need an incident path. If the platform sends an incorrect language version or loses a recorded preference, staff need a way to stop further messages, identify affected accounts and correct the workflow. Include ownership of customer follow-up rather than treating the issue solely as a technical ticket.

The Contact-centre expectations guide can help frame service questions. Your agreement should then record the commitments actually offered and accepted, without assuming that Welsh buyers receive longer hours or Scottish buyers receive different response times.

Test exit with both teams' records

Read termination rights and operational exit support together. Notice periods determine when an agreement can end; export and transition arrangements determine whether the service can move successfully. Do not assume that a national location supplies either term.

Specify the records you will need after exit. These may include account identifiers, customer language preferences, approved templates, open tasks, communication history and available churn-score history. Also identify configuration information needed to understand how the workflows operated.

Ask for a representative export before signing or as an agreed acceptance condition. Have the Scottish and Welsh service owners inspect it. They should be able to find the same account, understand its current owner and identify the language and contact preferences needed to continue serving it.

Make the export format and assistance obligations explicit. “Data can be downloaded” does not answer whether relationships between records are preserved, attachments are included or field meanings are documented. A sample file is more useful than an unsupported assurance of portability.

For processing carried out on your behalf, UK GDPR processor terms address return or deletion at the controller's choice after the service ends, unless the law requires storage. Your exit schedule should explain the operational sequence, including continuing access during transition and the handling of backups under the agreed deletion process.

Finally, identify dependencies outside the supplier's platform. A telephony provider, CRM connector or messaging service may have its own access and termination arrangements. Assign responsibility for closing or transferring those connections so that neither team loses essential records unexpectedly.

Use a cross-nation signing checklist

Use this checklist as a sign-off record. Assign an owner and supporting document to each item; an unanswered question should remain visible rather than becoming an assumed contract term.

Keep the completed checklist alongside the signed schedules. If a supplier's standard terms conflict with a negotiated service commitment, resolve the conflict before signature and make the agreed document precedence clear.

Apply the checks to a shared service brief

Consider a business with customer-success staff in Scotland and Wales that wants to use one platform. It has chosen to offer English and Welsh communications for specified customer journeys. This is a service requirement to document, not evidence of a standard national contract.

Start with the account workflow. Define how staff record language preferences, allocate ownership and transfer an account between teams. Then identify which CRM fields and communication records the retention platform needs.

Ask the supplier to demonstrate a complete journey: import a test account, assign its owner, select an approved message, record a reply and transfer the account without losing its preferences. Include a cancellation request so the demonstration covers leaving as well as renewing.

Next, test a failure. Remove a required template or interrupt the test integration and observe the resulting alert, message suppression and escalation. Record who will correct the fault and who will contact any affected customer.

Finally, export the test account and check that both teams can interpret the files. Use the results to settle the service schedule and acceptance conditions. The resulting agreement may cover both nations, but its commitments come from the agreed service and applicable duties, not from assumed regional norms.

Common questions