A change request usually arrives as a message. Sales wants one more column on a report. A client asks for two pages that were never in the scope. An engineer needs a configuration change in production before Friday. Each request is reasonable on its own. The trouble is that it landed in a channel where nothing can be decided: nobody can say who approved the last one, what it cost, or whether the same change was already turned down in July.
Most change request templates solve the first half of that problem. They hand over a document with fields for the description, the reason, the impact and a signature line. That document is worth having, and a complete version of it is written out below. What decides whether change control actually holds is the half that comes after the form is filled in. Where the request waits, who is holding it, what the requester hears back, and whether any of it can be read six months later.
What the form is for, and what it is not for
A change request form is a decision record. Its job is to capture enough about a proposed change that somebody with the authority to say yes or no can do so without a meeting, and to leave a trace of that decision that survives the people involved.
It is not a queue, and treating it as one is the most common way the process collapses. A form produces submissions. A queue needs a status, an owner, and a place where the same item can be looked at twice. A document cannot hold any of those, so teams that stop at the document end up with two systems: the forms, and a spreadsheet where somebody retypes them.
Three failure modes follow from confusing the two.
Requests that are approved twice. Two approvers see the same request in different places and both answer. The requester gets two answers, and the one who acts first sets the outcome.
Requests that die silently. A request is read, judged low priority, and never answered. Nothing in the process notices, because nothing in the process expects an answer. The requester learns to skip the form next time and ask in person, which is exactly the behaviour change control exists to prevent.
Requests that cannot be reconstructed. The change shipped. Nobody can produce the assessment that justified it, because the assessment was a paragraph in a thread.
A form that only collects is fine for a one time survey. For change requests, which arrive continuously and each need a reply, the collection is the easy part.
The fields that make a request decidable
A field earns its place if leaving it out would force a round of questions. Every other field is a cost paid by every requester forever. The list below is grouped by the question each group answers.
Who is asking, and on whose behalf
Name, email, team, and the system or project the change touches. The last one matters more than it looks: it is what routes the request to the right approver without anybody reading it first. Make it a fixed list rather than free text, because a free text answer of "the portal" will match nothing when the log is read later.
What the change is
Ask for the current behaviour and the wanted behaviour as two separate questions. Requesters given one box write the wanted behaviour only, and the reviewer then has to guess what it is being compared against. Two boxes produce a usable before and after in almost every case, at the cost of one extra field.
Why now
The reason, and the consequence of not doing it. The second half is the one that separates a genuine priority from a preference. A request whose answer to "what happens if this waits until the next release" is "nothing in particular" has answered its own question.
What it affects
Systems touched, people affected, whether any data changes shape, and whether anything outside the team has to change at the same time. Keep this to a short checklist with an other box. A free text impact assessment invites either a sentence or an essay, and neither can be counted.
Risk, in the requester's words
Two questions carry most of the value here. What could go wrong if the change is made, and how it would be undone. A requester who cannot describe the rollback has told the reviewer something important without being asked.
Timing and cost
Wanted date, hard deadline if there is one and why, and an estimate of effort if the requester has any basis for one. Mark the estimate clearly as the requester's guess so that nobody later reads it as a commitment from the team doing the work.
The decision, filled in by the reviewer
Outcome, reason, approver, date, and the release or window the change is going into. These are not questions for the requester, and putting them on the public form is a mistake that gets made often. They belong to the record, not to the submission, which is why the tool holding the record needs somewhere for the team to write that the requester never sees.
The template, written out
Copy this as it stands and cut what does not apply. Field types are given so it can be rebuilt in any form tool.
Requester
- Full name. Short text. Required.
- Email. Email. Required.
- Team or department. Multiple choice. Required.
- Requesting on behalf of someone else. Yes or no.
The change
- System, product or project affected. Multiple choice. Required.
- Title of the change, in one line. Short text. Required.
- How it works now. Long text. Required.
- How it should work instead. Long text. Required.
- Type of change. Multiple choice: new capability, correction, configuration, removal, documentation. Required.
Reason
- Why the change is needed. Long text. Required.
- What happens if it is not made. Long text. Required.
- Who asked for it originally. Short text.
Impact
- Other systems affected. Checklist with an other box.
- People or teams affected. Checklist with an other box.
- Does any stored data change shape. Yes, no, or not sure. Required.
- Does anything need to be announced to customers. Yes or no. Required.
Risk
- What could go wrong. Long text. Required.
- How the change would be undone. Long text. Required.
- Has this been tried before. Yes or no, with a box for what happened.
Timing
- Wanted date. Date.
- Hard deadline, and what makes it hard. Short text.
- Requester's estimate of effort. Multiple choice: hours, days, weeks, no idea.
Attachments
- Screenshots, specifications, client email. File upload.
For the reviewer, not shown to the requester
- Decision: approved, approved with conditions, deferred, declined.
- Reason for the decision.
- Approver.
- Release or window.
- Actual effort once done.
That is twenty two questions at the outside, and a realistic internal version runs to twelve. Cut the type of change field if there is only one kind. Cut the attachments field if nothing is ever attached. Do not cut the rollback question.
Where the document stops being enough
The form is the cheap part. What differs between setups is what happens to the submission afterwards, and that is where the running cost sits.
| Setup | Handles the collection | Handles status and owner | Handles the reply | Where it breaks |
|---|---|---|---|---|
| Word or PDF template by email | Yes, badly. Versions multiply | No | Manually, in the thread | Two people edit two copies and neither is the record |
| Form to spreadsheet | Yes | Columns can hold it, if everybody updates them | Manually, from a separate mailbox | The spreadsheet and the mailbox drift apart within a month |
| Project or service management tool | Through a request form, often rigid | Yes, this is what it is for | Yes | Cost and setup scale with seats and with process. Heavy for a team of five |
| A form tool with response management | Yes | Yes, each response carries its own owner and stage | Yes, from the response itself | Not a substitute for a full service desk if change requests feed into incident management |
The third and fourth rows both work. The question is which one matches the size of the problem. A team fielding four hundred changes a month across regulated systems wants the service management tool and the audit trail that comes with it. A team fielding fifteen a month wants the request, its status, and the reply in one place, and will abandon anything that takes a week to configure. The feature list worth checking in any candidate is short: stages that can be renamed, an owner per response, internal fields the requester cannot see, and a reply that sends from the record rather than from somebody's inbox.
The approval path, written down before the first request
Most change processes fail at the approval step rather than the intake step, and for a dull reason: nobody wrote down who decides what. The fix is a table, agreed once, that lives next to the form.
Set thresholds rather than naming every case. Configuration changes with no data effect and under a day of work go to the team lead. Anything touching stored data or customer facing behaviour goes to the named owner of that system. Anything with a cost above a stated figure goes to whoever holds the budget. Everything else is the lead's call.
Then set two rules that are easier to agree in advance than in the moment. A request with no decision after a set number of working days is escalated automatically, not left. And a declined request is answered with the reason, because a decline without a reason comes back as the same request in three weeks.
One approver per request, always. Splitting approval across two people without saying which one is accountable produces the double answer described earlier. If two sign offs are genuinely needed, make the second one a condition recorded by the first approver rather than a parallel path.
What the requester hears back
Change control has a reputation problem, and it is earned by silence. Three messages fix most of it, and all three can be automatic.
The first goes out the moment the form is submitted, and includes a copy of what was written. This single message removes the most common follow up, which is somebody asking whether the request arrived. It also gives the requester a chance to notice that they described the wrong system.
The second goes out when the status changes. Moving from received to under review to a decision is three short notes, and nobody needs to write them from scratch if the wording is saved once as a template.
The third is the decision itself, with the reason and the window. Send it from a saved template too, especially the decline, because the decline is the message people put off writing and then forget. Setups where the reply goes out from the response record itself keep the sent message attached to the request, which is what makes the record complete a year later. Teams handling several intake streams at once tend to arrive at the same arrangement, and the common patterns look much alike whether the intake is change requests, support tickets or applications.
What the log tells you after a quarter
Once a hundred requests have gone through the same form, four numbers become available, and each one changes a decision.
Volume by system tells you where to spend engineering time. A system generating a third of all change requests has a design problem, not a process problem.
Time from submission to decision, split by approver, shows where the queue actually sits. It is rarely where people assume.
Decline rate by requesting team shows whether the form is being used as intended. A team with a very low decline rate is probably filtering before it submits, which sounds good and means the log is incomplete.
Estimated against actual effort, on the requests that were done, is the number that makes the next round of estimates believable. It only exists if somebody records the actual, which is why that field is on the reviewer's side of the form.
None of this requires analysis tooling. It requires that all the requests be in the same place with the same fields, exported as a CSV, which is the practical argument for one intake form over three.
What to change first
Put the intake in one place this week, even if the fields are imperfect, because a single incomplete log beats three complete threads. Then add the two things that make it a process rather than an inbox: an owner on every request and an automatic acknowledgement with a copy of what was submitted. If the current setup cannot do those two, see what the handling looks like in a tool built around them, such as Halict.
Q1. What is the difference between a change request form and a change order?
A change request is the proposal, and it may be declined. A change order is the instruction that follows an approval, usually where money or a contract is involved, and it records agreed cost and schedule. One form can carry both if the approval fields include the agreed cost, but many teams keep the order as a separate signed document for contractual reasons.
Q2. Who should be able to submit a change request?
Anyone affected by the system, with no gate on submission. Gating the intake pushes requests back into private channels, which is the problem the form exists to solve. Control belongs at the approval step, not at the door.
Q3. Do small teams need a change request process at all?
A team of three sharing one codebase usually does not need a form. The threshold is not headcount but memory: once changes are requested by people outside the team doing the work, or once anybody has to explain a past decision, a written record costs less than the reconstruction.
Q4. How long should a change request form take to fill in?
Five minutes for a routine request. Anything longer and requesters start batching several changes into one submission, which makes each one impossible to decide separately. If the form cannot be completed in five minutes, cut fields rather than adding guidance.
Q5. Should emergency changes use the same form?
Yes, but filled in after the fact rather than before. Emergency changes that bypass the record entirely are the ones that get repeated by mistake. Keep a flag for retrospective entries so the decision timings are not read as though the process ran normally.