What should your team be able to edit?
Give your team control over content they need to maintain, such as projects, service details and contact information. Specify the actual changes, who makes them, what needs approval and how they reach the live site. Agree separately which layout and functional changes need a developer.
A CMS handover request in our project records asked for field locations, editing limits and image specifications. Account access alone would not explain how to do the work.
Start with the work your team will do
A content management system, or CMS, lets authorised people maintain the website's content. What they can change depends on the platform and how the particular site is built.
Start your CMS requirements with ordinary jobs: add a completed project, correct a service description, update a team member or change a phone number. Include articles and FAQs if your team will maintain them.
Then identify who will do that work and how often. A marketing coordinator adding projects needs different control from an office manager requesting one factual correction each year.
“We want to edit everything” leaves both people guessing. Give the developer tasks they can design around, including what the team should leave alone.
This approach is established practice. The APS Academy's CMS requirements guidance includes user needs, content formats and preview arrangements. The plan below turns those requirements into specific work for a service-business team.
Example editing plan: a commercial cleaning company
This fictional company wants its marketing coordinator to maintain project stories and service content. Its operations manager checks service facts; its office manager publishes approved changes.
It does not need staff to redesign pages or build forms. Those are deliberate choices for this example, rather than limits every business should adopt.
| Content or function | Change and frequency | Person doing the work | Allowed control |
|---|---|---|---|
| Completed projects | Add an example when the project details and images are cleared | Marketing coordinator | Add text and images within the agreed project template |
| Service information | Correct details when the actual offer changes | Marketing coordinator, with operations approval | Edit agreed service fields while keeping the layout |
| Public phone number | Update when contact arrangements change | Office manager | Change the agreed shared contact field and verify affected pages |
| New quote form | Add when a new customer task justifies it | Developer, after scope approval | Build and test the new flow; no routine editor control required |
Ask the developer to confirm how the proposed build will support each row. A checked box beside “content editing” is too vague to settle these requirements.
Completed projects: follow the content into every placement
The project editor needs to know where to create an entry and which fields supply the title, summary, photographs and main description.
For this example, each project has its own page and appears in a project listing. Specify image dimensions, crop, file format and size limits for both placements. Record text limits and any fields that hide a section when left empty.
The coordinator prepares the entry using accurate, cleared material. The operations manager checks the project details; the office manager handles publication after those checks.
Preview the project page and its listing card, including on a narrow screen. A photograph that works inside the article may crop poorly in the card.
Adding another project should use the existing template. A new project layout or a new kind of content returns to the developer for assessment.
Service details: separate factual editing from changing the offer
Name the fields staff can maintain, such as the service description, coverage and relevant FAQs. Document heading or text limits and any conditions controlling which sections appear. Mark media as absent if these fields do not use it.
The coordinator enters a correction after the operations manager confirms the facts. Preview the affected service page and any summary that uses the same content before the office manager publishes.
Changing a service name may also affect navigation or its address. Treat that as a coordinated change, with the developer checking the consequences before release.
A text field does not authorise a new service promise. The person responsible for delivering the work still approves what the company says it provides.
Contact details: confirm what one edit actually changes
This plan calls for one shared phone-number field. The developer must identify its location and which public placements use it.
The office manager confirms the new number, enters it and checks the contact page, header and footer in preview. After publication, check the displayed number and the number opened by the call link.
Record the field's accepted format and any validation. There are no image requirements for this task.
If a phone number is repeated elsewhere as ordinary text, the shared edit will not necessarily change it. Identify those exceptions and assign the remaining updates.
Changing the public number also does not establish where form enquiries go. That routing is a separate requirement to confirm and test with the developer.
New functions: keep a clear route back to the developer
For this company, a new quote form is outside routine editing. The owner first explains what customers need to submit and who will respond.
The developer recommends the fields, checks the receiving system and scopes the build. Required fields, validation, any upload limits and confirmation messages belong in that work. Media is included only if the form needs it.
The office manager tests the proposed route in a safe test environment before the owner approves release. The agreed release owner then makes it live and checks it there.
Some builds allow staff to assemble pages or adjust forms through existing controls. If that is required, specify those tasks too. Do not infer the capability from a platform name.
Have the intended editor try a representative change
A demonstration should use the tasks you have agreed. Ask for one before accepting the editing setup, with the person who will actually maintain the site involved.
For the cleaning company, use the completed-project task:
- The coordinator finds the project section and creates an entry using safe sample material.
- They add the title, summary and permitted photograph using the documented field and image requirements.
- They preview the project page and listing card. If the title wraps badly or the crop hides the subject, they correct it.
- The operations manager reviews the project details, and the office manager follows the agreed approval and publication steps.
- The release owner confirms where the change is visible. Any separate website deployment remains assigned, rather than assumed.
Run this in an agreed test or preview environment. Do not experiment with live customer content to prove that a button works.
Notice where the editor gets stuck. Is a field hard to find? Does the preview omit the listing card? Is the next publishing step unclear?
Resolve those specific gaps before accepting that task. A successful project-entry demonstration does not prove every service edit or form change works too.
Saving content, publishing it in the CMS and releasing it on the public website can be separate steps. Confirm which apply to your build, who handles each and how an urgent correction reaches the site.
Choose how much control is worth maintaining
Give staff enough control to carry out their real work. A fixed project template can let them add useful evidence without adjusting spacing, typography and layout each time.
More layout freedom is worth considering when a capable team regularly creates genuinely different pages. It also needs clear limits, suitable guidance and checks before publication.
For a business making very few changes, an agreed provider-managed update route may be the better choice. Compare the work of maintaining editing access with the cost and response arrangements for requesting updates.
Familiarity matters too. Someone who understands an existing editor brings useful experience. Have them try the proposed setup before deciding whether that experience carries across.
Write down any required roles or approvals, then confirm what the selected setup actually supports. If approval happens outside the CMS, document that handoff. Do not assume software prevents publication merely because the team has agreed to seek approval.
Agree who handles mistakes as well. Ask what can be restored, who can do it and when developer help is needed. Do not assume every change has a one-click undo.
Our questions to ask a web developer cover assessing the provider's recommendation and control arrangements. This editing plan gives you the specific tasks to put in front of them.
Make the handover useful on an ordinary working day
A useful guide should help a colleague complete the agreed task later, without having to reconstruct the demonstration from memory.
For the editing work in scope, agree guidance that identifies:
- Where each content type, page section and shared setting is managed.
- Which fields staff can edit, their limits and any conditional behaviour.
- The image specifications and preview checks for the relevant placements.
- Who checks facts, approves content, publishes and handles any separate release step.
- Known quirks, the correction route and changes that need a developer.
Confirm the actual access, instructions or training included in the agreement. Also identify ongoing subscriptions, support costs and who maintains the underlying system.
Keep passwords and private customer information out of the planning sheet. Arrange access through the agreed secure method.
Put the editing tasks in your website brief, alongside the business reason for needing them. Use the content preparation guide to collect accurate material and clear its use.
At handover, carry the agreed demonstrations into your website launch checks. Record what worked and what still needs resolving; a login alone does not demonstrate independent editing.
With SOL, we agree any CMS capability, editing access and handover within the website development scope. Bring the changes your team expects to make, and we can assess the editing setup alongside the wider website plan.
SOL STUDIOS is Australia's leading design and digital systems studio for established businesses.
Contact Us
