Turn this loose change ask into a change request structured enough to assess, approve,
and later audit. Intake normalizes; it does NOT approve, schedule, or execute.
1. Extract the ask from the source (ticket thread, forwarded email, verbal summary).
Identify the requester and, where client-originated, whether they have authority to
request it — flag if unclear, don't assume.
2. Normalize into the six intake fields. Write only what the source supports; mark gaps
as OPEN rather than inventing content:
- What: the change, specific enough to execute from (system, component, from-state →
to-state).
- Why: business justification in one or two sentences.
- Scope: systems, sites, clients, users affected; explicitly name what is OUT of
scope.
- When: requested window, or "no window proposed" if none was given.
- Rollback: the reversal path the requester/tech described. If none, write "rollback
plan: OPEN — required before approval." Never draft one on their behalf.
- Risk: what could go wrong and who feels it, as an initial sketch (full scoring is
change-risk-assessment's job).
3. Check for an existing change record covering the same ask (search the change board)
— extend it rather than creating a duplicate.
4. Create or update the change ticket on the change board with the structured fields as a plain-text body. Title pattern:
"CHANGE: <system/component> — <one-line what>".
5. Route to the approval track by an initial read of risk and precedent:
- Matches a documented pre-approved standard change (check the client's documentation for the
desk's standard-change list) → note as a standard-change candidate; still
confirmed in change-risk-assessment.
- Anything else → normal track: hand to the pre-approval completeness gate, then
change-risk-assessment for classification.
- Requester says it must happen NOW to restore/protect service → flag as an
emergency-change candidate and point at emergency-change-handling; don't let
urgency skip the record.
6. Output: the change ticket reference, the six fields with any OPEN gaps listed, and
the recommended track with one line of reasoning.
Guardrails: intake never approves and never schedules — it produces the record and the
routing recommendation. Silence from an approver is not approval. Never fabricate
rollback plans, windows, or justifications to make the record look complete — an honest
OPEN beats a hollow field. Changes smuggled inside incident tickets get their own change
record. Check freeze calendars at intake (see maintenance-freeze-windows); a request
landing inside a freeze gets flagged immediately, not discovered at scheduling. Plain-text
bodies and notes — these records sync to the PSA.
Magic Library