There is a gap in almost every corporate travel platform that everyone in the industry knows about and nobody has closed. A business traveller books a transatlantic flight through the OBT, checks into a hotel through the OBT, and then spends the next three days getting between sites using Uber on their personal card, a contactless tap on a metro they barely understood, and a taxi receipt they will argue about with finance for six weeks. The flight and the hotel are managed. Everything else is a black hole.
The instinct to close this gap by integrating Mobility as a Service into the OBT is correct. The typical proposal stops too early. It focuses on business trip ground transport and misses the larger strategic opportunity sitting directly adjacent to it: the daily commute.
If an OBT can become the platform an employee uses not just when they travel for work, but every single morning when they tap into the metro, it has transformed from a procurement tool into a daily utility. That transformation changes the switching cost calculus entirely, changes the engagement profile fundamentally, and changes the competitive position of the platform in ways that ground transport integration alone cannot achieve.
This is the case for building both, in the right sequence, for the right reasons.
The Problem, Stated Precisely
Ground transport in corporate travel fails in three distinct ways, and they require different interventions.
The visibility problem. Ground transport spend is largely unmanaged. Ride-hailing, taxis, public transit, and rental cars are booked outside the OBT and submitted as expenses after the fact. Finance cannot see the cost until the trip is over. Policy cannot be enforced at the point of booking. Carbon data is incomplete or estimated. The travel manager's dashboard shows sixty percent of the trip; the rest is reconstructed from crumpled receipts.
The friction problem. A business traveller navigating an unfamiliar city after a long-haul flight, running late for a client meeting, should not have to figure out which app works locally, whether their corporate card will be accepted, and how to get a compliant receipt from a bike-share kiosk. The OBT, which has the itinerary context, the corporate policy, and the payment infrastructure, contributes nothing to solving this moment.
The leakage problem. Because ground transport is unmanaged, it is expensive. Travellers default to the most convenient option, not the most cost-effective or policy-compliant one. Without visibility at the point of booking, the travel manager has no mechanism to steer behaviour, and policy enforcement is retrospective, which means it is largely ineffective.
These three problems affect business travel ground transport. There is a fourth problem that sits adjacent to them and is even less managed.
The commute opacity problem. Most companies offer some form of transport benefit for employees' daily commute: a travel allowance, a season ticket loan, a tax-advantaged mobility budget, a metro pass subsidy. These benefits are administered through HR, paid through payroll, and almost never integrated with the corporate travel platform. The result is that the same company managing its business travel spend carefully has zero visibility into how its commute benefit is being used, whether it is being used at all, and whether employees are making choices that align with the company's carbon commitments or flexible work policies.
A platform that solves only the first three problems is a better OBT. A platform that solves all four is something qualitatively different: a unified corporate mobility layer that sits at the intersection of travel management, HR benefits, and finance operations. The switching cost implications of that position are significant, and the strategic logic for pursuing it deserves careful examination.
The Daily Commute Proposal: What It Actually Is
Before evaluating whether to build it, the feature needs to be defined precisely, because "commute integration" covers a wide range of product choices with very different build costs, regulatory requirements, and strategic value.
At its simplest, commute integration means the OBT app can load a corporate mobility budget onto a virtual card that the employee uses for daily transport. The employee taps their phone on the metro, the transaction is charged to the corporate mobility wallet, and the finance team sees the spend in real time without anyone submitting an expense report.
At its most ambitious, it means the OBT issues or integrates with physical and digital transit passes for specific networks, manages city-specific monthly subscriptions, handles tax-advantaged allowance administration by jurisdiction, integrates with bike-share and e-scooter schemes, and provides the employer with utilisation dashboards that show whether employees are using their benefits and which transport modes they prefer.
The strategic case for the simpler version is strong and the build is manageable. The strategic case for the ambitious version requires navigating regulatory complexity that varies significantly by country and competing with HR benefits platforms that have spent years building exactly these integrations. Both are worth examining.
Why the Daily Commute Is Strategically Undervalued by OBTs
The fundamental reason OBTs have not pursued commute integration is a category assumption: OBTs are for business travel, HR platforms are for employee benefits, and these are separate procurement decisions made by separate buyers.
This assumption is increasingly incorrect, and the platforms that recognise it first will capture a position that is very difficult for latecomers to displace.
Consider the engagement arithmetic. A business traveller who takes twelve trips per year interacts with the OBT maybe forty to sixty times annually, counting searches, bookings, and expense submissions. An employee who uses a corporate mobility budget for their daily commute interacts with the platform two hundred and fifty times per year, minimum. The daily commute is not a niche use case grafted onto a travel platform. It is a use case with five to six times the interaction frequency of the core product.
High-frequency daily use creates three compounding advantages that business-travel-only OBTs do not have.
Habit and muscle memory. An app that an employee opens every morning to tap into the metro becomes a reflex. It lives on the home screen. It is the first transport app opened when the employee also needs to book a ride-share for a client meeting, because it is already the transport app they trust. Consumer behaviour research is consistent on this point: the app that captures daily routine use captures all adjacent use cases by default.
Richer behavioural data. Daily commute data combined with business travel data produces a mobility profile for each employee that no other platform can construct. The OBT knows not just that an employee flies to Munich four times a year, but that they prefer rail for distances under three hours, that they are a morning commuter who takes the metro rather than a bus, and that they consistently choose the faster option over the cheaper one. This profile makes every AI recommendation better and makes the platform more personally valuable the longer it is used.
Structural switching costs at the employee level, not just the company level. This is the most important strategic implication. Standard OBT switching costs are corporate: retraining staff, re-integrating with HR and ERP systems, renegotiating supplier contracts. These are real but they are felt by the procurement team and the travel manager. Daily commute integration creates switching costs at the individual employee level: their transit pass history, their preferred route shortcuts, their accumulated mobility budget balance, their bike-share subscription, all live in the platform. Migrating away means every employee loses their transport setup and has to reconstruct it. That is a switching cost that the road warrior, the office employee, and the CFO all feel simultaneously, and it is qualitatively different from any switching cost a business-travel-only OBT can create.
The Critical Evaluation: What the Standard Proposal Gets Wrong
The strategic logic above is sound. The execution risks are significant, and a proposal that does not address them honestly is not a product strategy; it is a product vision.
Risk one: the buyer mismatch. Business travel is bought by procurement and finance. Employee commute benefits are bought by HR. These are different buyers with different evaluation criteria, different budget cycles, and different relationships with vendors. An OBT that proposes to own the commute benefit is asking HR to share or cede a product category they currently control. This is a political and commercial negotiation, not a product decision. The go-to-market strategy must account for how the OBT reaches HR buyers, which relationships it builds, and how it positions itself as a complement to existing HR platforms rather than a replacement for them.
The risk of ignoring this is real: a company that has already deployed a dedicated mobility benefit platform like Cobee, Swile, or Benefex is not going to rip it out to consolidate on an OBT, regardless of how elegant the integration proposal looks. The OBT needs a strategy for markets where these platforms already exist, and a strategy for winning the unoccupied territory before they expand into it.
Risk two: regulatory complexity is not a feature, it is a prerequisite. Commute benefit tax treatment varies materially by jurisdiction. In Germany, the Mobilitätsbudget has specific tax exemption rules under EStG that require employer declaration procedures. In India, transport allowances and leave travel allowances have income tax implications that differ between salaried and non-salaried employees and are subject to CBDT interpretation. In the UK, season ticket loans, Cycle to Work schemes, and tax-free public transport benefits each have distinct HMRC rules. In France, the Forfait Mobilités Durables has specific eligible modes and caps.
A mobility budget feature that does not handle these jurisdictional rules correctly is a tax compliance liability, not a product benefit. Building it correctly requires country-by-country tax rule libraries, employer declaration workflows, and ongoing maintenance as tax policy changes. This is not engineering work; it is compliance work, and it needs to be scoped as such.
Risk three: daily commute data is more sensitive than business travel data. Home-to-work routing data reveals where employees live. Under GDPR in Europe and equivalent frameworks in other jurisdictions, home address is sensitive personal data that requires explicit consent for collection, strict access controls, and clear retention and deletion policies. An OBT that processes daily commute data needs a data governance framework that is materially more rigorous than the one required for business travel itineraries. This is not an insurmountable problem. It is a problem that needs to be designed into the product from day one, not retrofitted after launch.
Risk four: the frequency advantage is also a quality threshold. An app used twice a year can have occasional reliability issues and users will tolerate it. An app used twice a day, every working day, has a quality bar that is orders of magnitude higher. A failed transit ticket at 8am when an employee is trying to get to work is not a minor UX problem; it is a trust-destroying event that generates immediate HR escalations and internal advocacy against the platform. The daily commute feature ships only when the infrastructure behind it has demonstrated the reliability required for mission-critical daily use. Launching before that threshold is met is strategically worse than not launching at all.
Does Commute Integration Actually Increase Switching Costs? The Honest Assessment
The switching cost argument is the central strategic claim for this feature. It deserves rigorous examination rather than assertion.
Switching costs are real when they involve one or more of three mechanisms: data that cannot easily be migrated, integrations that are expensive to rebuild, or habits that are expensive to change. Commute integration creates all three, but the strength of each depends on implementation choices.
Data switching costs. If the platform holds eighteen months of an employee's commute history, their preferred routes, their transit pass configuration, and their mobility budget balance and transaction history, that data has genuine personal value. It informs the platform's recommendations and is referenced when employees make claims or queries. Migrating it to a new platform requires the employer to export it, the new platform to import it, and every employee to reconstruct their personal settings. This is a real switching cost, but its magnitude depends on how deeply the platform integrates with each employee's transport setup. A virtual card that charges a generic mobility budget creates weak data switching costs. A platform that holds the employee's actual transit pass, monthly subscription, and route preferences creates strong ones.
Integration switching costs. The OBT's commute feature is integrated with the employer's HR system for budget allocation, the finance system for spend reporting, and potentially the payroll system for tax-advantaged benefit administration. Each of these integrations takes weeks to months to build and requires IT and finance involvement to maintain. When the employer considers switching OBT, they are not just switching a booking tool; they are re-doing all of these integrations. This is the same class of switching cost that SAP Concur has exploited for years, and it applies equally to a commute-integrated OBT. The depth of the integration determines the strength of the cost.
Habit switching costs. This is the most underappreciated switching cost mechanism and potentially the most durable. A platform that an employee opens every morning becomes the default transport app for every other transport decision during the day. When a colleague asks which app to use for the airport transfer, the answer is the one already on the home screen. Habit is the switching cost that does not appear in a procurement analysis but determines actual platform stickiness at the user level. It compounds over time and it is not transferable.
The honest conclusion is that commute integration does meaningfully increase switching costs, but the magnitude depends on implementation depth. A thin implementation, essentially a corporate virtual card for transit spend, creates moderate switching costs primarily through integration. A deep implementation, holding transit passes, managing subscriptions, personalising routes, and administering tax-advantaged allowances, creates strong switching costs through data, integration, and habit simultaneously. The strategic case for deep implementation is strong. The build cost and regulatory complexity of deep implementation are correspondingly higher.
A Revised Product Architecture: Three Phases Across Two Use Cases
The product should be built in three phases that develop both the business travel ground transport capability and the daily commute capability in parallel, sharing infrastructure and progressively deepening switching costs.
Phase One: The Corporate Mobility Wallet
The first phase establishes the foundational infrastructure that serves both use cases. The corporate mobility wallet is a virtual payment instrument, issued per employee, that works across all ground transport providers integrated with the platform. Business travel ground transport and daily commute transport use the same wallet. The employer configures separate budget pools: a travel programme budget for business trip ground transport, and a mobility benefit budget for daily commute.
The wallet captures every transaction automatically, categorises it by trip context, extracts GST or VAT where applicable, and closes the expense loop without employee action. For the employer, this means zero manual expense processing for ground transport. For the employee, it means no personal card exposure, no receipt collection, and no expense report for any ground transport.
This phase does not require deep transit integration. It requires a corporate card infrastructure, a virtual credential issuance capability, and connections to ride-hailing aggregators for the highest-volume transport use case. Metro ticketing and subscription management follow in phase two; the wallet infrastructure is the prerequisite for all of it.
The key metric in phase one is ground transport capture rate: the percentage of a company's total ground transport spend, across both business travel and commute, that flows through the wallet versus submitted as after-the-fact expenses. A company moving from near-zero to sixty percent capture has delivered transformational compliance value before a single route algorithm is written.
Phase Two: Transit Integration and Mobility Budget Management
Phase two adds the integrations that make the wallet useful for structured daily commute benefits. This means integrating with major transit networks in the employer's key office locations, enabling digital ticketing through the OBT app, and building the mobility budget management layer that allows HR to configure allowance rules, tax treatment by jurisdiction, and eligible transport modes.
Transit integration should be prioritised ruthlessly. The business case does not require integration with every city's public transport system simultaneously. It requires integration with the transit networks that serve the employer's primary office locations. A company with major offices in London, Singapore, and Mumbai needs Oyster and contactless TfL integration, EZ-Link integration, and Mumbai Metro integration. Everything else is a roadmap item. Starting with three cities and getting them right is more valuable than attempting twenty cities and getting them inconsistently.
The mobility budget management layer is where the regulatory complexity lives. The build requirement here is a jurisdiction-specific rule library that determines how each allowance type is treated for tax purposes, what documentation the employer needs to maintain, and what reporting obligations apply. This layer should be designed to be updateable without engineering involvement, because tax rules change and a platform that requires a code deployment every time the HMRC updates its guidance is a compliance liability.
The employer-facing dashboard built in this phase shows utilisation by employee, by transport mode, by office location, and against carbon targets. This is the data that changes the relationship with the HR and finance buyer: they are no longer administering a benefit blindly. They can see whether the commute subsidy is being used, which modes employees prefer, and whether the benefit is influencing carbon outcomes. That visibility is genuinely new and genuinely valuable.
Phase Three: Personalised Ambient Assistance
Phase three layers intelligence on top of the infrastructure built in phases one and two. By this point the platform has transaction history for both business travel and daily commute, integration with the employee's regular transit networks, and a policy profile for the employer. The personalisation available from this dataset is qualitatively different from what any business-travel-only OBT can offer.
The ambient assistance in this phase operates at two levels.
For business travel, the platform knows the employee's preferred transport modes from their commute behaviour, not just their travel history. It knows they take rail when journey time is under two hours. It knows they prefer a specific class of hotel because their commute patterns indicate they are willing to trade convenience for cost savings during the week but not on weekends. The recommendations are more accurate because the dataset is richer.
For daily commute, the platform can detect when an employee is travelling to an office other than their usual location, suggest the most efficient route from their current starting point, alert them to service disruptions on their regular route before they leave, and adjust budget allocation automatically when the employer has temporary office relocations or flexible work events.
The contextual integration between business travel and daily commute is where the platform becomes genuinely difficult to replicate. No standalone OBT has commute data. No standalone HR benefits platform has business travel data. The platform that holds both has a dataset that neither can construct, and the AI trained on that combined dataset makes recommendations that neither competitor can match.
The Competitive Threat: HR Benefits Platforms Are Moving Toward Travel
The commute integration proposal must be evaluated against the competitive landscape it creates. The OBT is not the only platform with ambitions in corporate mobility.
Cobee, operating in Spain and expanding across Europe, offers employees a flexible benefits wallet covering transport, meals, health, and training, with tax-advantaged treatment per local rules. Swile in France operates across transport benefits, meal vouchers, and gift cards. Benefex in the UK offers a benefits platform that includes commute support. These are not travel companies. They are HR tech companies that are expanding into adjacent benefit categories.
The OBT competing in this space is entering a market where HR benefits platforms are well-established with HR buyers, have deep local regulatory knowledge, and have existing payroll and HRIS integrations that the OBT will need to build from scratch. The OBT's advantage is its business travel data and its finance buyer relationships. Its disadvantage is everything to do with HR procurement and employee benefits administration.
The strategic positioning that addresses this is not "we replace your benefits platform." It is "we integrate with your benefits platform to connect commute benefits with travel policy in ways neither system can do alone." A partnership strategy with Cobee, Benefex, or Swile is a more viable path to commute integration in markets where these platforms are established than a direct competitive entry. The OBT provides the travel context and the finance integration; the benefits platform provides the local regulatory compliance and the HR buyer relationship.
In markets where these platforms are not established, primarily high-growth markets in South and Southeast Asia where the mobility benefits category is less mature, the OBT has an opportunity to enter directly and build the category before dedicated competitors arrive. The Indian market, where HRA and transport allowances are administered through payroll but rarely through a purpose-built mobility platform, is an example of unoccupied territory where an OBT with the right compliance infrastructure could establish a position before the HR tech stack catches up.
The Revenue Architecture for the Unified Mobility Layer
A unified mobility platform serving both business travel and daily commute has a more defensible revenue architecture than a travel-only OBT, because it has higher transaction frequency, more persistent employer relationships, and multiple buyer relationships within the same company.
Platform subscription per enrolled employee, covering both business travel and commute functionality. This is priced against the operational cost it replaces: manual expense processing, HR benefit administration overhead, and compliance management time. A company that enrols five hundred employees on a unified mobility platform is paying for a capability that reduces headcount in both finance and HR operations. The pricing should reflect both savings, not just the travel management component.
Transaction fee on ground transport bookings, structured as a distribution cost paid by transport providers rather than a booking fee charged to the employer. This is lower per transaction than air and hotel distribution fees, but daily commute transactions at two hundred and fifty per employee per year generate substantially higher volume than the twelve to fifteen business trips per year that currently define the OBT transaction base.
Mobility budget administration fee for the tax-advantaged allowance management capability. Employers pay for the compliance infrastructure: the jurisdiction-specific rule library, the payroll reporting, the audit trail documentation. This is priced as a percentage of total mobility budget administered, comparable to the way payroll providers charge for benefits administration.
Benchmarking and analytics as a premium tier. Anonymised and aggregated across the client base, commute and travel data enables benchmarking that no individual employer can generate: average commute subsidy utilisation by industry, modal shift rates in response to benefit structure changes, carbon intensity per journey type by city. Large enterprise clients with sustainability commitments will pay for this data, and it deepens the relationship beyond the transaction.
What Not to Build, and the Sequencing Discipline That Matters
Scope discipline is as important as scope ambition in a product of this complexity.
The platform should not attempt to replace the consumer transit apps that employees use for navigation. Google Maps, Citymapper, and local equivalents do real-time routing better than any OBT will. The platform's routing capability should be limited to policy-aware mode suggestion at trip planning time, not turn-by-turn navigation.
The platform should not attempt to administer physical transit cards directly in phase one or two. Virtual payment credentials that work at NFC terminals are sufficient for the majority of transit networks and are significantly easier to issue, manage, and cancel than integrating with each city's card issuance infrastructure. Physical card integration is a phase three consideration for the highest-volume markets where virtual credentials are not yet universally accepted.
The commute feature should not launch in markets where the regulatory compliance infrastructure is not complete. A mobility budget feature that mishandles tax-advantaged allowance treatment is worse than no mobility budget feature. The employer bears the tax liability, and a single compliance failure in a high-profile client creates reputational damage that takes years to recover from.
The correct sequencing is: wallet infrastructure first, highest-volume transit integrations second, regulatory compliance by jurisdiction third, personalisation and ambient assistance fourth. This sequence means the platform ships something valuable in each phase rather than waiting eighteen months for the full vision to be complete before any customer sees it.
Conclusion: The Platform That Earns Daily Relevance
The ground transport gap in corporate travel is a real and solvable problem. The daily commute gap in corporate mobility benefits is a related but distinct problem that has been overlooked by OBTs because it sits in HR's territory rather than finance's territory.
The platform that chooses to solve both simultaneously is not building two features. It is building a unified corporate mobility layer that holds the employee's complete transport relationship with their employer: the flight to the client meeting, the ground transport between sites, and the daily commute home. That platform has daily engagement rather than occasional engagement, employee-level switching costs rather than only corporate-level switching costs, and a dataset that no travel-only or HR-only platform can construct.
The switching cost argument is real. It is strongest when the implementation is deep: when the platform holds the transit pass, manages the subscription, administers the tax allowance, and personalises routes based on eighteen months of combined travel and commute history. A thin implementation creates moderate switching costs. A deep implementation creates the kind of switching costs that make renewal a formality rather than a negotiation.
The risk of pursuing this is also real: regulatory complexity, HR buyer politics, quality thresholds that are higher than business travel, and competitive pressure from HR benefits platforms with a head start in their home markets. None of these risks are disqualifying. All of them require deliberate product and go-to-market decisions that most product proposals do not make.
The OBT that becomes the app an employee opens every morning has earned a position that the OBT used only for quarterly business trips will never hold. That position is worth building toward, carefully and in the right sequence.