How to ask for website changes without losing time

A living website gets updated: a new price, a photo, opening hours, one more section. When you need to ask for website changes, the way you do it decides whether they are done in a day or whether weeks go by in crossed messages. The difference is almost never the technical difficulty, but the clarity of the request.

This guide shows you how to put together a request that can be carried out the first time, how to group your changes and how to tell a change from a bug. It works with any provider, and at the end we tell you how we do it at Pixie.

First: is it a change or a bug?

• A change is something new or different from what was agreed: another text, another photo, a new page, a different color.
• A bug is something that should work and does not: a form that does not send, a broken button, a page that does not load.

It is worth separating them because they are handled differently. A bug is fixed through support, and the sooner it is reported the better. A change requires defining what is modified and how much work it takes, and it may have a cost. If you are unsure, describe what you see and let whoever receives the request classify it.

Website changes: what information to include in each request

A good request answers four questions:

1. Where: the exact address of the page (copy the link) and, if needed, which part of the page.
2. What: what you want changed. "Change the price from 45,000 to 52,000" is clear; "update prices" is not.
3. With what material: attach the final text, the photos or the files. If you have an example or a screenshot, even better.
4. By when: if there is a deadline (a promotion, an event), say so from the start.

If the request is about a bug, add: what you did, what you expected to happen and what happened, which device or browser you saw it on and, if you can, a screenshot.

Write the complete texts, already reviewed

The back-and-forth of corrections takes up the most time. Before sending:

• Check spelling, figures, names and contact details.
• Send the text in a document or in the body of the message, not in an image.
• Say what replaces what. If the new text goes in place of the current one, say so.

Group the changes instead of sending them one by one

Every request has a fixed management cost: reading it, understanding it, testing it and publishing it. Ten separate requests cost more and take longer than one with ten points. A good practice is to gather the week's changes into a single numbered list:

1. Home page: change the main title to "…".
2. Services page: update the price of "…".
3. Contact: new opening hours.

And keep a copy of the list: it works as a history of what you asked for.

Use a single channel

Requests spread across WhatsApp, email, calls and social media messages get lost. Choose a main channel and always use it. At Pixie, support requests are registered from the support page: each ticket gets a reference number and is answered by email, so no request gets lost.

How changes are quoted

Many small changes do not need a long quote, but it is important to know beforehand how they work:

• An hours bank: you buy hours of work and use them when you need them.
• A monthly maintenance plan: it includes a number of hours of changes each month, without quoting each one separately. You can see how monthly maintenance works.
• A one-off quote: for larger changes, such as redesigning a section or adding a new feature.

Always ask what the service includes before requesting. If they quote a change, approve it in writing before it starts.

Timelines: what to expect

Timelines depend on the size of the change and on the schedule of whoever does it. As a general rule:

• Text or image changes are usually done quickly if the material arrives complete.
• Changes that touch the design or the structure take longer and are worth planning.
• Urgent bugs (the website down, a payment that does not work) should be handled with priority: clearly mark them as urgent and explain the impact.

An incomplete request is always delayed, because someone has to come back and ask you.

After the change: check it

When they tell you it is published, check it right away:

• Go to the page and verify that the change is there.
• Look at it from your phone too.
• If you do not see the change, it may be your browser's memory: try a private window. We have a technical guide on cache and CDN that explains why this happens.
• If something ended up different from what you asked for, reply in the same thread, saying what you expected and what you see.

Frequently asked questions

Can I change the texts myself?

It depends on how your website is built. Some have a panel to edit content; others are modified from the code. Ask which options yours has.

What if the change breaks something?

A responsible provider tests before publishing and can roll back. That is why big changes are best coordinated and not made directly on the live site.

How many changes fit in one request?

There is no fixed limit, but the clearer and more grouped it is, the better. If there are many and they are complex, a separate quote is probably a better fit.

What to do next

If you already have your website with us, write to us from support. If you do not yet, get in touch and we will tell you how we work. And to prepare the material from the start, follow the guide on website content.