Change Request Workflow Guideline
Department
Summary
How Kiluth handles a client change requested after a sign-off. The AE owns the Change Request (CR) end to end—capture, assess impact, price, get the CR Form signed, collect payment, then kick off the rework and re-sign-off the new output. The rule is simple: if a sign-off happened and the client wants a change, it is a CR, and the client pays. No unit starts rework until two hard requirements are met—a signed CR Form and a payment receipt—so hours are always logged and no team absorbs another unit’s miss.
Table of Contents
| Section | |
|---|---|
| 1 | Summary |
| 2 | Purpose |
| 3 | Prerequisites |
| 4 | Scope |
| 5 | Definitions |
| 6 | Operating Model |
| 7 | Roles & Responsibilities |
| 8 | The CR Rule |
| 9 | The Two Hard Requirements |
| 10 | Change Request Workflow |
| 11 | Checklist (Account Management Use) |
Purpose
This guideline defines how Kiluth runs a change request after a sign-off, so scope changes are captured, priced, signed, paid, and reworked without confusion — and without any team quietly absorbing another unit’s miss.
| Outcome |
|---|
| Every post-sign-off change becomes a tracked CR with logged hours, a signed CR Form, and a payment receipt before rework begins. |
Prerequisites
Before proceeding with this document, please review the following documents:
| # | Document | Purpose |
|---|---|---|
| 1 | Contracting & Change Order Workflow Guideline | Understand contract signing and how Legal drafts a Change Order / updated SOW for large or complex changes |
| 2 | Invoicing & Payment Operations Guideline | Understand invoice issuance and payment confirmation workflow |
| 3 | Onboarding Guideline | Understand how Kiluth uses Kiluth Tasks, Google Workspace, and other core tools |
Scope
This guideline covers:
| Included | |
|---|---|
| 1 | Handling any client change requested after a sign-off (brief, design, build, or any signed-off artifact) |
| 2 | Pricing the CR, getting the CR Form signed, confirming payment, and kicking off the rework |
| 3 | Re-sign-off on the changed output |
This guideline does not define initial contracting (see Contracting & Change Order Workflow Guideline), pricing strategy, or delivery execution mechanics. Those live in Legal, Account Management pricing, and Delivery docs.
Definitions
| Term | Definition |
|---|---|
| Sign-off checkpoint | A point where work is passed from one unit to the next only after the client signs off on the upstream artifact (e.g., brief sign-off before design, design sign-off before build). Freezes the artifact so downstream work builds on an approved base. |
| Sign-off proof | Evidence of approval/acceptance, linked from Kiluth Tasks as Sign-off proof: [Link] |
| Change Request (CR) | The client’s request to change an artifact after it has been signed off. The rule is absolute: if a sign-off happened and the client wants a change, it is a CR. Period—regardless of which unit caused any earlier omission. |
| Change Order | The signed document that authorizes a CR and records its fee. For most CRs the CR Form is the Change Order; large or contractually complex changes escalate to a Legal-drafted updated SOW. |
| CR Form | The client-signable form stating what is changing, the delivery impact, and the fee. Signing it confirms the client agrees to the change and acknowledges the fee. |
Operating Model
| Operating Model | |
|---|---|
| 1 | Kiluth Tasks is the system of record for work tracking, approvals, and handoffs. |
| 2 | Use checkpoints and decision points: don’t move forward until the previous step is “done”, and branches are explicit. |
| 3 | Handoff order: upstream defines handoff artifacts/exit criteria; downstream defines execution after handoff. |
Roles & Responsibilities
| Role | Responsibility |
|---|---|
| Account Executive (AE) | Owns the CR end to end. Creates and owns the CR task (Account Management); routes it to the right PM; prices the CR; issues the CR Form; kicks off rework once both requirements are met; secures client re-sign-off on the new output |
| Project Manager (PM) | Assesses delivery impact (man-hours, timeline, scope delta), pulling in the unit head when needed; on kickoff, assigns the executing unit(s) |
| Unit Lead / Head of Production | Helps assess impact for their unit; holds the line—no unit starts rework before both requirements are met; protects their team from absorbing other units’ or the client’s misses |
| Finance | Invoices the CR, confirms payment, issues the receipt to the client, and notifies the AE |
| Legal | Drafts/reviews a Change Order / updated SOW when a CR is large or contractually complex; validates contractual terms and signatures |
| Business Executive | Approves commercial commitments (as defined in Account Management docs) when escalation is needed |
The CR Rule
| Rule | |
|---|---|
| 1 | If a sign-off happened and the client wants a change, it is a Change Request. Period. It does not matter which unit caused any earlier omission—the signed-off artifact is the source of truth at that checkpoint. |
| 2 | The client pays for a CR. This is the default and only rule the protocol documents. (Whether the company ever chooses to waive a fee is a per-case management decision made off-book; it does not change any step below.) |
| 3 | A CR is not dev-specific. A change after any sign-off (brief, design, build) is a CR, routed to whichever unit performs the rework. |
| 4 | The CR is authorized by a signed document—the CR Form (or a Legal-drafted updated SOW for large/complex changes). Not email-only. |
The Two Hard Requirements
No unit starts rework until both of these exist. This is what protects every team—the CR always exists, so the hours are always logged and no unit silently absorbs another’s miss.
| Requirement | |
|---|---|
| Requirement 1 | Signed CR Form — the client agreed to the change and acknowledged the fee. |
| Requirement 2 | Payment receipt — money is in and confirmed by Finance, not merely promised. |
Change Request Workflow
What you’ll do: Handle any change the client requests after a sign-off—capture and raise the CR, assess impact, price it, get the CR Form signed, collect payment, then kick off the rework and re-sign-off the new output. The AE owns the CR end to end; the rework routes to whichever unit owns the affected work (designer, dev, or other).
Step 1: Capture & Raise the CR
The AE confirms it is a CR and raises it as the master record in Account Management.
Prerequisites: A sign-off has happened and the client wants a change.
Process:
| Action | |
|---|---|
| 1 | AE confirms the trigger: sign-off exists + change wanted → it is a CR |
| 2 | AE creates the CR task under account-management and assigns it to himself |
| 3 | AE documents what is changing, why, and which signed-off artifact is affected |
| 4 | AE creates a Document record in ERPNext (Kiluth Legal → Document), Document Type = Change Request. ERPNext assigns the CR ID automatically (e.g. CR-00001). Set Related Document to the base agreement’s record, and note the CR ID on the task |
CR reference: generated automatically by ERPNext when the AE adds the Document record (e.g. CR-00001) — no manual counting. That record is also where the signed PDF is stored and where the base agreement is linked (via Related Document).
| Task Template | |
|---|---|
| Title | Change Request – [Client Name] – [what’s changing] |
| Dept | account-management |
| Assignee | AE (self) |
| Project | PROJ-XXXX |
| Description | Client requested a change after sign-off. What’s changing • [Short] Artifact affected • [Brief / design / build], signed off on [date] Why • [Reason] Links • Sign-off proof: [Link] • Original brief / SOW: [Link] Output (filled as the CR progresses) • Signed CR Form: [Link] • Payment receipt: [Link] |
Checkpoint: Proceed only when the CR task exists under account-management, owned by the AE.
| Outcome |
|---|
| The CR is captured as the AE-owned master record, with the affected sign-off and artifact linked. |
Step 2: Route & Assess Impact
The AE routes the CR to the right PM, who assesses delivery impact and returns the man-hours.
Prerequisites: CR is captured and owned by the AE.
Process:
| Action | |
|---|---|
| 1 | AE picks the PM based on the unit that handles the affected work |
| 2 | AE assigns the PM to assess impact (via the template below) |
| 3 | PM assesses, pulling in the unit head to help where needed |
| 4 | PM returns the man-hours, timeline shift, and scope delta to the AE |
| Task Template | |
|---|---|
| Title | Assess CR impact – [Client Name] – [what’s changing] |
| Dept | [Executing unit, e.g. creative / technology / delivery] |
| Assignee | PM (pulls in unit head if needed) |
| Project | PROJ-XXXX |
| Description | Assess delivery impact for this change request. Assess • Man-hours • Timeline shift • Scope delta Links • CR task: [Link] • Signed-off artifact: [Link] Output • Man-hours estimate returned to AE |
Checkpoint: Proceed only when the PM has returned the man-hours to the AE.
| Outcome |
|---|
| Delivery impact (man-hours, timeline, scope) is assessed and returned to the AE. |
Step 3: Price the CR & Get the CR Form Signed
The AE prices the CR from the man-hours, issues the CR Form, and the client signs it (Requirement 1).
Prerequisites: PM has returned the man-hours.
Process:
| Action | |
|---|---|
| 1 | AE derives the fee from the man-hours |
| 2 | AE issues the CR Form to the client (template below); escalates to a Legal-drafted updated SOW only if the change is large or contractually complex |
| 3 | Client signs the CR Form |
| 4 | AE attaches the signed CR Form PDF to the ERPNext Document record and sets its status to Signed; links the CR ID on the task |
The CR Form is a full, signable document. It contains these sections:
| Section | |
|---|---|
| 1 | Cover — Customer, Service Provider (Kiluth LTD.), CR reference, related agreement, date raised |
| 2 | Change Summary — CR ID, title, requested by, priority, status |
| 3 | Background — how the change came up; whether the artifact was already signed off |
| 4 | Requested Change — the specific changes |
| 5 | Scope of Work — tasks by discipline (UX / UI / Dev / QA / PM) |
| 6 | Out of Scope — what’s excluded |
| 7 | Impact Assessment — estimated effort + target start / completion |
| 8 | Cost Estimate — hours × rate, subtotal, VAT, total |
| 9 | Fee Waiver — optional; include only when the company absorbs the fee (default is the client pays) |
| 10 | Approval — signatures for both parties |
| 11 | Appendix — reference designs |
📄 Example CRs to follow (fictional client and figures — use as a format guide):
| Example | Shows | |
|---|---|---|
| 1 | Change Request — client pays (PDF) | Standard CR for new scope; the client pays (no Fee Waiver section) |
| 2 | Change Request — fee waived (PDF) | A shared-miss change the company absorbs; includes the Fee Waiver section |
Checkpoint: Requirement 1 — proceed only when the signed CR Form link exists on the CR task.
| Outcome |
|---|
| The client has signed the CR Form, agreeing to the change and the fee. The signed form is linked on the CR task. |
Step 4: Invoice & Confirm Payment
Finance invoices the CR, the client pays, and Finance issues the receipt and notifies the AE (Requirement 2).
Prerequisites: Signed CR Form exists (Requirement 1 met).
Process:
| Action | |
|---|---|
| 1 | AE coordinates with Finance to invoice the CR fee |
| 2 | Finance issues the invoice and sends it to the client |
| 3 | Client pays |
| 4 | Finance confirms payment, issues the receipt to the client, and notifies the AE (records confirmation + date on the CR task) |
Checkpoint: Requirement 2 — proceed only when payment is confirmed by Finance and the receipt is recorded on the CR task.
| Outcome |
|---|
| The CR is paid, the receipt is issued to the client, and Finance has notified the AE. Both requirements are now met. |
Step 5: Kick Off the Rework
With both requirements met, the AE kicks off the CR exactly like a regular project kickoff.
Prerequisites: Signed CR Form (Requirement 1) and payment receipt (Requirement 2) both exist.
Process:
| Action | |
|---|---|
| 1 | AE confirms both requirements are met |
| 2 | AE assigns the PM to run the rework |
| 3 | PM assigns the executing unit(s) to start (template below) |
| Task Template | |
|---|---|
| Title | CR rework – [Client Name] – [what’s changing] |
| Dept | [Executing unit] |
| Assignee | Unit member(s), assigned by PM |
| Project | PROJ-XXXX |
| Description | Execute the approved change request. Both requirements met. Do • [The rework] Links • CR task: [Link] • Signed CR Form: [Link] • Payment receipt: [Link] Log • Log hours to this CR (project PROJ-XXXX) |
Checkpoint: Proceed only when the executing unit(s) have been assigned and started.
| Outcome |
|---|
| Rework is kicked off and assigned to the executing unit(s), with hours logged to the CR. |
Step 6: Execute & Re-Sign-Off
The unit completes the rework; the client signs off again on the new output, closing the loop.
Prerequisites: Rework has been kicked off and assigned.
Process:
| Action | |
|---|---|
| 1 | The assigned unit(s) complete the rework and log hours to the CR |
| 2 | AE secures the client’s re-sign-off on the changed output |
| 3 | If the changed artifact flows on to a further unit (e.g. design → dev), that unit’s normal sign-off checkpoint still applies |
Checkpoint: Proceed only when the client has re-signed-off on the new output.
| Outcome |
|---|
| The change is delivered and re-signed-off. The loop closes the same way the original sign-off checkpoint did. |
Checklist (Account Management Use)
This checklist is used by the AE to track progress for each change request. Complete each item in order where applicable.
| Checklist | |
|---|---|
| 1 | ☐ Trigger confirmed: sign-off happened + change wanted → it is a CR |
| 2 | ☐ CR task raised under account-management, owned by the AE |
| 3 | ☐ Routed to the right PM; man-hours assessed and returned to the AE |
| 4 | ☐ CR priced; CR Form issued to the client |
| 5 | ☐ Requirement 1: signed CR Form linked on the CR task |
| 6 | ☐ Requirement 2: payment confirmed and receipt recorded on the CR task |
| 7 | ☐ Rework kicked off only after both requirements are met (AE → PM → unit) |
| 8 | ☐ Hours logged to the CR by the executing unit |
| 9 | ☐ Client re-sign-off secured on the new output |