This walk-through is part of the client SOP change adoption guide, which covers what to inventory before a client process transition. Here the job is to show one hard case in full, so a BPO transformation consultant knows what a valuable exception looks like.
The case file: one account, two instructions (Illustrative)
A fictional 640-person business process outsourcing company runs billing support for one utility client from two delivery teams, A and B, about 90 agents in all. The client has two stakeholders who can change procedure: a billing manager and a compliance lead. The outsourcer's knowledge team publishes SOPs in its knowledge base, team leads push read-and-acknowledge notices, and a quality team scores a sample of interactions every week.
Nothing here is a real account, a real client or a completed deal. The case is built to show how a common failure leaves a record trail.
Step by step: what happened, who decided, what was kept
Each row is one step. The middle column names the person who made the call; the last column names the record that captured it.
| Day | What happened | Who decided | Record kept |
|---|---|---|---|
| Day 1 | Client billing manager asks for a callback within 24 hours on disputed bills | Client billing manager | Email with sender, date and wording |
| Day 1 | Knowledge team publishes SOP v14.1 with the callback rule | BPO knowledge lead | SOP revision with publish date and change note |
| Day 2 | Client compliance lead asks for disputed bills to be transferred to the client's tier 2 line | Client compliance lead | Second email, from a different stakeholder |
| Day 3 | SOP v14.2 published with the transfer rule; team B acknowledges it, team A never receives the notice | Team B lead sends the notice; nobody owns team A's | Read confirmation log by agent, team and version |
| Day 5 | On the same call type, team A's calls, still following v14.1, fail against the v14.2 criteria while team B's pass in weekly scoring review | Quality manager | QA reviews and scoring review notes |
| Day 6 | Account lead escalates; client confirms the transfer rule wins, with the callback kept for out-of-hours calls | Client, in writing, after the outsourcer account lead asks | Client decision email and escalation ticket |
| Day 8 | SOP v15 merges both rules; read confirmation requested from both teams | BPO knowledge lead, on the client's ruling | New revision and a fresh read confirmation round |
| Day 11 | A re-scored sample passes on both teams | Quality manager | QA re-score against the v15 criteria |
Two features make this case hard rather than routine. The conflict came from inside the client, not from an agent mistake. And the first visible symptom, a QA split, pointed at the wrong cause.
Why this sequence is useful evidence
Take any one row away and the case stops explaining itself:
- Without the two client emails, v14.1 and v14.2 look like the outsourcer changing its mind.
- Without per-version read confirmations, nobody can show that team A never saw v14.2. Some knowledge tools support this directly; Guru announcements, for example, can require agents to acknowledge a card and let the sender export who confirmed.
- Without the scoring review notes, the Day 5 split reads as poor performance on team A.
- Without the client's written decision, v15 looks like improvisation.
- Without the re-score, nobody knows whether the fix worked.
GuruRead together, the records show the problem, the authorized action and the checked result. That is the shape of evidence that explains judgment: who noticed, who had authority to decide, and how the outcome was verified. A single current SOP shows none of it.
Where the trail usually breaks
The same case at a real company would rarely survive whole. Four gaps are common, and each is worth noting as a finding rather than guessing around:
| Gap | Why it happens | What it costs the case |
|---|---|---|
| Only the latest SOP kept | Migration or export carried the current version | The split between v14.1 and v14.2 vanishes |
| Read confirmations logged per article, not per version | Tool or configuration did not record version | Team A's missed notice cannot be shown |
| Scoring form edited in place | QA criteria overwritten when v15 landed | Old reviews appear scored against new rules |
| Client decision on a call, never written down | Escalation handled verbally | v15 has no documented authority |
Tool behavior matters here. Zendesk's help center keeps article revisions that show differences between versions, with publishing changes in a separate history view. Zendesk QA review data can be exported through an API with reviews, scores and comments, though not dashboard data. Whether a given BPO used these features, and for how long, is a question for its administrators. The system map lists the joins to check.
ZendeskHow to recognize a similar case at a client
You do not need to see records to know whether a client has cases like this. Listen for these signals on a discovery call:
- More than one client stakeholder can change procedure. Billing, compliance and operations each send instructions.
- Several teams or sites work the same account. Rollouts reach teams at different times.
- QA results sometimes disagree between teams on the same call type. Scoring review sessions discuss "which version applies".
- The company tracks read confirmations. A read-and-confirm step exists in the knowledge base or LMS.
- Escalations to the client are documented. There is a ticket, an email or a change request trail.
If three or more apply, ask the delivery director a metadata question: roughly how many conflicting or superseded client instructions do they handle a year, and how far back do versions and read confirmations go? Write down the answer, not the records. The SOP data-type page and the QA scoring form page describe each record class on its own.
Rights need care in outsourcing. The client may own its procedures and interaction data, while read confirmation logs and scoring review notes may be the outsourcer's own; see whether an outsourcing vendor can share client data. The who-can-say-yes decision tree shows who to bring in. Whether any records can be licensed, how they would be de-identified, whether a buyer wants them and any offer stay unknown until SourceX's rights review.
The introduced company needs 50+ full-time employees at peak (contractors excluded), documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 70% of the data is in English. Partners sign the Channel Partner Agreement before submitting, and the first valid introduction within the 90-day window is credited when the company submits a verified application. The BPO industry page covers the sector.
Next step
Refer a company. No cap on rewards. Default reward on a company's first qualifying transaction: the greater of $50,000 plus 5% and 15% of Actual Supplier Payout, with no cap; further qualifying transactions first agreed within 12 months of the first Closing pay 15%. Eligibility and payment conditions apply, including the USD 100,000 Minimum Transaction, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
If a BPO client handles conflicting client instructions like this and keeps versions, read confirmations and QA reviews, register as a partner, check the company against who qualifies and read the program terms before you introduce the delivery director.