Free Website Change Request Board Template
A website change request board tracks e-commerce site updates from submission through triage, scheduling, build, QA, and live release.
Share template
Checkout has to work on day one, but an e-commerce build can still drift until the season’s over, or go live with basics like taxes, shipping zones, or card payments half-right. A website change request board gives every request one place to land and one path to production, so the work stays visible instead of turning into a thread of “quick tweaks” that always need a developer.
The board runs as a set of columns that move a change from first intake to launch, which means everyone can see what’s waiting, what’s blocked, and what’s ready for review before anything ships. Syne headings over Inter body text keep the board readable at a glance, with an olive background and ledger-blue accents to separate decisions from in-progress work without turning the page into noise.
- Submitted New requests land here, so you can capture them before they turn into scattered messages.
- Triage Requests get clarified and sorted here, so the next step and priority are decided before anything gets scheduled.
- Scheduled Approved work waits here with your own dates added, so the team knows what’s coming up next.
- Work in progress Active build work sits here, so it’s clear what’s being worked on right now and what’s still waiting.
- Review & QA Changes go here for checking, so issues get caught before anything reaches customers.
In Plutio, you run this as a project template, then add your own dates because the board carries the order of the work rather than a calendar. The board starts empty, so you create cards for each request and move them across until the change reaches Live.
We went from spending hours on every proposal to creating fully customized ones in under 5 minutes. That's not an exaggeration - we timed it.
What is on this board
6 columns, ready for your own cards. Adding it builds the board as a project in your workspace, with every column in place. The cards in the preview are examples of how the board is used, and are not added.
| Column | What is in it |
|---|---|
Submitted | A starting column for new change requests before anyone commits to building them. |
Triage | A decision column where each request gets clarified, sized up, and routed to the right next step. |
Scheduled | A holding column for approved work once it has an owner and your own dates attached. |
Work in progress | The build column for requests that are actively being implemented. |
Review & QA | A testing column for checks before release, including edge cases that affect checkout and totals. |
Live | A finish column that marks the change as shipped, so the team can see what’s already in production. |
What happens when you install it
- A project is created with its board and 6 columns, empty and ready for your own cards.
- Every card you add opens as a task with its own description, assignee, dates, subtasks and files, and columns are renamed, reordered or deleted like any other.
Who it is for
Web studios, freelancers, and product teams handling e-commerce builds who need a clear flow for changes after scope, before release, and during launch week.
Questions about this project template
What should a website change request board include?
A website change request board usually includes columns for intake, triage, scheduling, build, review and QA, and a final live state. The point is to show where each change is in the flow without turning the work into a calendar.
How do you handle change requests during an e-commerce build?
A team captures each request as a single card, then confirms what needs changing during triage before scheduling work. The card moves through build and QA so launch changes don’t skip review.
How do you stop small website tweaks from turning into endless work?
A change request board makes every tweak visible and forces a decision on scope before work starts. The work moves forward only after triage, so “quick” requests don’t quietly stack up in the background.
What’s the difference between triage and scheduled in a change request workflow?
Triage is where a request gets clarified and the next step gets decided. Scheduled is where approved work waits with an owner and timing, ready to be picked up.
Should QA be a separate step for website updates?
QA works best as its own step when changes affect checkout, tax rules, shipping zones, or payments, because mistakes show up at the worst possible time. A separate QA column also makes it clear what’s waiting for review versus still being built.
Do website change request boards need dates?
Dates help if the team is coordinating a release window, but the board itself can stay order-based. This template leaves dates to you, because the workflow is about state and readiness rather than a fixed schedule.
Start free today
Your entire business, one login away
No credit card required. No contracts. Just the tools you need to run, grow, and automate your business with Super Work AI.
No credit card required
