Your operations manager has changed. The new photograph is ready. Their biography has been approved.
You email the person who looks after your website and ask for the profile to be updated.
"Of course. We'll get that sorted."
A week later, the old photograph is still there.
Another message goes out. Then another.
The change itself might take minutes. Arranging for it to happen has somehow become an administrative exercise.
The delay may be in the queue, approval process or support arrangement rather than the edit itself. Ask who owns the request, when it is scheduled and whether the quoted response time means an acknowledgement or a completed change.
A small edit and a small job aren't always the same thing
Some website changes really are simple.
Replacing a paragraph, updating an address or changing a photograph may involve very little development work.
Others can look deceptively small.
Adding a new service to a navigation menu, for example, may require changes across multiple pages, responsive layouts and internal links.
Introducing a new enquiry field could affect validation, spam protection, email handling and how information is stored.
A sensible supplier should be able to distinguish between these situations.
Not every request deserves an invoice for half a day's development. Equally, not every request described as a quick change is genuinely quick.
The difficulty begins when nobody explains the difference.
The real delay is often in the queue
A two-minute edit can sit in an inbox for two weeks because the supplier has other projects, there isn't an agreed update arrangement or nobody has been assigned to handle smaller requests.
The work itself may not be the bottleneck.
That doesn't necessarily mean the supplier is being unreasonable. A studio managing several projects needs a way to prioritise work.
But the customer needs to understand that process.
An acknowledgement should explain what happens next.
If the request can be handled under an existing support agreement, the client should know when it is scheduled.
If it requires a separate quotation, that should be made clear before anyone assumes the work is underway.
And if the change is urgent, the supplier needs enough information to assess whether it can be prioritised.
Silence is a rather poor project management system.
Not every change has the same business impact
Consider three requests from a professional services firm.
The first is a new team photograph. It's useful to update, but the old photograph doesn't prevent customers from making contact.
The second is an outdated description of a service that the firm no longer provides. That could mislead prospective clients.
The third is a broken enquiry form preventing messages from reaching the business.
All three involve the website. They shouldn't necessarily receive the same priority.
When requesting work, explain the business consequence rather than simply describing the technical change.
"The contact form isn't delivering enquiries" tells the supplier more than "the website is broken".
Similarly, "we need the revised service information live before Monday's campaign" explains why a date matters.
It won't make every deadline possible, but it allows an informed response.
Agree how small changes will be handled
When commissioning a website, ask how routine updates work after launch.
Will your team be able to edit ordinary content? Does the supplier provide an allowance for small changes? Is work quoted individually? Can you purchase an ongoing support arrangement?
There isn't one correct model.
A content management system may be useful for a business that regularly publishes news, updates services or manages a substantial catalogue.
A custom-coded site may suit a company whose core content changes less frequently and which prefers updates to be handled through a controlled development process.
What matters is that the editing arrangements match the way the business actually operates.
If your team will make updates, verify that the right people can sign in and use the agreed editing controls. The business website access checklist covers those practical checks.
Ask who receives requests, how they are prioritised, what response times apply and which services incur additional charges.
Our guide to what happens after a website goes live covers the distinction between included project support, ongoing maintenance and further development.
Make the request easy to act upon
You shouldn't need to write a technical specification to change a telephone number.
But sending the right information helps.
Instead of "Can we update the team page?", provide the page address, the exact replacement text, the approved image and any date by which the change is needed.
For a more substantial request, explain the intended outcome and ask the supplier to confirm the scope.
One complete instruction is often more useful than a conversation spread across several emails.
If your team makes frequent updates, consider keeping a shared list of approved changes with the person responsible for each one.
That makes it easier to distinguish unfinished requests from new ideas.
Your website needs a sensible way to keep up with your business
An established business doesn't stand still after its website launches.
People join. Services evolve. Projects are completed. New capabilities become commercially important.
Your website needs a practical way to reflect those changes.
That doesn't mean every future request should be free, or that a supplier must be available at every hour.
It means that expectations should be clear and communication should continue after the initial build, within the agreed support arrangements.
At Smartcon Works, we believe those arrangements are worth discussing before launch, not when the first urgent change arrives.
After all, updating a website is supposed to be the smaller job.
Running the business is quite enough to get on with.