Captive, BOT, Managed or Hybrid? Choosing the Right GCC Operating Model

The operating model decision

Enterprises deciding to build global capability face an immediate structural question: how should the center be established, governed, and operated?

This is not merely an administrative choice. The operating model determines who owns the intellectual property, how quickly the center becomes productive, what happens if the strategy changes, how talent is attracted and retained, and ultimately whether the center delivers strategic value or becomes an expensive liability.

Six distinct operating models exist in practice. Each represents a different position on the spectrum between full control and full delegation.

Model 1: Wholly Owned Subsidiary (Captive GCC)

How it works

The enterprise forms a legal entity in the target country (typically a Private Limited Company in India), leases or purchases office space, establishes all operational infrastructure, recruits directly, and manages the center as a fully owned subsidiary.

Characteristics

• Ownership: 100% enterprise-owned
• Legal structure: Separate legal entity, typically wholly owned subsidiary
• Governance: Direct board control, enterprise-appointed leadership
• Talent: Employed directly by the subsidiary
• IP: Fully owned by the enterprise
• Infrastructure: Enterprise-procured and managed
• Timeline to operational: 9–18 months
• Setup investment: $5–20M+ depending on scale

When to choose captive

• The enterprise requires absolute control over IP-sensitive work
• Long-term commitment (5+ years) is certain
• Target scale exceeds 200–300 people
• The enterprise has experience operating in the target country
• Regulatory requirements mandate direct entity presence
• The parent company brand attracts top talent locally

Strengths

• Maximum control over strategy, operations, and culture
• Full IP ownership with no contractual ambiguity
• Complete data sovereignty
• Strongest talent retention (direct employment, career paths, equity participation)
• No third-party dependencies
• Long-term cost optimization at scale

Weaknesses

• Highest setup cost and longest launch timeline
• Requires management expertise in foreign operations
• All operational risk borne by the enterprise
• Inflexible if strategy changes (stranded assets, severance obligations)
• Distraction from core business during setup phase
• Requires learning local labor law, compliance, and operational norms

Model 2: Build-Operate-Transfer (BOT)

How it works

A specialist partner establishes the center on behalf of the enterprise — forming the entity (or using their own), fitting out the facility, recruiting the initial team, operationalizing workflows, and managing day-to-day operations during a "build" phase. After a defined period (typically 18–36 months), ownership transfers to the enterprise.

Characteristics

• Ownership: Partner-owned during build phase, transfers to enterprise
• Legal structure: Initially partner entity, transitions to enterprise entity
• Governance: Joint governance during build, enterprise governance post-transfer
• Talent: Initially partner-employed, transition to enterprise employment
• IP: Enterprise-owned from day one (contractually enforced)
• Infrastructure: Partner-procured, enterprise-transferred
• Timeline to operational: 3–6 months (significantly faster than captive)
• Setup investment: Partner-funded initially, repaid through fees + transfer premium

When to choose BOT

• Speed to market is critical (need operational team within 3–6 months)
• The enterprise lacks experience in the target country
• Risk mitigation during the critical first 18 months is valued
• Management bandwidth to set up a GCC is unavailable
• The enterprise wants proven processes before taking ownership
• Initial scale is 50–200 people (the BOT sweet spot)

Strengths

• Dramatically faster launch (3–6 months vs 9–18 months)
• Partner absorbs setup risk and operational learning curve
• Enterprise avoids distraction during the build phase
• Partner brings recruitment networks and local expertise
• Proven team and processes at point of transfer
• Deferred CapEx (spread across build period fees)

Weaknesses

• Transfer premium (typically 3–6 months of operating cost)
• Risk of cultural misalignment during build phase
• Partner's recruitment quality may not match enterprise standards
• Transfer process itself is disruptive (legal, HR, facilities transitions)
• Dependency on partner during build phase
• Contractual complexity around IP, non-compete, and team retention post-transfer

Transfer risks

The transfer phase is where BOT models most frequently fail:

• Talent attrition: 15–30% of staff may leave during or immediately after transfer due to uncertainty, changed benefits, or partner counter-offers
• Knowledge loss: Undocumented processes and relationships that existed informally during partner management
• Infrastructure gaps: Systems, tools, and vendor relationships that were partner-managed and not clearly documented
• Cultural shift: Team accustomed to partner's management style may resist enterprise norms

Mitigation: Enterprise involvement from day one in hiring decisions, culture-building, and relationship development — even during the "partner-operated" phase.

Model 3: Managed GCC

How it works

An operator provides the shell infrastructure — workspace, technology, compliance, HR administration, facilities management — while the enterprise retains full control over the technical team, work allocation, delivery, and intellectual property. The team works exclusively for the enterprise but is administratively supported by the managed services provider.

Characteristics

• Ownership: Enterprise controls work; provider manages infrastructure
• Legal structure: Provider employs staff (EOR model) or enterprise entity with managed services
• Governance: Enterprise governs work; provider governs operations
• Talent: Reports functionally to enterprise, administratively to provider
• IP: Enterprise-owned (contractually)
• Infrastructure: Provider-managed, enterprise-specified
• Timeline to operational: 4–8 weeks (fastest model)
• Setup investment: Minimal ($100K–$500K)

When to choose managed

• Speed is the primary requirement (operational within weeks)
• Scale is small to medium (20–150 people)
• The enterprise wants to validate the GCC thesis before committing to full ownership
• Administrative overhead is undesirable
• Flexibility to scale up/down rapidly is valued
• The enterprise prefers OpEx over CapEx

Strengths

• Fastest time to operational (4–8 weeks)
• Lowest setup investment
• Maximum operational flexibility (scale up/down without asset commitment)
• No legal entity required initially
• Provider handles compliance, payroll, benefits, facilities
• Enterprise focuses entirely on capability delivery

Weaknesses

• Less control over operational environment
• Provider dependency for administrative functions
• Staff may feel less connected to enterprise (dual employment psychology)
• Higher per-person cost than captive at scale (provider margin)
• Limited ability to customize physical environment
• Potential data handling concerns with provider infrastructure

Model 4: Hybrid GCC

How it works

The enterprise owns and directly manages core IP-generating functions (engineering, R&D, product development) while outsourcing or managing peripheral operations through providers. Multiple models coexist within a single GCC operation.

Characteristics

• Ownership: Mixed — core captive, periphery managed or outsourced
• Legal structure: Enterprise entity for core, provider arrangements for periphery
• Governance: Direct governance for core, contractual governance for periphery
• Talent: Mixed employment — enterprise direct + provider-managed
• IP: Core IP enterprise-owned; peripheral services contracted
• Timeline: Staged — core captive first, periphery added as needed
• Setup investment: Moderate ($2–8M for core, managed services for periphery)

When to choose hybrid

• The enterprise has clear distinction between core and peripheral activities
• Some functions are commoditized (facilities, basic testing, operations) while others are strategic (architecture, AI, product)
• Budget constraints prevent full captive at desired total scale
• The enterprise wants operational flexibility on non-core functions
• Regulatory requirements differ by function (e.g., data processing vs engineering)

Strengths

• Optimizes cost by matching investment level to strategic importance
• Flexibility on peripheral functions without compromising core control
• Enables faster scaling of non-core functions through provider capacity
• Core team benefits from captive stability; peripheral team from provider efficiency
• Risk diversification across models

Weaknesses

• Governance complexity (multiple models, multiple relationships)
• Cultural divisions between captive and managed staff
• Integration overhead at boundaries between models
• Contract management for peripheral providers
• Potential IP leakage at model boundaries

Model 5: Outsourced (Benchmark)

How it works

The enterprise contracts with a service provider (IT services firm, consulting company, or specialized delivery partner) to deliver defined outcomes. The provider employs the staff, manages the operations, and delivers against SLAs.

Characteristics

• Ownership: Provider-owned entirely
• Talent: Provider employees; may rotate across clients
• IP: Negotiated — often shared or requires explicit assignment
• Control: Limited to contractual SLAs
• Timeline: 2–4 weeks (fastest, but limited initial quality)
• Investment: Minimal (contract execution costs only)

When outsourcing is appropriate (instead of GCC)

• Work is truly commoditized with no IP differentiation
• Engagement is short-term (< 18 months)
• Volume fluctuates dramatically and unpredictably
• The enterprise lacks management bandwidth for any level of direct operation
• Cost is the sole decision criterion

Why enterprises move from outsourcing to GCC

• IP ownership requirements increase as work becomes more strategic
• Knowledge loss during provider transitions becomes commercially damaging
• Quality variability across provider staff rotations is unacceptable
• Provider margins (30–50%) become unjustifiable at sustained scale
• Strategic alignment between enterprise goals and provider incentives diverges

Model 6: Virtual-First (Emerging)

How it works

The enterprise assembles GCC capability — talent, infrastructure, AI systems, governance — through a digital-first model that does not begin with physical infrastructure. Distributed talent works through cloud workbenches, AI platforms, and governed execution environments. Physical consolidation follows only if and when required.

Characteristics

• Ownership: Enterprise controls capability, platform, and IP
• Physical infrastructure: Minimal or none initially
• Talent: Distributed (may be co-located later if valuable)
• Technology: Cloud workbenches, AI agents, managed compute, governance platforms
• IP: Enterprise-owned through platform and contractual controls
• Timeline: 2–4 weeks to initial capability
• Investment: Platform subscription + talent costs (minimal CapEx)

When to consider virtual-first

• The work is primarily digital (software, AI, data, analytics, design)
• Speed to capability matters more than physical presence
• The enterprise wants to validate capability before investing in facilities
• Talent can be distributed without quality degradation
• AI and automation can substitute for some of the scale that physical co-location traditionally provided
• The enterprise is exploring whether a traditional GCC is needed at all

Strengths

• Fastest path to capability (days to weeks)
• Lowest investment (no facilities, no entity initially)
• Maximum flexibility (scale, change, or exit without stranded assets)
• Access to distributed talent (not limited to single city)
• AI-native from inception
• Natural evolution path: virtual → micro-GCC → full GCC if justified

Limitations

• Unproven at large scale for complex R&D
• Regulatory uncertainty in some jurisdictions
• Cultural and collaboration challenges for complex coordination
• May not satisfy enterprise stakeholders who expect physical presence
• Dependent on platform capability and reliability

The decision framework

Choosing the right model requires evaluating multiple dimensions simultaneously:

Factor	Captive	BOT	Managed	Hybrid	Outsource	Virtual
Control	Maximum	High (post-transfer)	High (functional)	Mixed	Low	High (platform)
Speed	Slow (9-18mo)	Medium (3-6mo)	Fast (4-8wk)	Medium	Fastest	Fast (2-4wk)
Investment	Highest	Medium	Low	Medium	Lowest	Low
IP security	Maximum	High	High	Mixed	Negotiated	High
Talent retention	Strong	Moderate (transfer risk)	Moderate	Mixed	Weak	Moderate
Flexibility	Low	Low post-transfer	High	Medium	High	Maximum
Scalability	High (with investment)	Medium	High	High	High	High
Risk	All internal	Shared → internal	Shared	Mixed	External	Platform-dependent
Long-term cost	Lowest at scale	Medium	Medium	Varies	Highest	TBD
Governance complexity	Low	Medium (during transition)	Low	High	Low	Medium

Decision triggers

Choose captive when:

• IP is crown-jewel (AI models, core algorithms, proprietary systems)
• Committed to 500+ people within 3 years
• Enterprise has global operations experience
• 5+ year time horizon with certainty
• Regulatory requires direct entity presence

Choose BOT when:

• Speed matters but so does eventual full ownership
• Enterprise lacks local operational experience
• 100–500 person target within 2 years
• Risk mitigation during setup is valued
• Budget allows for transfer premium

Choose managed when:

• Team size is 20–150 people
• Validation before commitment is the priority
• Administrative overhead is unacceptable
• Operational within weeks is required
• Enterprise prefers pure OpEx model

Choose hybrid when:

• Clear core/periphery distinction exists
• Multiple functional types with different strategic value
• Budget constrains full captive but requires core ownership
• Flexibility on non-strategic functions is important

Choose virtual-first when:

• Work is digital-native and AI-augmentable
• Speed to capability exceeds all other priorities
• Physical presence is not a stakeholder requirement
• Enterprise wants to prove value before investing in infrastructure
• The question is "do we need a GCC at all?" and the answer needs testing

The evolution path

Most successful GCC journeys are not single-model commitments. They are progressions:

Path A (Traditional): Outsource → BOT → Captive The enterprise validates the work offshore through outsourcing, then establishes ownership through BOT, then operates as full captive.

Path B (Modern accelerated): Managed → Captive (or Managed → Hybrid) Skip the outsourcing phase. Start with managed model for speed. Transition to captive once scale and commitment justify entity formation.

Path C (Digital-first): Virtual → Managed → Micro-GCC → Captive Start with platform capability. Add managed talent. Consolidate into a physical Micro-GCC. Scale to full captive if the business case holds.

Path D (Hybrid steady-state): Captive core + Managed periphery (permanent) Some enterprises find that hybrid is not a transition state but the optimal permanent model — owning what is strategic, managing what is operational.

The best operating model is the one that matches your current maturity, risk tolerance, and capability requirements — while preserving optionality to evolve as conditions change.

---

This is Part 5 of the Global Capability Centers thought leadership series. Previous: The Rise of the Micro-GCC. Next: Where Should You Build Your GCC in India?.