Hand off local business website edits with approval checks

Define a bounded editing responsibility

A new local editor does not necessarily need authority over the entire site. List the actual changes they will make, such as opening hours, menus or closure notices. Publishing, customer-enquiry access, billing and domain administration are separate responsibilities. This guide is narrower than transferring ownership and all contracts: it hands over everyday editing work. Identify who confirms the business facts and who can publish them so a contractor is not forced to decide whether a shop is really open. Bounded responsibility makes both training and later access removal easier to review.

Use individual access with the required permissions

Wix provides roles and permissions that can be matched to the collaborator’s work. Check the current project’s editing and publishing requirements and avoid giving everyone owner-like access. Review collaborator-seat and plan conditions as well. A shared login makes it harder to identify whose access to remove when employment or a contract ends. Record the collaborator, role, responsibility, granted date and review date, with an owner for removal. The practical test is whether the person can perform the assigned update without gaining unrelated access to customer records, payment details or administrative controls.

Standardise the update request

A request should include URL, affected element, old and new values, effective time, source and verifier. Make it look better is not an acceptance criterion. Image replacements need the selected file, alternative text and relevant languages. A temporary notice needs a retirement task. Give the editor enough verified information to avoid researching the same business fact again. If they discover another issue, record it separately for review instead of quietly expanding a small request into a larger redesign. A bounded request allows the reviewer to compare the actual result with a concrete authorised change.

Review drafts and live publication separately

Webflow distinguishes CMS saving, draft changes, queued publication and live publication. Use the project’s actual publishing process to keep unapproved content out of a release. A shared static element can affect several pages, so inspect scope when editing it. A preview and a live URL are different verification surfaces; check the real destination after publishing. When collaborators have other drafts in progress, understand which changes the release can include. Do not close an update request just because the editor saved it successfully. Completion requires the authorised content to be visible at the intended public location.

Provide recovery values and an escalation route

Keep previous values, affected URLs, action time and a recovery owner. A screenshot alone may not provide reusable copy, so retain necessary text or settings in an editable form. Decide who can remove misleading information temporarily and how an out-of-hours problem reaches the right person. If using a platform’s restore function, check whether it would also undo unrelated correct updates. A one-field mistake may need a targeted correction rather than a site-wide restore. The handoff should help the editor recognise the boundary of their authority and escalate before using a recovery action with a larger scope.

Complete one supervised update

Have the incoming editor perform a small fictional or readily reversible update through drafting, review, release and live verification. Do not complete the test by having the trainer click everything on their behalf; observe where the new editor becomes uncertain. Evaluate collaborator plans and review time separately. A sole editor may not need a new approval application, but still needs verified content and a post-release check. Keep documentation maintainable with URLs and decision conditions rather than an excessive collection of screenshots that becomes obsolete when the interface changes. Training is evidence of a completed sample, not a guarantee against future mistakes.

Confirm ownership and remove obsolete access

Walk through hours, image replacement, a temporary notice, failed publication and an absent owner. The new editor should explain who decides and what happens next. Transfer unfinished requests and scheduled updates from the outgoing person, then review obsolete access as appropriate. Completion means the new owner can perform the sample, identify the source and recovery route, and see remaining work. Use the broader website-handoff guide for ownership and contracts, the change-management guide for CMS conflicts and the hours guide for local information fields. Daily editing responsibilities should remain explicit within that larger arrangement.

• Accept a website handoff across updates, contracts and recovery
• Control content changes during a CMS migration
• Build a useful store-hours and directions page