A site can be live and still be hard to operate. Before blaming the platform or provider, identify which edits your team expected to make, who had access, and what the proposal promised. Some sites are intentionally developer-managed; others include an editor interface and training. The right remedy depends on the agreed operating model.
List the edits your team actually needs
Write down recurring tasks: changing opening hours, updating a staff biography, publishing a case study, replacing a service price, adjusting a form recipient, or adding a location page. Each may use a different part of the system. “We need to edit the site” is too broad to diagnose.
Ask a staff member who will do the work to attempt one harmless change in a staging or preview environment. Record where they get stuck. Is there no login, the wrong permission, an uneditable hard-coded section, an unclear content field, or a fear that publishing will break the layout? A five-minute observed task can reveal more than a generic training video.
Check the agreed handover
Read the proposal for CMS setup, editor roles, documentation, and training. If editing was included, request the missing invitation, walkthrough, or correction. If content updates were meant to be a paid maintenance service, ask for that service’s terms and consider whether a different operating model would fit better. Do not assume that owning the domain gives staff access to the CMS.
For an editor-managed site, ask the provider to document the safe fields and the changes that still require design or development. Staff should know how to preview, publish, undo, and find a previous version where the platform supports it. Keep administrator access with an authorized owner, while giving routine editors only the permissions they need.
Fix the workflow, not just the password
If each small edit breaks spacing or mobile layout, the issue may be the content model. Ask whether the page can use structured fields or reusable components instead of freeform formatting. If the platform does not support the required workflow, request the cost and risk of changing it before agreeing to a rebuild. A move can affect URLs, content export, and third-party subscriptions.
Designate a staff owner for approvals and a provider contact for technical issues. Test one change after handover while the project team is available. Keep the test record and documentation in a place the business controls, not only in an employee’s inbox.
ARCHV’s website service page says editing, access, handover, and support should be specified for the particular project. It does not promise a CMS for every site or unlimited future edits. If you are planning a new site, use the website estimate to explain who needs to update which content. For more on exit rights, see ARCHV’s pay-monthly website guide.
If the team is only missing access, ask for named editor invitations and a safe training page. If editing was never included, request a small add-on proposal describing the fields, roles, training, and test update you need. Avoid demanding full administrator access for every employee; broad permissions can create accidental changes to site settings unrelated to routine content work.
If the site uses WordPress, its official roles documentation explains why an Editor account and an Administrator account have different powers. Other platforms use different role names, so test the actual permission your staff receives rather than assuming the label is equivalent.