Outsourced Philippines guide
Set a Two-Person Rule for Sensitive Client Requests
Define which requests need a second person, separate the preparer from the approver, and keep the evidence beside the decision instead of in a chat thread.
Some client requests are routine, and some can change a price, a bank detail, a legal position, or a public statement. The second category should never depend on one person's memory at the end of a long day. A two-person rule names the requests that need a second set of eyes, separates preparation from approval, and leaves evidence that the check actually happened.
On this page
Define which requests need two people
Start from consequences rather than job titles. A request needs two people when a mistake would be hard to reverse, visible outside the company, or expensive to correct. Payment changes, pricing exceptions, contract edits, account closures, and public responses usually qualify. Write the categories in plain language and include examples the team has actually seen.
Add a catch-all for requests that combine several risk factors. A small discount may be routine, but the same discount applied to a renewal with a payment change is not. Give the reviewer a short list of triggers to check. When the triggers overlap, the request goes to the higher review path. This prevents a low-risk label from hiding a high-risk combination.
Split the preparer and the approver
The preparer gathers the facts, drafts the response, and names the action requested. The approver checks the facts against the source and confirms that the action is allowed. One person should not perform both roles on the same request. This separation is the point of the rule, not an administrative extra step.
Name a backup for each role so the process does not stop during leave. The backup should have the same access and the same written criteria. If no qualified approver is available, the request waits or moves to a manager. Do not let urgency quietly collapse the two roles. Record the delay and the reason so the pattern is visible.
Require evidence with the approval
The approval should point to the client message, the current record, and the rule that permits the action. A note that says approved is not enough to reconstruct the decision later. Ask for the specific field or clause that was checked. If the evidence is missing, the approver sends the request back rather than filling the gap personally.
Keep the evidence where the work lives, not in a private inbox. A ticket, shared folder, or task record works if the right people can see it. Limit access to the people who need it, and avoid copying sensitive numbers into chat. The record should answer who asked, what changed, who approved, and when.
Log the exception rather than the conversation
When the team makes an exception, write down the normal rule, the reason for the exception, and the person who accepted the risk. A chat thread is easy to lose and hard to search. The log should be short enough to complete during the request. If it takes longer than the task, the form is too complicated.
Review exceptions at a fixed interval and look for repeats. Three exceptions for the same client may mean the rule is wrong or the client needs a different process. Decide whether to change the rule, train the team, or escalate the pattern. Close the loop in the log so the next reviewer understands the outcome.
Review the rule after an incident
After a near miss or a real error, trace the request through the rule rather than blaming the last person who touched it. Ask whether the request was classified correctly and whether the approver had the evidence needed. If the rule allowed the error, change the rule. If the rule was skipped, find out why the skip felt reasonable.
Update the training example and the written criteria in the same cycle. Tell the team what changed and why, without turning the review into a public trial. A rule that is updated after every incident becomes more useful over time. A rule that is only enforced when someone remembers will not survive a busy week.
Put the rule inside the workflow
A rule in a policy document is easy to forget when a request arrives in a chat window. Build the check into the tool where the request is handled. Require an approver field before the task can move to done, and block the closure when the field is empty. The control should appear at the moment of action, not in a separate training tab.
Keep the field simple: approver, date, evidence link, and decision. Too many fields encourage people to type a single word and move on. Test the workflow with a real request from the previous month. If the control adds more than a minute, simplify it before rolling it out. A rule that slows the queue without improving the check will be bypassed.
Handle urgent requests without skipping the check
Urgent requests still need a second person, but the second person can be a manager on call rather than the usual reviewer. Write the escalation path and the maximum time allowed for a decision. If no approver can be reached, the default is to hold the action and tell the client when to expect an answer. Urgency changes the speed, not the standard.
Record every urgent approval and review the pattern monthly. A high number of urgent requests may mean the normal path is too slow or the client is planning poorly. Fix the cause rather than normalising the exception. The two-person rule should reduce risk without becoming a bottleneck that people route around.
Sources and next steps
Continue with reporting and QA, then confirm scope, authority, and review ownership before expanding the role.