Decision intelligence · Global Capability Centers
GCC Operating Models: Choosing Between Captive, BOT, Managed and Hybrid
The operating model decision determines how fast you start, how much control you hold, what the cost curve looks like, and how easily you can change course. It is harder to reverse than almost any other choice in the program.
It should be decided against the work you intend to move and the control you genuinely need — not against a preference for ownership in the abstract.
Decision intelligenceReviewed by Ramesh Rathi, Vice President — GCC Enablement & ImplementationPublished January 2026Last reviewed February 202610 min read
Direct answer
Which GCC operating model should we choose?
Choose captive when the work is core, sensitive or long-horizon and you can commit senior management attention from day one. Choose build-operate-transfer when you want speed and a defined path to ownership, and are prepared to negotiate transfer terms rigorously up front. Choose managed services when the work is well-defined, benchmarkable and not a source of advantage. Choose hybrid — the most common outcome at scale — when different work streams genuinely warrant different answers.
The four models compared
Each model trades control against speed and fixed commitment against flexibility. There is no dominant option; there is a fit to your work portfolio.
| Model | Control | Speed to first delivery | Cost profile | Principal risk |
|---|---|---|---|---|
| Captive | Full — entity, employment, IP, culture and roadmap. | Slowest. Entity setup, hiring and governance are all yours. | Highest upfront and fixed; lowest marginal cost at scale. | Senior attention starves the ramp; the center under-performs while still fully costed. |
| Build-Operate-Transfer | Partial during build, full after transfer. | Fast. The partner already has entity, premises and hiring machinery. | Fee-based during build, then a transfer consideration and a step change to direct cost. | Transfer terms and valuation are ambiguous, and the option becomes expensive or impractical. |
| Managed services | Contractual. You control outcomes, the provider controls delivery. | Fastest. Capability exists on day one. | Variable and largely opex; predictable per unit but rarely cheapest at scale. | Capability never becomes yours, and the work quietly becomes unmovable. |
| Hybrid | Differentiated by work stream — captive core, partnered periphery. | Fast for partnered scope, slower for the captive core. | Mixed; requires disciplined allocation and clear boundaries. | Complexity in governance and accountability if boundaries are drawn loosely. |
What should actually drive the choice
- Criticality of the work: core product, proprietary data and regulated processes push strongly toward captive control.
- Definability: work that can be specified and benchmarked is a candidate for managed delivery; work that requires continuous context is not.
- Speed requirement: if a commitment depends on delivery within two quarters, a pure captive build is usually the wrong instrument.
- Management bandwidth: a captive center consumes senior parent-company time for at least a year. If that time is not genuinely available, choose accordingly.
- Horizon and exit: if the work may not exist in three years, do not build a structure designed to last ten.
In our experience five factors explain most of the decision. Ownership preference on its own explains very little.
What actually goes wrong with BOT
Build-operate-transfer is attractive because it appears to give speed now and ownership later. It works well when the transfer is engineered from the start and badly when it is left to good intentions.
The terms that matter are specific: what exactly transfers (people, contracts, IP, tooling, processes), on what timetable, at what price or formula, under whose employment terms, and what happens if the transfer is delayed by either side. If those are not in the original agreement, the negotiating position at transfer time is weak — the partner holds the operational knowledge and the relationships.
The second failure mode is cultural. A center run for two years under a partner's management system develops that partner's ways of working. Transfer is not complete when the entity changes hands; it is complete when the center operates as part of your organization, and that takes deliberate design during the operate phase, not after it.
A defensible way to reach the decision
- 01
Segment the work portfolio
Classify each work stream by criticality, definability and volatility before considering any model.
- 02
Set the control requirement per segment
Decide what must be under direct employment and what can sit with a partner under contract.
- 03
Test against management capacity
Confirm the senior time a captive core requires is genuinely committed, in named people with reallocated priorities.
- 04
Model the cost curves side by side
Compare models over the same horizon, including transfer consideration and exit cost — not just year-one spend.
- 05
Design the transition and exit before signing
Whatever the model, the terms under which capability moves in or out should exist in writing on day one.
NirjiX view
Our view: choose per work stream, and design the exit before you need it
Enterprises that treat this as a single enterprise-wide choice tend to over-build captive capacity for work that was never strategic, or hand a partner work that quietly becomes the core of their engineering capability.
Hybrid is the pragmatic outcome for most organizations at scale, but it only works when the boundary is drawn by criticality rather than by convenience, and when governance is designed for two delivery modes rather than bolted on afterwards.
Whichever model you choose, write down what would make you change it and what changing would cost. An operating model that cannot be exited is not a model — it is a dependency, and dependencies are repriced by the party that holds them.
Frequently asked executive questions
- Captive vs BOT vs managed GCC: which model is best?
- There is no universally best model — the right one follows from how strategic the work is, how quickly you must start, and how much operating risk you can hold. Captive suits work that is core, long-lived and worth owning outright; build-operate-transfer suits organizations that want eventual ownership without absorbing early setup risk; managed suits scoped, non-core capacity where speed matters more than control. Hybrids are common and legitimate: own the differentiated work, contract the rest.
- Is a captive GCC always cheaper at scale?
- Often, but not automatically. Marginal cost per role is usually lower once a captive is at scale, and that advantage can be erased by low utilization, slow ramp, high attrition or governance overhead that was never costed. The comparison should be run on your own volumes and ramp, over the same horizon for every model.
- How long does a BOT transfer typically take?
- Commonly two to four years from build start to transfer, though the operative constraint is contractual rather than technical. The transfer window, trigger conditions and pricing formula should be defined in the original agreement; negotiating them later is where most value is lost.
- Can we start managed and convert to captive later?
- Yes, and many organizations do — but only if the contract anticipates it. Rights over people, processes, tooling and data at conversion need to be explicit from the outset. Without them, conversion means rebuilding capability rather than transferring it.
- What governance does a hybrid model require?
- A single accountable owner for the whole capability, one performance framework covering both modes, clear boundaries on which decisions sit inside the captive core, and a shared architecture and security standard. Running two governance systems side by side is the most common reason hybrids underperform.
- How does an AI-native design change the operating model choice?
- It usually strengthens the case for owning the core. When AI capability, proprietary data and evaluation are central to how the work is done, that layer belongs under direct control even if surrounding delivery is partnered. It also changes role mix and seniority, which should be reflected in the business case for each model.
Decide next
Related decisions
- 01 · GCC decisionGCC business caseBuilding a capability-center case that survives finance review rather than a cost slide.
- 02 · GCC decisionGCC setup roadmapThe realistic sequence from decision to a functioning center, and where timelines slip.
- 03 · GCC decisionGCC location strategyChoosing a city on talent depth, wage trajectory and competitive density, not brochures.
- 04 · GCC decisionGCC talent and attritionWhat actually holds a capability center together once the first hiring wave lands.
Continue
Related intelligence
- DecisionGCC business caseHow to build a case that survives finance review, modelled against your chosen model.
- PortalGCC feasibility assessmentTest intent, work portability, talent, governance and cost before choosing a model.
- ServicesGCC engagement modelsHow NirjiX engages across each model, with comparison tooling and cost calculators.
- PortalBuild your GCC blueprintTurn the chosen model into an execution blueprint with structure, roles and sequencing.
- DecisionAI build vs rentThe same ownership logic applied to AI capability rather than delivery capacity.
- HubGCC consulting hubFeasibility, business case, operating model, blueprint and advisor review in one path.
Transparency
Sources and methodology
This page reflects NirjiX practitioner experience designing, costing and standing up capability centers in India, and the same modelling logic used in the NirjiX GCC business case builder and blueprint.
We do not publish generic per-seat or per-FTE benchmarks as if they were universal. Compensation, real estate, statutory cost and attrition vary materially by city, role mix, seniority and hiring speed, and a business case built on an averaged benchmark is usually wrong in both directions at once.
The models we build with clients use your own baseline cost, your own role mix and your own ramp assumptions, then stress-test them with sensitivity ranges rather than presenting a single deterministic number.
Decide the model against your own work portfolio
The GCC assessment segments your work by criticality and portability, then the blueprint translates the chosen model into structure, roles and a sequenced plan.
Outputs are preliminary and intended for advisor validation before commercial commitment.