Outsourced Philippines guide
Keep a Decision Log for Role Scope Changes
Write down each scope change in the client's words, name the approver, and link the decision to the task inventory so the role does not drift by accident.
A role grows through small requests that each seem reasonable on their own. Someone asks for one more report, a weekly task becomes daily, or a coordinator starts answering a client question that used to go to the account manager. Without a record, the role quietly becomes a different job and the original scope discussion is impossible to reconstruct.
On this page
Record the request in the client's words
Write the request as the client stated it, then add the operational meaning in a separate line. The first version preserves intent, while the second shows what the team would actually do. If the client said help with reporting, the team might interpret that as building a new weekly pack. Keeping both lines exposes the gap before work begins.
Include the date, the channel, and the person who made the request. A verbal request in a meeting should be confirmed in writing before it enters the log. This is not bureaucracy; it prevents a later disagreement about whether the request was approved. A short confirmation message is enough when the client dislikes formal documents. Ask the client to reply with a simple yes so the record has a clear answer. If the client does not reply, note the follow-up date and keep the request open.
State the reason and the alternatives
Record why the change is being considered and what it replaces. A new task either displaces existing work, adds capacity, or changes the quality standard. Write which one applies. If the answer is unclear, the decision is not ready. The log should show the trade-off rather than only the desired outcome.
List at least one alternative, including doing nothing. The team might move the task to a different day, simplify the output, or assign it to another role. Comparing options makes the cost visible. It also gives the client a way to choose a smaller change when the full request is too expensive.
Name who approved and what changed
Record the approver by role and name, the date of approval, and the exact change to the task inventory. If the approval was conditional, write the conditions beside it. A scope change without an updated inventory is only a suggestion. The log and the inventory should agree when the next review begins.
Note who was informed and who was not. The account manager, the quality reviewer, and the person doing the work may need different levels of detail. Keep sensitive client information out of the general log and link to the restricted record instead. The log should be useful without becoming a second copy of the client file.
Link the decision to the task inventory
Assign an identifier to each decision and reference it in the task entry it changed. When someone later asks why a report includes an extra section, the identifier leads to the request and the approval. This link is more reliable than a folder of meeting notes. It also makes the history searchable by task rather than by date.
Update the time estimate when the scope changes. A task that gains a review step takes longer, even if the output looks similar. If the estimate does not change, the team is absorbing the difference somewhere else. Record that assumption so the next capacity check does not miss it.
Review the log at each account check
Bring the last few decisions to the regular account review and ask whether they still apply. Temporary changes should have an end date. Permanent changes should be reflected in the role description and the quality checklist. Decisions that no longer make sense should be closed rather than left open forever.
Keep the log small enough to read. One line per decision, with a link to detail, is usually enough. Archive closed entries by quarter and leave a short summary for the account. A decision log is valuable when it explains the present scope, not when it proves how much paperwork the team can produce.
Separate a scope change from a quality problem
Not every complaint is a request for new work. If the output is missing a required section, that is a quality issue to repair, not a scope change to approve. Ask whether the task description already promised the work. If it did, fix the delivery and record the correction. If it did not, the request belongs in the decision log.
Write the distinction into the account notes so the team applies it consistently. A client who repeatedly reframes quality problems as new requests may need a clearer acceptance checklist. A team that treats every correction as scope creep may miss a genuine gap. The log should show which interpretation was used and why.
Give the log a short monthly summary
At the end of each month, count the scope changes, the time added, and the changes that displaced other work. Summarise the result in a few lines for the account owner. Do not list every request again; point to the entries that matter. The summary should help the owner decide whether the role still matches the original brief.
Use the summary in the next planning conversation. If scope has grown without a matching change in hours, the team is absorbing the difference. If scope has shrunk, the role may have room for another task. Record the conclusion and the next review date. A monthly summary is more useful than a large report nobody reads.
Sources and next steps
Continue with operations support, then confirm scope, authority, and review ownership before expanding the role.