A Website Handoff You Can Actually Use

“Your website is live; here is the login” leaves the important questions unanswered. Who renews the domain? Where does a quote request go? Can another person recover access? A useful handoff answers those questions in a working record and proves the answers with a short demonstration.

You can use this at the end of a new build, during a staff change or when a new maintenance partner takes over. It is an operational acceptance exercise. It does not decide the ownership terms of your contract; those belong in the agreement. Our guide to website ownership covers that separate question.

Demonstrate the tasks the owner will actually perform

Ask the builder to work through three everyday changes while the business representative watches: update a phone number, change a service description and replace a relevant image. Record where each change belongs and whether it affects more than one page. The point is to establish a repeatable task, not to deliver a long tour of every menu.

Then let the representative repeat one change in the agreed test environment. If the instructions stop making sense as soon as the builder stops talking, improve them before calling training complete. A two-minute screen recording of the actual task can be easier to maintain than a manual full of features the business never uses.

For a small team, also name the boundary: what staff may change themselves, and what should become a maintenance request. A new price label and a new checkout rule deserve different levels of review.

Use named accounts with the right responsibilities

A shared administrator login makes it harder to tell who changed something or remove one departing person’s access. Give each authorized person their own account and verify recovery through an appropriate business-controlled address. Avoid using an employee’s personal inbox as the only recovery route for an essential account.

WordPress distinguishes roles through capabilities. An editor can manage content without receiving every administrator function. The official roles documentation explains the defaults; installed plugins or custom roles can change what a specific site permits. Test the actual assigned account instead of treating a role label as sufficient proof.

Keep one secured administrator recovery route under the business’s control, with an agreed backup person. That does not mean giving every employee administrator access. Record access locations and recovery ownership in the handoff; exchange secrets through the approved password manager.

Write a renewal map before the first bill is missed

List the domain registrar, hosting provider, paid theme or plugin licenses, booking service and any other required subscription. For each, record the business account owner, renewal date, billing contact and consequence if it expires. Mark whether the item is included in an ongoing service or billed separately.

A practical record might say “booking platform: office manager; annual renewal; billing notifications go to the operations inbox; cancellation removes online appointment requests.” This is an illustrative entry, not a description of a particular provider’s terms. Confirm the actual behavior with the vendor.

Review the list against the signed scope. A provider may properly retain an agency license or manage hosting as a service. The handoff should explain that arrangement and the agreed transition process, without pretending every account can simply be transferred.

Trace one inquiry through the whole system

Submit an authorized synthetic inquiry with an unmistakable test label. Check the confirmation shown to the visitor, the stored record, the destination mailbox or CRM and the person assigned to respond. If there is an automatic reply, inspect it as the recipient. Verify that it gives an accurate next step.

For a shop, booking site or membership service, agree an equivalent controlled test with the operator. Use the provider’s test mode where appropriate; do not quietly create live payments or real bookings during a handoff exercise. Record the test environment and its limits.

Write the result in a form another employee can interpret: date, test reference, expected route, observed route, responsible person and unresolved issue. Keep customer information out of screenshots. A homepage screenshot proves little about the handoff between website and business.

Include the technical record and the recovery route

Ask for the supported platform versions, the location of custom code, update ownership, backup coverage and the procedure for requesting a restore. A content export alone does not represent every part of a WordPress installation. WordPress’s backup handbook distinguishes the database and files needed for recovery.

The Site Health information screen can help document the installed environment. It is a technical snapshot, not proof that a site is secure or that every integration works. Store the useful report privately and explain who will keep it current.

Do not put database credentials, application passwords or private customer records in an ordinary handoff PDF. The public-facing instructions and the restricted recovery materials can live in different places, with the handoff pointing an authorized person toward each.

Close the handoff with explicit open items

Separate confirmed items from pending work. “Analytics access invitation awaiting acceptance” is useful. “Analytics done” is misleading if the business cannot open the account. Assign each open item a person and a date, then agree which items affect launch acceptance.

Use the same record at the next staff or provider change. The names and subscriptions will change; the customer journey still needs a responsible operator. If nobody currently owns that work, bring the record to a website maintenance conversation and make the operating responsibilities part of the scope.