A change request process keeps small website updates from becoming a stream of vague messages, missed details, and unexpected risk. It should be lightweight enough for the team to use and specific enough to protect important paths.

Capture the request clearly

Record the page or workflow, desired outcome, audience, example copy or asset, deadline, reason, owner, and acceptance condition. “Make it better” is a conversation starter, not a development brief.

Classify urgency and impact

Separate broken forms, security issues, incorrect business information, scheduled launches, conversion improvements, content edits, and cosmetic changes. Note which requests affect search, revenue, privacy, accessibility, or integrations.

Confirm ownership and approval

Assign the person who can approve the content, design, business rule, legal wording, or launch. A request should not wait indefinitely because the reviewer was never named.

Test before publishing

Review desktop and mobile layout, links, forms, analytics, permissions, accessibility, structured data, and error states when they apply. Use representative content instead of testing only the happy path.

The website QA checklist gives a useful acceptance baseline.

Keep a change history

Record what changed, who approved it, when it shipped, what was tested, and what should be monitored. This makes future debugging and content refreshes easier.

Review the queue regularly

Close stale requests, combine duplicates, revisit deadlines, and identify repeated work that should become a template, component, integration, or documented process.

Website updates getting lost in chat threads? Ask Vertinus to turn them into a small, repeatable workflow.