Three proposals arrive and none of them looks like the others. One quotes per hour, another per FTE, the third per resolved case. One includes supervision and quality, another charges them separately, the third doesn't mention them. The buyer builds a table, realises they aren't comparing the same thing, and ends up picking the lowest figure — which is almost always the bid that understood the work least.
The problem is rarely the providers. It's the document the bids were requested with. An RFP that says "we need twenty support agents, send us a rate" isn't asking for a proposal: it's asking for a number. And a number without scope means nothing.
What makes a bid comparable
Two proposals can be compared when they answer the same description of the work, in the same unit of measure, with the same split of responsibilities. That doesn't happen during evaluation; it happens in the brief. If the RFP doesn't fix the unit, each provider picks the one that suits them, and the comparison becomes a translation exercise built on your own assumptions.
An RFP isn't for getting the lowest price. It's for making the price mean the same thing across every answer.
What the document has to describe
The process, not the headcount. "Twenty agents" is a consequence, not a requirement. What needs describing is what comes in, what the person does, in which systems, on what criteria they decide, and when a case counts as closed. If the process isn't written down, that's a sign there's work left before going to market: we covered it in what to document before outsourcing a process.
Volume and its shape. The monthly total isn't enough. You need the distribution by day of week and by time band, known seasonality, and expected growth. Without the curve, the provider sizes on assumptions — and sizing is the variable that moves cost the most; the mechanics are in how to size a support operation.
Time per case, if you know it. If there's internal measurement of handle time or of how long a transaction takes, it belongs in the RFP. If it doesn't exist, say so rather than invent it: a serious provider will propose measuring it in the pilot instead of pretending to know.
Channels and languages. Voice, chat, email, back office; the share of each; which language at what required level, and whether that level applies to the whole team or part of it.
Coverage hours. Days, bands, holidays, and which time zone they're written in. A badly expressed schedule is the most common source of silent cost overrun.
Technology and who supplies it. Which systems the team will use, who pays for licences, who administers access, and what integrations are needed. This only gets settled by naming each tool; the detail is in tools and licenses in BPO.
Expected service level. The indicators, their exact definitions, and how they'll be measured. An SLA stated without a definition gets read differently in each proposal and then argued about in the monthly meeting.
The personal data framework. What data the team will see, under what classification, and which controls the organisation requires. In Colombia it's worth being explicit about the data processing roles in the contract, which we covered in controller vs. processor. General framing, not legal advice.
The client-side team. Who answers questions during transition, who approves material, who decides exceptions. An outsourced operation without an active counterpart doesn't start well, however good the bid was.
How to ask for the price
This is where comparability is won or lost. Three practical rules.
- Fix the unit yourself. Ask for the price in the model your operation can administer — hour, FTE or transaction — and if you want alternatives, ask for them as an additional proposal, not a replacement. The differences between models are in BPO pricing models.
- Ask for a breakdown of what's included. Supervision, quality, initial training, coordination, reporting, licences, rework. Not to negotiate each line, but to know what's in and what isn't.
- Ask for one-off costs separately. Transition, documentation, configuration, initial training. Mixing them into the recurring rate makes two identical bids look different.
One more thing: ask for the cost of growing and of shrinking. What happens if volume rises by a third, how much notice is required, and what's payable if it falls. Almost no RFP asks, and almost every operation needs the answer within a year.
What not to put in
A target budget, if what you want is to see how each provider prices. A two-hundred-item requirements list copied from a template, which forces answers about compliance instead of judgement. Credential questions taking up more space than the description of the work. And three-day response deadlines: a good proposal requires reading the process, asking questions and sizing the team; a short window only guarantees generic answers.
The process around the document
An RFP works better with a written question round and answers shared with every participant. That levels the information and, along the way, reveals something useful: the quality of each provider's questions says more than their corporate deck. The one asking about exceptions, the hourly curve or who decides an ambiguous case understood the work. The one only asking about the award date didn't.
If the process is new or volume is uncertain, say in the brief that the award includes a pilot with decision criteria defined before it starts. That changes what providers propose and reduces the incentive to over-promise. The design is in how to design a BPO pilot.
Evaluating without fooling yourself
Compare understanding of the process first, then the proposed operating model — structure, supervision, quality plan, ramp — and only at the end the price, normalised to the same unit and the same scope. If one bid sits far below the rest, the question isn't whether that provider is more efficient: it's what they assumed differently. Almost always they assumed less volume, less time per case, less supervision or fewer hours. How to read those differences is in how to read a BPO quote.
How smartBPO works it
When we receive an incomplete RFP we say so before quoting, and propose the missing questions along with the assumption we'd use if there's no answer. We quote in the unit the client asks for, and if we think another one fits the process better we present it separately with the reasoning visible. We always separate recurring from one-off costs, and we write down what the rate includes — supervision, quality, training, reporting — so the comparison doesn't depend on fine print. When volume or time per case haven't been measured, we propose a pilot with criteria agreed before it starts rather than signing on an assumption. We don't promise to be the cheapest bid on the table: we aim to be the one that reads without translation.