This system map is part of the client SOP change adoption guide, which covers what to inventory before a client process transition. This page answers a narrower question for BPO transformation consultants: can the company's records actually be joined into one story?
The map: system, record, linking key, owner
Five systems usually hold the pieces. The table is the reference; the graphic shows the same systems as nodes with the keys moving between them.
| System | Record it holds | Linking key | Typical owner |
|---|---|---|---|
| Client email or change tracker | The instruction: what changed, who asked, when | Change request number, or sender and date | Client account lead at the outsourcer |
| Knowledge base | Procedure revisions, change notes, publish dates | Article ID and revision number | BPO knowledge team, often on client content |
| LMS or agent attestation log | Who confirmed which version, and when | Agent ID, team, SOP version, timestamp | BPO training team |
| QA platform | Reviews, scores, comments and QA alignment session notes | Agent ID, review date, QA form version | BPO quality team |
| Workforce roster | Which agent sat on which team on which date | Agent ID and effective dates | BPO workforce management or HR |
The keys repeat on purpose. The revision number appears in three systems, agent ID in three, and dates in all five. A case can be rebuilt only where the same key is recorded on both sides of a join.
The four joins and where each one breaks
Most archives keep the records but lose the keys. These are the four places to look.
| Join | Key on one side | Key on the other side | Common break |
|---|---|---|---|
| Instruction to version | Change request number or email date and sender | Change note on the SOP revision | Change notes say "updated per client" with no reference |
| Version to agent attestation | Version number or publish date | Agent attestation record with version | Agent attestations logged against the article, not the version |
| Version to QA result | Scoring form version or effective date | Review date and criteria | Scorecards edited in place, so old reviews show today's criteria |
| Agent to team | Roster with effective dates | Agent ID on attestations and reviews | Agents moved teams mid-period with no dated roster |
Most of these breaks are invisible until someone tries to rebuild a specific case. That is why the test further down picks one closed change and walks it through every system.
One fully joined case (Illustrative)
A fictional 900-seat BPO runs appointment scheduling for a regional healthcare client. It is not a real account or a completed deal. Follow one change through the five systems:
- Client tracker. Change request CR-318 asks agents to confirm the patient's preferred callback number before rescheduling. Dated, with the requester's role.
- Knowledge base. Article KB-2214 moves from version 7 to version 8. The change note cites CR-318 and the publish date.
- Agent attestation log. 112 of 118 agents on the account confirm version 8 within five days; six on leave confirm on return. Each row carries agent ID, team, timestamp and version.
- QA platform. The QA form adds a criterion for the callback check, effective from the version 8 publish date. Reviews after that date are scored against it.
- Roster. Two agents moved from the scheduling team to billing during the week; the dated roster shows which team each was on when reviewed.
Every join holds: CR-318 links the request to the version, the version links to agent attestations, the effective date links the version to the QA form, and the roster places each agent. Anyone reading the joined case can see the instruction, the rollout, the adoption rate and the quality result. The exception examples page shows what happens when two instructions collide; this map is what makes such a case traceable.
A ten-minute test of any archive
Ask the delivery director to name one closed change from two or three years ago. Then ask the system owners, without exporting anything:
- Can the knowledge team find the version that change produced, with its publish date?
- Can the training team say who acknowledged that version, by team?
- Can the quality team say which QA form applied the week after?
- Can workforce management say which team each agent sat on that week?
Tool settings decide several of these answers. Zendesk keeps article revisions for title and body, while publishing changes sit in a separate history view. Guru lets a sender export who acknowledged an announcement. Zendesk QA reviews export through an API, but dashboard data does not come with them.
Zendesk
GuruFour yes answers mean the joins exist. Each no is a finding to record plainly: "agent attestations exist from 2022 but carry no version" is something SourceX can weigh; a guess is not. The referral brief template has a field for exactly these findings, and the internal knowledge bases page describes the record class in general.
Owners, rights and what stays open
The map shows who holds each record, not who may license it. In outsourcing, the client often owns its procedures and interaction data, while agent attestation logs, QA alignment session notes and rosters may be the outsourcer's own. The client-owned vs company-owned data map explains the line; the SOP data-type page and AI agent adoption statistics give wider context. Start with the delivery director, who can name the executive with authority.
Unknown until SourceX reviews it: which records and years are the company's to license, how agent and customer details would be de-identified, whether a buyer wants adoption histories and whether any offer follows. 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.
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 the ten-minute test shows a BPO client can join its versions, agent attestations and QA results, register as a partner, check the company against who qualifies and read the program terms before you introduce the delivery director.