Brand identity
Configured per programmeLogo, colour tokens, typography and tone applied to the partner-facing surfaces in scope.
Managed by Shared
TaxiD White-Label Platform
Your Brand.
Your Customers.
Powered by TaxiD.
Launch a branded mobility experience backed by TaxiD’s booking, fulfilment, payment, settlement and reporting infrastructure. Build your customer proposition while operating through a governed platform and partner model.
You own your brand and customer relationship. TaxiD provides the mobility infrastructure within the agreed programme scope. Transport image is illustrative, not evidence of available fleet.
01
A customer experience that feels like you.
Your identity, your distribution, your customer proposition. The scope below distinguishes configurable experiences from features still on the roadmap.
Your brandIllustrative web experience · Not a live booking
YOUR NEXT JOURNEY
Where would you like to go?
Pickup · Nairobi
Destination · Airport transfer
Quote subject to admitted supply and availability
Your identity at the front.
TaxiD infrastructure underneath. Brandable surfaces are admitted and configured for your programme.
Booking experience
Configured per programmeBranded quote-and-book journey for the services admitted to the programme.
Managed by Shared
Customer portal
PartialOrder history, tracking and documents under the partner brand.
Managed by Shared
Partner Workspace
LiveOperational workspace at /partner/workspace for the partner's own staff.
Managed by TaxiD
Transactional email
Configured per programmePartner sender name and template content; authenticated sending domain is agreed during provisioning.
Managed by Shared
Receipts and invoices
Configured per programmePartner brand on documents, with statutory identifiers and tax data fixed by the issuing entity.
Managed by Shared
Custom domain
RoadmapPartner-owned hostname with DNS verification and managed TLS.
Managed by Shared
Native mobile application
RoadmapA store-published branded app is not part of the white-label programme today.
Managed by Partner
SMS sender identity
RoadmapAlphanumeric sender IDs depend on the operator and market and are arranged per programme.
Managed by Shared
Brand profiles cover logo, colours, typography, app and email identity, notification templates, legal identity and customer-facing policies—only within the admitted surface scope.
What branding can never override
- Statutory identifiers on tax documents (issuing entity, tax identity, invoice numbering).
- Safety, emergency and incident-reporting information shown to a traveller.
- The lawful basis, privacy notice and data-controller identity presented at collection.
- Security surfaces: authentication screens, credential handling and consent prompts.
- Audit, event and settlement records — branded in presentation, never in substance.
02
One connected mobility platform.
A clear path from your customer proposition to an accountable, settled and reported order.
- 01Partner
- 02Tenant configuration
- 03Branded booking
- 04Quote & order
- 05Operations & dispatch
- 06Payment
- 07Settlement
- 08Reporting
Tenant isolation, security, governance, observability and compliance span every stage.
Explore architecture, tenant boundaries and order states03
The right services. In the right markets.
Service admission and market coverage require operational approval. A programme never inherits every service or every city by default.
Mobility
- Ride-hailingConfigured per programme
Admitted per market and vehicle class.
- Airport transfersConfigured per programme
Scheduled pickups with flight reference on the order.
- Corporate mobilityConfigured per programme
Employee travel with cost-centre attribution.
- Executive chauffeurConfigured per programme
Assigned chauffeur supply, contracted per programme.
Charter
- Charter (road, air, marine)Configured per programme
Quotation-led; priced from the governed charter rate card.
Bus, van & coach · Aircraft · Helicopter · Marine
Employee & group transport
- Shuttle and staff transportConfigured per programme
Recurring routed movements agreed with operations.
Delivery & logistics
- Parcel and courier deliveryPartial
Available in Nairobi operations; other markets by agreement.
Rentals & leasing
- Car rental and self-drivePartial
Inventory-dependent; availability confirmed at quoting.
- LeasingContractual
Handled as a contracted arrangement, not as a booking flow.
Future programme scope
- School transportRoadmap
Not admitted to the white-label programme today.
Market coverage
Kenya — Nairobi
LiveFull catalogue in scope
Payments settle in KES via M-Pesa and card rails.
Kenya — Mombasa, Nakuru, Kisumu
Configured per programmeRide, transfer, charter, shuttle
Supply density confirmed before launch.
Kenya — other counties
PartialCharter and contracted movements
By agreement, with lead time on supply.
Outside Kenya
Roadmap—
No white-label availability today; expansion is assessed per market.
Coverage classifications are programme scope, not a guarantee of supply or a payment test for your tenant. Payment-rail availability must be verified before launch.
04
Trust is part of the architecture.
Documented platform controls, with roadmap items kept distinct. These labels are not a certification or an independent security assurance.
Tenant isolation
LiveScoped credentials
LiveRole-based access control
LiveWebhook signing
LiveAudit logging
LiveEncryption in transit
LiveSecrets management
LiveSandbox separation
LiveSingle sign-on for partner staff
RoadmapMulti-factor authentication
RoadmapIP allow-listing
Roadmap05
Your customer. Clearly shared responsibilities.
The operating model defines who does what. Legal accountability remains governed by the signed agreement.
Partner
Brand and creative
Marks, tone and approved customer-facing presentation.
Customer relationship
Acquisition, first-line commercial contact and retention.
Distribution
Channels, campaigns and demand generation.
TaxiD
Mobility infrastructure
Quoting, ordering, tracking, documents and the operating platform.
Fulfilment and dispatch
Supply admission, assignment and completion of journeys in scope.
Settlement infrastructure
Charge capture, statement generation and reconciliation records.
Shared
Pricing
TaxiD governs the rate structure; partner margin is contracted per programme.
Customer support
Partner takes first line; TaxiD operates mobility escalation in scope.
Governance and performance
Joint review cadence against the agreed measures.
Compliance
Each party is accountable for its own regulated obligations under the agreement.
06
A commercial model built around your programme.
Scope, markets, services, volume and integration requirements determine the agreement. Negotiated rates and contract-specific terms are not public price lists.
Implementation and setup
One-off, sized from the agreed scope of services, markets and integration work.
Contractual
Transaction fee
Per completed order, tiered by monthly volume.
Contractual
Partner margin
Applied on top of the governed rate, agreed per service and market.
Contractual
Payment terms
Settlement period and payment window fixed in the agreement.
Contractual
Minimum volumes
Where a programme carries dedicated supply or operations capacity.
Contractual
Refunds and chargebacks
Allocated by cause between partner and TaxiD under the agreement.
Contractual
Taxes
Charged and remitted by the issuing entity per Kenyan tax law.
Contractual
Support and service levels
Selected support tier and the associated response targets.
Contractual
From completed order to reconciled statement
- Completed order
- Charge
- Payment
- Fees and tax
- Settlement
- Partner statement
- Reconciliation
Only verified payments are recognised. Corrections create adjustment entries; historical ledger records are never edited.
Finance, settlement and contractual service levels07
Built for your engineering team.
The same governed API platform used by API partners. Start with scoped capabilities; keep endpoint specifications in the developer resources.
Live
API platform overview
Capability domains, endpoints, scopes and webhook catalogue.
Live
Developer console
Usage, quotas, OpenAPI versions, webhook verification, delivery log and credential rotation.
Live
API documentation
Reference material for the published surface.
Live
Developer portal
Entry point for partner engineering teams.
Live
Partner Workspace
Operational workspace for an admitted partner.
Live
TaxiD Enterprise
The enterprise proposition this programme sits inside.
Scoped credentials · Signed webhooks · Idempotency keys · Versioned OpenAPI · Tenant-scoped access
Capability evidence and compatibility contracts08
A considered path from qualification to launch.
Ten stages. Named owners. Evidence at every gate. Mandatory production-readiness stages cannot be bypassed.
01Partner qualificationTaxiD
- Entry criteria
- Application submitted with company, market and volume profile.
- Activities
- Eligibility, brand and market screening.
- Deliverables
- Qualification decision.
- Exit criteria
- Partner accepted into discovery.
- Approver
- Partner desk
02Solution discoveryShared
- Entry criteria
- Qualified partner.
- Activities
- Services, markets, customer journey and branding scope.
- Deliverables
- Solution outline.
- Exit criteria
- Scope agreed in writing.
- Approver
- Commercial lead
03Technical and operational feasibilityShared
- Entry criteria
- Solution outline.
- Activities
- Integration pattern, supply feasibility, data flows, security review.
- Deliverables
- Feasibility record and risk list.
- Exit criteria
- No unresolved blocking risk.
- Approver
- Integration desk
04Commercial and operating agreementShared
- Entry criteria
- Feasibility cleared.
- Activities
- Pricing, margin, settlement, support, governance, data terms.
- Deliverables
- Signed agreement.
- Exit criteria
- Agreement executed.
- Approver
- Both parties
05Tenant and configuration provisioningTaxiD
- Entry criteria
- Signed agreement.
- Activities
- Tenant creation, brand profile, services, markets, roles, sandbox credentials.
- Deliverables
- Sandbox tenant and workspace access.
- Exit criteria
- Partner can authenticate and quote in sandbox.
- Approver
- Integration desk
06Build and integrationPartner
- Entry criteria
- Sandbox tenant issued.
- Activities
- Booking flow, webhooks, documents, reconciliation handling.
- Deliverables
- Working integration in sandbox.
- Exit criteria
- Agreed scenarios implemented.
- Approver
- Partner engineering
07CertificationTaxiD
- Entry criteria
- Sandbox integration complete.
- Activities
- Happy-path and failure-path scenarios, signature verification, idempotency, cancellation, reconciliation.
- Deliverables
- Certification record.
- Exit criteria
- All mandatory scenarios pass.
- Approver
- Integration desk
08Controlled production launchShared
- Entry criteria
- Certification passed and production credentials issued.
- Activities
- Staged traffic exposure against rollback triggers.
- Deliverables
- Live programme at full exposure.
- Exit criteria
- 100% exposure held without a rollback trigger.
- Approver
- Both parties
09HypercareShared
- Entry criteria
- Programme live.
- Activities
- Heightened monitoring of bookings, payments, webhooks and settlement.
- Deliverables
- Hypercare exit report.
- Exit criteria
- Agreed stability window met.
- Approver
- Operations
10Joint performance governanceShared
- Entry criteria
- Hypercare exited.
- Activities
- Scheduled review of volume, quality, incidents, settlement and change.
- Deliverables
- Review record and actions.
- Exit criteria
- Continuous — the programme stays in governance.
- Approver
- Both parties
09
Launch is the beginning, not the finish.
Controlled exposure, hypercare, incident escalation and joint reviews keep the programme governed as it grows.
Monitor & reconcile
Booking quality, payments, webhook delivery and reconciliation exceptions feed the operating review.
Respond & recover
Named escalation owners, staged exposure and agreed rollback criteria support incident handling.
Change & govern
Changes follow notice and approval rules. Breaking changes and scope changes require recertification.
Performance measures
- Bookings created and completed
- Cancellation rate by cause
- Fulfilment and assignment performance
- Revenue and partner margin
- Settlement and reconciliation status
- Support volume and first-line resolution
- Service quality and customer ratings
- API usage, error rate and latency
10
The detail, when you need it.
Architecture, controls, commercial terms and operational procedures remain accessible here—without interrupting the main narrative.
White-label platform architecture
A partner request enters at the top of this spine and leaves as a settled, reported, documented journey. Each layer is a real system boundary with its own authorization.
Partner
Contracting legal entity
Tenant
Brand, services, markets, environment
Brand configuration
Identity applied to surfaces in scope
Customer experience
Branded booking and tracking surfaces
Booking / API
Quote, order, cancel, track — scoped credentials
Canonical mobility order
One order record, one state machine
Operations
Exception handling, support escalation
Dispatch / fulfilment
Supply assignment and completion
Payments
Capture on verified provider callback
Settlement
Append-only ledger and sealed statements
Reporting
Performance, usage and reconciliation
Multi-tenant model
Tenant A cannot reach Tenant B, and sandbox cannot reach production. Isolation is enforced in the database by row-level security, so a UI defect cannot leak another partner's data.
Partner
The contracting legal entity.
Root of every scope below; created by the partner desk on admission.
Tenant
One operating configuration of a partner (brand, services, markets, environment).
Sandbox and production are separate tenants; credentials never cross them.
Users and roles
The partner's own staff and their permissions.
Row-level security scopes every read and write to the caller's partner membership.
Customers
End customers of the partner brand.
Visible only inside the owning tenant; never pooled across partners.
Orders
Canonical mobility orders raised under the tenant.
Tenant-scoped; cross-tenant reads are rejected server-side, not hidden in the UI.
Credentials
API keys and webhook secrets.
Issued per tenant and environment, revocable, with an append-only audit trail.
Documents
Receipts, invoices and statements.
Tenant-scoped, hash-sealed and verifiable independently of the UI.
Settlement records
Charges, fees, statements and reconciliation.
Tenant-scoped, append-only; corrections are adjustments, never edits.
Brand configuration layer
A brand profile is attached to the tenant at provisioning and applied to the surfaces in scope. Some information is deliberately outside its reach.
Brand profile
- Logo
- Colours
- Typography
- App identity
- Email identity
- Notification templates
- Legal identity
- Customer-facing policies
Never overridable by branding
- Statutory identifiers on tax documents (issuing entity, tax identity, invoice numbering).
- Safety, emergency and incident-reporting information shown to a traveller.
- The lawful basis, privacy notice and data-controller identity presented at collection.
- Security surfaces: authentication screens, credential handling and consent prompts.
- Audit, event and settlement records — branded in presentation, never in substance.
The branded customer journey
The customer sees one continuous branded experience. Behind it, each step has an accountable operator.
- 01DiscoverPartner
- 02BookPartner
- 03QuoteTaxiD
- 04ConfirmShared
- 05TrackTaxiD
- 06FulfilTaxiD
- 07PayTaxiD
- 08Receive documentTaxiD
- 09SupportShared
- 10SettleTaxiD
- 11ReportShared
Canonical mobility order
One order record carries the journey from quote to settlement. These are the only states, and the only transitions the platform allows.
| State | Meaning | Allowed next |
|---|---|---|
| QUOTED | A priced, time-bounded offer exists. | PENDING · EXPIRED |
| PENDING | Accepted by the customer, awaiting confirmation of supply or payment authority. | CONFIRMED · CANCELLED · FAILED |
| CONFIRMED | Commitment made; the order is owned by operations. | ASSIGNED · CANCELLED |
| ASSIGNED | Supply is allocated to the order. | STARTED · CANCELLED |
| STARTED | Fulfilment is in progress. | COMPLETED · FAILED |
| COMPLETED | Fulfilment finished; charge and documents are raised. | terminal |
| CANCELLED | Terminated before completion; cancellation terms apply. | terminal |
| FAILED | Could not be fulfilled; exception handling applies. | terminal |
| EXPIRED | A quote lapsed before acceptance. | terminal |
API and integration
White-label runs on exactly the same API platform published for API partners — one surface, one set of scopes, one changelog. There is no separate, undocumented white-label API.
API platform overview
LiveCapability domains, endpoints, scopes and webhook catalogue.
OpenDeveloper console
LiveUsage, quotas, OpenAPI versions, webhook verification, delivery log and credential rotation.
OpenAPI documentation
LiveReference material for the published surface.
OpenDeveloper portal
LiveEntry point for partner engineering teams.
OpenPartner Workspace
LiveOperational workspace for an admitted partner.
OpenTaxiD Enterprise
LiveThe enterprise proposition this programme sits inside.
OpenScoped credentials per tenant and environment
Signed, replay-bounded webhooks
Idempotency keys on every mutating call
Versioned OpenAPI with published diffs
Tenant-scoped capability surfacewl-2026.08.1
Open the white-label workspaceEach branded surface is sourced from the same capability model as the API partner platform, with a mandatory X-TaxiD-Tenant header and tenant identity on every webhook envelope.
Quoting & AvailabilityLive
Server-governed quoting, identical to the API partner surface.
Booking & OrdersLive
Canonical mobility order with idempotency keys and a closed state machine.
Tracking & TelemetryLive
Scoped share tokens safe to render inside the partner brand.
Documents & EvidenceConfigured per programme
Partner brand on receipts and invoices; statutory identifiers fixed by the issuing entity.
Settlement & ReconciliationConfigured per programme
Tenant-scoped statements enabled per programme at provisioning.
Identity & GovernanceLive
Per-tenant, per-environment credentials with rotation and an append-only audit trail.
Security and data privacy
Only controls that exist are listed as controls. Everything else is marked roadmap or contractual — a security architect should be able to plan against this table without a call.
Security controls
Tenant isolation
LiveRow-level security scopes every partner read and write to the caller's membership; cross-tenant access is denied in the database, not the UI.
Scoped credentials
LiveAPI credentials are issued per tenant and environment by the integration desk, with revoke and rotation history.
Role-based access control
LivePartner staff hold explicit roles; privileged actions are checked server-side on every call.
Webhook signing
LiveHMAC-SHA256 over `${timestamp}.${rawBody}` with a bounded replay window and a verification console.
Audit logging
LiveCredential, lifecycle and document events are recorded append-only with actor and timestamp.
Encryption in transit
LiveTLS on every partner-facing endpoint; plaintext transport is refused.
Secrets management
LivePlatform secrets are held in managed secret storage and never returned to a browser.
Sandbox separation
LiveSandbox credentials cannot reach production data, and production credentials cannot reach sandbox.
Single sign-on for partner staff
RoadmapEnterprise IdP federation for partner workspace users.
Multi-factor authentication
RoadmapSecond-factor enrolment for partner workspace users.
IP allow-listing
RoadmapRestricting production credentials to declared egress ranges.
Data and privacy
Data minimisation
LiveOnly the traveller data required to quote, fulfil, document and settle a journey is collected.
Access logging
LivePrivileged reads of partner and customer records are recorded with the acting identity.
Data residency
Configured per programmePlatform data is held in the managed cloud region agreed at provisioning.
Retention and deletion
ContractualRetention periods and deletion handling are set in the data-processing terms of the agreement.
Data subject requests
ContractualRequests are routed through the partner as first line and executed by TaxiD for platform-held data.
Subprocessors and incident notification
ContractualNamed in the agreement, with notification obligations on both parties.
From order to settled statement
Each step names its source of truth. Nothing in this chain is edited after the fact — corrections are new entries.
Order
A completed order fixes the billable scope.
Source of truth: Canonical order record
Charge
Fare, surcharges, waiting and tolls are computed from governed pricing.
Source of truth: Pricing engine output stored on the order
Payment
Captured from the customer or drawn from a pre-funded partner wallet.
Source of truth: Verified payment-provider callback
Fees and tax
Platform fee, partner margin and applicable tax are applied to the charge.
Source of truth: Contracted commercial schedule
Settlement
Amounts due are accumulated over the agreed settlement period.
Source of truth: Append-only settlement ledger
Partner statement
A sealed statement is issued for the period.
Source of truth: Issued document with content hash
Reconciliation
Statement, payments and orders are matched line by line.
Source of truth: Reconciliation run output
Exception management
Refunds, reversals, adjustments and disputes are raised as new entries.
Source of truth: Adjustment entries — no ledger row is ever edited
Commercial model
The structure is published; the numbers live in the signed agreement. TaxiD does not publish white-label pricing, because it is sized from scope, services, markets and volume.
| Term | Basis | Status |
|---|---|---|
| Implementation and setup | One-off, sized from the agreed scope of services, markets and integration work. | Contractual |
| Transaction fee | Per completed order, tiered by monthly volume. | Contractual |
| Partner margin | Applied on top of the governed rate, agreed per service and market. | Contractual |
| Payment terms | Settlement period and payment window fixed in the agreement. | Contractual |
| Minimum volumes | Where a programme carries dedicated supply or operations capacity. | Contractual |
| Refunds and chargebacks | Allocated by cause between partner and TaxiD under the agreement. | Contractual |
| Taxes | Charged and remitted by the issuing entity per Kenyan tax law. | Contractual |
| Support and service levels | Selected support tier and the associated response targets. | Contractual |
Service levels
Targets and objectives are how the platform is run and reported. A commitment exists only where the agreement says so.
Booking API availability
SLOInternal service-level objective, reported monthly to the partner.
Quote latency
TARGETOperational target tracked in the developer console; not a contractual commitment.
Webhook delivery
TARGETRetried with backoff; every attempt is recorded with a correlation ID.
Incident response
CONTRACTUALSeverity definitions and response targets are set in the agreement.
Planned maintenance
CONTRACTUALAdvance notice window agreed per programme.
Service credits
CONTRACTUALWhere agreed, credits attach to the contracted measures only.
Controlled go-live and hypercare
Production exposure is staged, and every stage has a defined way back. Hypercare ends on evidence, not on a date.
Traffic exposure
- 0%
- 5%
- 25%
- 50%
- 100%
Rollback triggers
- • API error rate above the agreed threshold for the exposure window
- • Quote or booking latency beyond the operational target
- • Booking failure rate above baseline
- • Payment capture or callback failure
- • Webhook delivery failure that is not clearing on retry
- • Settlement mismatch detected in reconciliation
- • Any safety incident linked to the programme
Hypercare monitoring
- • Transaction volume against forecast
- • Booking failures by cause
- • Customer issues raised to first line
- • Fulfilment and assignment performance
- • Payment capture and refund activity
- • Webhook delivery and retry chains
- • Settlement and reconciliation exceptions
- • Latency and availability of partner-facing endpoints
Continuous operations, change and incidents
The relationship does not end at go-live. It enters a loop with recertification built into it.
- Launch
- Hypercare
- Monitor
- Measure
- Optimise
- Change
- Recertify
- Scale
Change management
Breaking API change
RecertificationAdvance notice with a dated migration window and a supported previous version.
Additive API change
Published in the changelog; no partner action required.
Pricing change
Notice period as set in the agreement.
Service or market change
RecertificationAgreed with the partner before configuration changes.
Policy or legal change
Notified with the effective date.
Security change
Notified; may be applied immediately where a risk requires it.
Brand change
Partner-initiated, reviewed against the brand immutables before publication.
Incident management
1. Detection
Platform monitoring, partner report or customer escalation opens an incident.
2. Severity
Classified by customer impact and financial exposure using the agreed severity scale.
3. Escalation
Routed to the accountable operations and engineering owners.
4. Partner notification
Issued for incidents that affect the partner's customers or settlement.
5. Mitigation and recovery
Containment first, then service restoration, with staged re-exposure where traffic was withdrawn.
6. Root cause analysis
Documented cause, contributing factors and detection gap.
7. Corrective action
Tracked to completion with an owner and a date.
8. Post-incident review
Reviewed jointly at the next governance session.
Business continuity posture
Partner-facing API outage
Requests fail closed with typed errors; no order is silently created or lost.
Dispatch degradation
Orders remain valid and queued; operations fall back to manual assignment.
Payment provider outage
Capture is deferred and retried; orders are not marked paid without a verified callback.
Mapping provider outage
Quoting degrades to agreed fallback pricing rather than producing an unpriced order.
Database or regional incident
Managed platform recovery; recovery objectives are agreed contractually rather than published.
Webhook delivery failure
Retry with backoff plus a delivery log with correlation IDs for replay.
Cyber incident
Credential revocation, containment and partner notification under the agreed notification terms.
Performance and governance
What gets measured, and the forum that owns each decision.
Partner performance
- Bookings created and completed
- Cancellation rate by cause
- Fulfilment and assignment performance
- Revenue and partner margin
- Settlement and reconciliation status
- Support volume and first-line resolution
- Service quality and customer ratings
- API usage, error rate and latency
Governance domains
Partner eligibility
Partner deskAdmission, suspension and exit criteria.
Brand approval
Brand reviewCustomer-facing presentation checked against the brand immutables.
Service and market approval
OperationsWhat the tenant may sell, and where.
Security
Security reviewCredentials, access, isolation findings and remediation.
Data governance
Privacy reviewProcessing scope, retention and data subject handling.
Commercial governance
Commercial reviewPricing, margin, volume and settlement performance.
Change governance
Change boardNotice, impact, testing, recertification and rollback.
Performance governance
Joint reviewScheduled review of the agreed measures and actions.
Claim verification matrix
Published so a buyer can challenge us on any statement above. Each claim carries a status and the evidence behind it.
| Claim | Category | Status | Evidence |
|---|---|---|---|
| Partner data is isolated per tenant | Security | Live | Row-level security policies scoped to partner membership, exercised by authorization tests. |
| Webhooks are signed and replay-bounded | Security | Live | HMAC-SHA256 signature scheme with a tolerance window and a verification console. |
| Credentials can be rotated and revoked with history | Security | Live | Credential audit records written on create, rotate and revoke. |
| Settlement records are append-only | Finance | Live | Corrections are recorded as adjustment entries; no ledger row is updated in place. |
| Branded booking experience | Product | Configured per programme | Brand profile applied per tenant during provisioning. |
| Custom partner domain | Product | Roadmap | Not implemented; shown as roadmap on the public page. |
| Branded native mobile application | Product | Roadmap | No store-published white-label app exists. |
| SSO and MFA for partner staff | Security | Roadmap | Not implemented; explicitly labelled as roadmap. |
| Availability and latency commitments | Service levels | Contractual | Targets and objectives are reported; commitments exist only in a signed agreement. |
| Commercial pricing | Commercial | Contractual | No published price list; structure only. |
Frequently asked questions
11 / Your next chapter
Build Your Mobility Proposition on a Governed Platform.
Tell us about your brand, target markets, service portfolio and integration requirements. Our team will assess programme fit, operational readiness and the appropriate commercial model.