Changes happen. Your business shifts, a competitor launches something, a stakeholder joins late. The point of a change request process is to make the cost and schedule effect visible before the work starts, not after.
How to raise one
Send the request in writing, on your project thread or by email to [email protected]. Describe what you want changed and why. The reason matters, because there is often a cheaper way to achieve the same outcome.
What we do with it
- Check the request against the approved scope on your quotation.
- If it falls inside scope, we schedule it as part of the normal build and confirm that back to you.
- If it falls outside scope, we estimate the effort and send you a written variation showing the additional cost in MYR and the effect on the launch date.
- Work on a chargeable change begins only after you approve the variation in writing.
Inside scope or outside scope
Adjusting the wording on an existing page is inside scope. Adding three new pages is not. Changing a button colour is inside scope. Replacing an approved design direction after development has begun is not. The dividing line is the inclusions list on your quotation, which is why we read it out at kickoff.
Timing
A change requested during design costs far less than the same change requested during testing. Once a page is built, changing its structure means redoing layout, responsive behaviour and testing. Raise ideas as early as you can, even half formed ones.
Changes we will push back on
We will tell you when a requested change is likely to hurt performance, accessibility or search visibility, or when it conflicts with something you approved earlier. You can still proceed, but the recommendation goes on record.
Bundling changes
If you have several small requests, send them together. Batched changes are cheaper to implement and test than the same list dripped in one at a time.
To discuss a change before formally requesting it, reply to your email thread or write to [email protected].
