It's the conversation that almost always gets left for the last week. The contract is signed, the team is selected, go-live is Monday, and someone asks whether the agents will work in the client's CRM or in one of the provider's. The answer changes the cost, the control and what happens the day the relationship ends. It isn't a technical detail: it's a design decision worth making before signing.
There are two possible setups and one blend. The team works inside the client's tools, the team works inside the provider's tools, or each layer of the process lives where it makes sense. All three work. What doesn't work is leaving it undefined.
The team works in the client's tools
This is the most common model when the process already exists and is being transferred. The client grants users in its CRM, ticketing platform, ERP or phone system, and the provider brings the people.
What you gain is direct visibility. The client sees activity in its own system, without depending on an intermediate report. Traceability is immediate, history stays where it already was, and nothing needs integrating.
What you pay is in licenses and in ramp speed. Every new person needs a user, and every user costs. If the provider rotates or reinforces for a peak, access has to be provisioned at the pace of the client's IT team, which is almost never the pace of the operation. That gap is one of the most frequent causes of a slow start.
The team works in the provider's tools
Here the provider brings the platform: telephony, case management, recording, reporting dashboard. The client receives reports and read access.
What you gain is agility and predictable cost. The provider scales users without asking permission, the tool cost is already inside the rate, and there are no dead licenses when volume drops.
What you pay is dependency and distance from the data. Operational information is born in a system the client doesn't own. That isn't bad by itself, but it forces three things into writing: what gets exported, how often and in what format. If that isn't defined, the client discovers the problem the day it wants to change providers.
The list to settle before day one
The discussion usually stops at the CRM, which is only one part. It's worth walking the full list and assigning an owner to each line:
- Case management system or CRM. Who provides it, how many users, who creates and deactivates accounts.
- Telephony or contact channel. Who holds the numbering and who stores the recordings.
- Email and signature. If the agent writes from a client domain, there are brand and configuration implications IT has to enable.
- Remote access. VPN, virtual desktop, multi-factor. Who grants it and how long it takes.
- Hardware and peripherals. Computer, headset, second monitor. Looks minor until audio quality becomes a service quality problem.
- Connectivity and backup. What happens when power or internet fails at the operating site.
- Supervision tools. Reporting dashboard, quality monitoring, attendance control.
- Third-party licenses. E-signature, identity verification, dialers, translation, anything billed by usage.
Each line needs three facts: who provides it, who pays for it, and what happens to it when the contract ends. A one-page annex prevents months of later argument.
How it shows up on the invoice
There are two ways to bill a tool, and it's worth knowing which one is being signed. Included in the rate: the provider absorbs the cost and dilutes it into the hourly or FTE price. Pass-through: the provider buys it and invoices it separately, sometimes with a handling percentage.
Neither is better. What matters is that the criterion is explicit and that usage-based licenses have a cap or an alert. A service billed by consumption, with no agreed limit, is the most common surprise on the third month's invoice.
If a tool is billed by consumption, the contract should say who authorizes additional consumption and from what point.
One practical detail: named-user licenses make peaks more expensive. If the operation grows thirty percent in November, license cost grows in the same proportion and doesn't come down until the contracted term ends. Worth reviewing alongside the seasonal peak plan, because it's a cost that almost never gets modeled.
The data still belongs to the client
Regardless of who provides the tool, business information and personal data don't change owner. The provider processes data on the client's instruction, and that has concrete consequences: access logging, control over who can export, deletion at the end, and the ability to hand over the database in a usable format.
In Colombia, the general personal data protection framework defines distinct roles for whoever decides about the data and whoever processes it on instruction, and that distinction should be reflected in the contract and in the technical configuration. We cover it in more detail in controller and processor roles. This is a general framing and not legal advice; each case should be reviewed with counsel.
The clause nobody reads and everybody needs
Exit. What happens to the data, the access, the recordings, the process documentation and the configurations when the contract ends. The time to negotiate that is at the start, when both sides want it to work, not at the end, when someone has already decided to leave.
A reasonable minimum: a deadline to hand over the information, the delivery format, proof of deletion, and a commitment to keep access alive during the handover. Without that, changing providers becomes an archaeology exercise; we wrote about doing it without breaking the operation in switching BPO providers.
Four recurring mistakes
Leaving access for go-live week. Provisioning users, VPN and multi-factor takes longer than IT estimates. If the team starts training without access to the real environment, the training is worth half.
Sharing users between agents. It saves licenses and destroys traceability. Without named users there's no quality audit, no attribution of errors and no control over data access.
Assuming the provider tool's report is enough. It usually is for day-to-day work and isn't for a quarterly review. Ask for raw data from the beginning, not the summary.
Not defining who supports the tool. When the client's system goes down, the operation stops and the SLA keeps running. That case should be anticipated: who reports it, how lost time is logged, and what happens to that day's measurement.
A mixed model is usually the right one
In practice what works best is leaving the master business system with the client — where the real data lives — and letting the provider bring the operational layers: telephony, dashboard, attendance control, productivity tools. The client keeps the data and the provider keeps the ability to scale without paperwork.
That design requires a minimum integration or, at least, an agreed export flow. Defining it costs a few days at the start and saves months of hand-built reports.
Where smartBPO fits
We build this list in the design stage, not in go-live week, and we put in writing who provides each tool, who pays, how many users are needed and what gets handed over at the end. When the client prefers the operation to live in its own systems, we request access early and fit the timeline to the real pace of their IT team. When we bring the platform, we define what gets exported and how often, so the information belongs to the client in practice and not only in the contract.