Review customer messages against the procedure the recipient will actually use. A technically correct registry change can still create confusion if a renewal reminder, transfer instruction or help article describes a different process. The useful output is a coordinated set of messages with clear responsibility, applicability and support routes.
Establish the source and effective state
Nominet's formal notice requires registrars to notify registrants of the new registration terms and update relevant customer arrangements where applicable before transition. The scheduled framework is distinct from the current one; instructions for an action today should not silently switch to a future procedure.
The future Registry-Registrar Agreement, clauses 3.8 and 3.9 covers making relevant terms known and highlighting key customer terms. Nominet's preparation guidance asks teams to review contracts, business processes, training and support materials. Read those requirements with the actual service and agreement in question.
This page helps organise that review. It does not provide a universal customer contract, legal approval or a claim that a standard email can satisfy every organisation's obligations.
Map messages to an owner
The roles below are suggested responsibilities to allocate inside an organisation; they are not assertions about a particular registrar's staffing.
| Communication | Audience | Factual dependency | Suggested owner | Review action |
|---|---|---|---|---|
| Advance notice of changed terms | Affected registrants | Applicable agreement, change and required notice | Contract/service owner | Identify affected customers, approval and evidence of notice |
| Renewal reminder | The authorised renewal contact | Actual expiry, renewal charge and renewal method | Operations or billing lead | Verify recipient, dates, links, charge basis and failure route |
| Expired-name message | Registrant with an expired name | Current state and remaining permitted action | Domain operations lead | State the available action without a misleading universal deadline |
| Registrar-transfer instructions | Registrant moving providers | Procedure in force, locks, TAC or TAG requirements | Support lead | Distinguish a provider move from a registrant change and check every step |
| Transfer-completion notice | Authorised parties to the move | Confirmed outcome and the intended registry record | Domain operations lead | Describe what completed; avoid implying an unrelated ownership change |
| Reseller help content | Customers of the reseller | Sponsoring registrar's service and responsibilities | Reseller and registrar contacts | Align instructions and identify who resolves each failure |
| Escalation and incident response | Customer whose issue remains unresolved | Provider complaints/support process and relevant Nominet route | Support manager | Make the first contact and escalation path clear and current |
Renewal and expiry messages
In the scheduled lifecycle policy, the required reminders include approximately one month and one week before expiry, and a further notice at or within five days after expiry where the registrant has not renewed. Check the exact policy conditions, the required description of notification methods and the treatment of a change of registrant near expiry.
Your message should answer the practical questions: which name, which expiry, what action, what charge and whom to contact. Avoid a bare “renew now” instruction that leaves the customer unable to distinguish an optional service charge, the domain renewal and an unrelated hosting invoice.
A provider's retail auto-renew arrangement should also be described accurately. A customer's payment preference and a registrar's registry renewal mode are different things. Use the lifecycle guide when reviewing copy that treats “auto-renew enabled” as a guarantee that the name is safely renewed in every circumstance.
A prospective buyer's optional drop reminder is a different message from a registrar's renewal reminder to its customer. DomainSabre's drop search and reminders concern a selected published schedule; they do not replace the registrant's provider instructions, reserve a name or attempt registration. Keep permission for those notices separate from promotional launch emails and general registry updates.
Transfer instructions and sensitive information
Separate instructions for changing registrar from those for changing registrant. When the future process is active, explain the authorised route for obtaining and delivering a TAC without encouraging customers to put codes in public tickets or messages. While current procedures remain in effect, direct the customer to the valid current process.
State which party performs each action and what establishes completion. If a receiving provider must first create an account or accept the move, the customer needs that information before the transfer starts. The transfer guide supplies the underlying distinctions, including renewal and retail-charge questions.
Fictional message-review example: a support article says “send us the code and your domain is transferred”. The reviewer identifies three missing dependencies: the correct authorisation, any blocking state and confirmation of successful completion. The revised article should explain the actual steps and result, rather than promising completion merely because a customer submitted a message.
Keep current and future material coherent
Prepare an inventory of public help pages, automated emails, canned support replies and staff notes. Record which change each item depends on, who approves it and when it should become active. If old instructions need to remain for historical cases, label their applicability and link to the current process.
Review cross-links as well as individual sentences. An accurate email can still send a reader to an outdated help page. A staff script can contradict the published renewal terms. Test the reader's whole route using fictional cases and the actual links, without sending unsolicited messages to customers as a review exercise.
Support escalation and compliance timing
Help the customer identify the provider responsible for the immediate task and the information that will help it investigate. A useful case records the domain, request time, relevant provider reference and a factual description of the problem. Do not ask for a password or transfer code unless the specific authorised workflow requires it.
For registry-specific escalation, use the current Nominet contact routes. Nominet's governance framework says the new obligations apply at transition while the detailed compliance approach develops. That is not a general permission to delay customer notices or ignore new duties.
Review before and after the confirmed transition
Before activation, check that the approved messages match the latest notice and your actual operating arrangements. After transition, verify the live customer path, resolve contradictory instructions and assign any remaining exception to a person who can close it.
Use the transition checks for operational handover and the readiness checklist to track which responsibilities apply. The transition hub remains the starting point for the scheduled/current distinction.