Most BOT conversations spend ninety percent of the time on the build and ten percent on the transfer. That ratio is backwards, and it is the single best predictor of how the arrangement will end.
The build is the easy part. Any competent partner in India can hire fifty engineers and put them in a building. The transfer is where the value either arrives or quietly does not, and by the time anyone is paying attention to it, the decisions that determined the outcome were made eighteen months earlier.
So this is a guide to BOT written backwards from the transfer, which is where it should be written from.
What BOT actually is
A partner establishes and runs your capability center, then hands you ownership once agreed milestones are met.
- Build: Entity groundwork, location, leadership hiring, recruitment, infrastructure, security, HR and payroll, governance, operating processes.
- Own: The partner operates while the center matures. Your teams work with it daily. You learn what you did not know about the market, the talent, and your own assumptions.
- Transfer: People, contracts, systems, IP, vendors, documentation and governance move to you.
The important distinction from outsourcing is not who does the work. It is where the arrangement is designed to end. Outsourcing ends with a renewal. BOT ends with you owning an operation.
If your contract does not make that ending concrete and dated, you have bought outsourcing with a hopeful clause attached.
The real argument for BOT is not speed
Every vendor pitches speed. It is true and it is not the point.
The actual case is that BOT inverts the order of commitment.
A DIY GCC asks you to commit first and learn second. You incorporate, sign a lease, hire a country head, build HR and payroll, and only then discover whether your compensation assumptions were right, whether the city has the talent depth you need, whether your engineering culture survives a five-hour time difference, and whether the functions you planned to move actually transfer well.
If any of those answers is unwelcome, you are holding a fixed cost base and a difficult conversation with a board.
BOT reverses that. You learn first with someone else carrying the operational risk, and commit capital once the thesis has evidence behind it. Your first fifty employees on day one of ownership are not strangers you just recruited. They already know your product.
That is a genuinely different risk profile, and it is worth paying for. Speed is a side effect. Timelines are milestone-driven, not calendar-driven Anyone quoting you a fixed transfer date before scoping is guessing.
Broadly, the shape looks like this.
- Months 0 to 2: Scope, location strategy, operating model, workforce plan, commercial structure, legal groundwork, first searches opened. The output that matters here is not a plan, it is clarity: who this center serves, what sits there, what stays at headquarters, what transfers later.
- Months 2 to 6: Hiring accelerates, infrastructure goes live, leadership lands, first teams start delivering. This is where a partner earns their fee, because the founding hires set the ceiling on everything afterwards.
- Months 6 to 12: The shift from adding headcount to building maturity. Process depth, leadership bench, meaningful metrics, more complex work moving in.
- Month 12 onward: Assessment against transfer criteria that were defined at the start.
Some centers are ready earlier: Some need longer because the capability is still developing, and extending is often the right call. What is never right is transferring on a date because the date arrived.
One thing worth saying plainly: a fifty-person team is not a GCC. It is a team. A GCC has management processes, security posture, quality standards, a leadership bench and integration with the business. Headcount is the least informative number in this entire model.
Where BOT goes wrong
We run this model, and these are the five failures we watch for. A partner who cannot name them is not worth hiring.
The incentives diverge quietly: The partner is measured on operational efficiency and headcount delivery. You want a capability you will own. Those overlap for about a year and then stop overlapping. The fix is contractual: measure transfer readiness explicitly, not just delivery and cost.
Transfer becomes an afterthought: If the operating model is built on the partner's systems, the partner's processes and the partner's management structure, unpicking it is expensive and slow. Every architectural decision in months 0 to 6 should be made asking: what does this look like when we own it? Very few programs ask that question early enough.
You inherit a dependency instead of a capability: The most common version of this failure. Critical knowledge sits with partner staff who do not transfer. On paper you own a center. In practice you own a team that has to call someone else to understand its own systems. Guard against it with documentation requirements, leadership development inside the client-facing team, and direct client engagement from month one.
The cost model ages badly: Indian compensation, real estate and technology costs move. A business case built on one fixed projection will be wrong by year two. Build sensitivity scenarios and revisit them, or you will end up renegotiating from a weak position.
The center never grows up: A GCC doing only repetitive execution stays a delivery arm. If you want it to eventually own product lines or run strategic work, the roadmap has to show how the work complexity increases, and the hiring has to anticipate that from the start. You cannot bolt seniority onto a center designed for throughput.
BOT versus DIY: the honest test
DIY is genuinely better when the parent company already has India experience, an established legal and finance function, local hiring capability, credible GCC leadership, and enough internal bandwidth to run the setup without distracting the core business.
If all of that is true, paying a partner to do what you can already do is a poor trade, and any honest provider will tell you so.
BOT wins when strategic urgency is high and local execution capability is low. Specifically:
You are entering India for the first time. Hiring at scale is your binding constraint. Leadership cannot spare the bandwidth for a setup program. The center needs to be productive before your internal organization is ready to run every function. Or you want to validate the operating model before committing capital.
The question to ask is not "BOT or DIY." It is which path gives us the lowest risk-adjusted route to the capability we actually want to own.
Sometimes that answer is neither, and a dedicated team is the right first step for a year. That is a legitimate outcome of the conversation.
What has to be in the contract
- Look past the monthly management fee: These clauses determine whether you get a capability or a long outsourcing arrangement with a transfer clause stapled on.
- Scope by stage: What the partner owns during build, own, and transfer, stated separately.
- Employment: Who employs, manages, evaluates and retains staff at each stage, and what happens to those employment relationships at transfer.
- Governance: Who decides what, operationally and strategically, and how that shifts over time.
- Intellectual property: Code, documentation, processes, data, work product. Unambiguous, from day one.
- Technology and systems: Who owns infrastructure, licenses and access controls, and which of them transfer.
- Security standards: Which controls apply and who audits them.
- Performance: KPIs that include capability maturity, not only delivery and cost.
- Transfer definition: What transfers, when, and against which objective criteria. This is the clause to spend your legal budget on.
- Early and late transfer: What happens if you want to take ownership sooner, or extend the operating phase.
- Exit: What happens if the relationship ends before transfer. Nobody wants to draft this and everybody should.
Measuring whether it is working
Headcount tells you almost nothing. A seventy-five person center owning complex work with real process maturity is further along than a two-hundred person center doing throughput.
Track six dimensions instead.
- Talent: hiring velocity, retention, leadership depth, coverage of critical skills.
- Operations: productivity, quality, service levels, process maturity.
- Business value: scope and complexity of work owned, stakeholder satisfaction, contribution beyond delivery.
- Technology: infrastructure readiness, security posture, architecture maturity.
- Financial: cost per role, total operating cost, forecast accuracy against the original case.
- Transfer readiness: documentation completeness, leadership ownership, process independence from the partner, vendor transition status, governance maturity.
That last dimension should be reported from month three, not month fifteen. If nobody is scoring transfer readiness early, it is not being built.
Questions to ask any BOT partner
Ten, and the quality of the answers matters more than the content.
- What exactly happens in the build phase, week by week.
- Who employs the people during their own phase.
- What precisely transfers, and what does not.
- What happens to key people at transition.
- How is leadership succession handled?
- Which systems and contracts come with us.
- How is our IP protected throughout?
- What happens if hiring targets are missed?
- How do costs adjust when the market moves?
- And what objective criteria determine that we are ready to transfer.
A provider who answers the last one with "when you feel ready" has not built this before.
When BOT is the wrong answer
Three situations, stated plainly because pretending otherwise wastes everyone's quarter. You already have Indian infrastructure and experience. Build it yourself.
You do not want to own the operation. Then you want outsourcing, and BOT adds cost and complexity for a destination you do not want.
The team is small. Below roughly twenty to thirty people, the setup complexity rarely justifies a formal BOT arrangement. A dedicated team gets you the same capability with less structure.
Build for the transfer
A successful GCC is not defined by how fast the first people joined. It is defined by what you can own and operate once the partner steps back. That is the whole point of the model, and it is the part most contracts treat as a footnote.
Design the ending first. Everything else follows from it. Thinking about India and unsure whether BOT, a dedicated team, or a direct build is right for your stage? Talk to us. We will map it against your growth plan before anyone talks headcount, and we will tell you if BOT is the wrong fit.
