SERVICE DESIGN CASE STUDY
Designing a B2B2X
Marketplace Service
at Omantel
How service design transformed a UX scaling challenge into an organisational alignment strategy — protecting trust, clarifying ownership, and enabling sustainable marketplace growth across CEP × Xhawi.
ROLE
Lead UX / Service Designer
ENGAGEMENT
~2.5 years (Omantel ecosystem)
THIS ASSIGNMENT
~6–8 months focused service design
DOMAIN
Telecom · E-Commerce · B2B2X
TEAM SETUP
1 Lead Designer (me) · 1 Creative Director · 2 Product Designers · 1 Visual Designer
THE PROBLEM
Trust broke every time customers crossed from CEP to Xhawi
Payments failed, wallets confused, nobody knew who was responsible. Users blamed Omantel — regardless of where failures occurred.
THE CONSTRAINT
UX fixes addressed surfaces, not the service underneath
Every UI improvement increased traffic but also amplified unresolved downstream failures. The problem was systemic.
WHAT WE DESIGNED
A service blueprint aligning trust, money, and ownership
We shifted from UX optimisation to end-to-end service design — mapping accountability across CEP, Xhawi, and sellers.
WHAT CHANGED
~30% less drop-off, ~28% fewer escalations, scalable model
Trust held across handoffs. Support resolved faster. New sellers onboarded with clear rules.
01 — CONTEXT
Two Platforms, One Customer Expectation
Quick version
CEP and Xhawi served the same 2M+ Omantel customers but operated as separate services, causing trust and accountability to default to the Omantel brand. A phased soft launch allowed controlled seller onboarding, limited customer exposure, and real-world validation. Low-friction integrations via Shopify, WooCommerce, and CSV enabled marketplace scale while protecting customer trust and brand credibility.
◉
Omantel Super App
(CEP)
Primary customer platform (iOS & Android). Identity, telecom, wallet, loyalty (Makasib), payments for 2M+ customers. The trusted Omantel environment.
◈
Xhawi - AI-Powered B2B2X Marketplace
Oman's first homegrown e-commerce platform with Zavi. End-to-end commerce: discovery, checkout, payments, delivery. Sellers via Shopify, WooCommerce, CSV.
◇
Why This Matters for Oman
Aligned with Oman Vision 2040. Omantel's shift from telecom to ecosystem orchestrator — revenue from platforms and partners, not just subscriptions.
Key Collaborators
Because the service spanned identity, payments, commerce, fulfilment, and support — no single team owned the full experience. I led service design within a cross-functional squad, collaborating continuously with:
CEP Product & Engineering
Customer Support & Operations
Marketing & Growth
Zavi (External Partner)
Xhawi Product & Platform
Finance, Legal & Compliance
02 — THE INITIAL ASK
Make the Entry Point Better
Quick version
Leadership wanted a clearer CEP → Xhawi entry point before scale-up.
The assumption: better UI would be enough to protect trust.
The project was framed as a UX-led enhancement — improve marketplace discovery from within CEP. Access to Xhawi existed but was inconsistent: occasional banners, campaign-led links, redirections without expectation-setting.
The explicit ask: persistent entry points, visual alignment, smoother transitions. Scope was intentionally limited to the frontstage — no changes to service ownership or backend orchestration.
What existed before
Before this engagement, access to Xhawi from CEP existed in a limited and inconsistent form. Marketplace exposure was primarily driven through occasional promotional banners, non-contextual redirections that moved users out of CEP without clear expectation-setting, and entry points that varied by campaign, channel, or release rather than being a stable part of the CEP experience.
This meant users were often unaware they were leaving the CEP environment. Expectations around payments, wallet usage, and support ownership were not set upfront. Trust relied on the Omantel brand implicitly, without the service being designed to uphold it consistently.
The business believed that clarifying the entry point and cleaning up the interface would be enough to support scale. It was a reasonable assumption until we tested it against real service signals.
"
03 — THE REFRAME
Better Screens Led to the Same Failures
Quick version
We tested multiple UX concepts. All improved visibility none resolved downstream failures.
The problem was at the service layer, not the interface.
What we explored first
🏛
Seamless Cross-Platform Continuity
Users were redirected from CEP to Xhawi without continuity cues, leading them to believe they had left Omantel entirely. This north star led to preserving CEP identity context during transitions, avoiding surprise re-authentication, and designing handoffs where CEP remained the perceived "owner."
↗
Transparent Wallet, Loyalty & Payment Rules
Support tickets showed customers unsure whether CEP Wallet, Makasib points, or Xhawi checkout logic applied. This drove explicit pre-purchase disclosures — which wallet would be charged, how loyalty applied — and post-purchase clarity on refunds.
⚠
Clear Ownership Before & After Purchase
Customers frequently contacted Omantel support asking who was responsible for delivery or refunds. This informed service blueprint decisions defining ownership at each stage — CEP for trust and payments, Xhawi for orchestration, sellers for fulfilment.
How the mismatch became evident
As these concepts were pressure-tested, it became clear that while they improved visibility, they did not resolve the questions and failures users were already experiencing once they entered the marketplace.
🎧
Support-Led Evidence
Failed payments, wallet deductions, loyalty confusion even through clearer entry paths.
❓
Ownership remained unclear
After purchase: "Is this CEP, Xhawi, or the seller's problem?"
📣
Marketing couldn't compensate
No messaging could set expectations without service rules behind it.
🔀
Escalations crossed every team
Breakdowns happened after UX handoff, not
at it.
THE CALLOUT
Improving entry points would increase marketplace traffic, but it would also amplify unresolved service failures downstream. The problem was not how users entered Xhawi, but how the service behaved once they did.
We reframed the problem from "improve the entry point" to "design continuity and ownership across the full service lifecycle."
04 — RESEARCH & SYNTHESIS
Following the Failures Upstream
Quick version
Limited user access meant support teams, CRM data, and analytics became primary sources. We synthesised through a service lens — grouping by where the service failed, not the UI.
14
Stakeholder Interviews
Product
Tech
Legal
Marketing
Ops
Support
4
Cross-Functional Workshops
Ownership gaps
Risk framing
Service alignment
Weekly
Support
Syncs
Ticket patterns
Escalation paths
Live failures
Ongoing
Marketing & Growth Reviews
Messaging constraints
Entry patterns
Expectations
DATA SOURCES TRIANGULATED
Support CRM
Tickets tagged weekly — payment failures, wallet issues, Makasib confusion, ownership questions
+
Behavioural Analytics
Firebase / GA — drop-off rates, checkout abandonment, wallet selection patterns
+
Behaviour Logs
Retries, repeat support contact, back-navigation — separating friction from breakdowns
HOW WE SYNTHESISED
01
Raw Capture
Tickets tagged weekly — payment failures, wallet issues, Makasib confusion, ownership questions
02
Affinity Mapping
Observations clustered without pre-defined categories — patterns emerged organically
03
Service Failure Theming
Reframed through a Service Lens — grouped by where the service failed, not the UI
04
Expectation vs. Reality
Mapped UX promises against live service behaviour at each journey stage
THE CORE FINDING — 4 SERVICE FAILURE THEMES
Across every source tickets, analytics, interviews, workshops the same four breakdowns repeated.
These weren't UX bugs. They were structural service failures no interface change could resolve:
Trust Anchoring
Any Xhawi failure = Omantel failure, regardless of who caused it.
Financial Clarity
Users discover wallet/refund rules only when something goes wrong.
Cross-Platform Continuity
Moving between platforms creates cognitive breaks and doubt.
Ownership & Accountability
"Who do I contact?" nobody knew after purchase.
THE CALLOUT
The core problem was not discoverability, it was how trust, money, and responsibility flowed across the service. These four themes became the foundation for every design decision.
05 — NORTH STARS
What Success Looked Like
Quick version
Before jumping to solutions, we defined three north stars derived directly from the failure themes.
These weren't feature specs — they were decision filters for what to prioritise, delay, or reject.
🏛
SIGNAL
Users believed they'd left Omantel when entering Xhawi
Seamless Continuity
Across every platform handoff
DESIGN RESPONSE
Preserve CEP identity context at every transition — no surprise re-auth, no brand break
↗
SIGNAL
Customers unsure if CEP Wallet, Makasib, or Xhawi checkout applied
Financial Transparency
Before commitment, not after failure
DESIGN RESPONSE
Surface wallet, loyalty, and refund rules explicitly at pre-purchase — not via support
⚠
SIGNAL
Customers asked "who's responsible?" after every purchase
Clear Ownership
End-to-end, especially post-purchase
DESIGN RESPONSE
Define CEP → Xhawi → Seller accountability at each stage so support can act instantly
06 — ECOSYSTEM
Who Owns What — And Why It Matters
Quick version
Responsibility was distributed across platforms and partners, but accountability stayed with Omantel. Problems lived betweenthe boxes — not inside them.
B2B2X ORCHESTRATOR
Omantel
Owns: Customer trust, identity, payments, wallet, loyalty (Makasib), regulatory compliance, brand accountability.
CUSTOMER
CONTROL PLANE
CEP (Super App)
Owns: Entry, identity, wallet access, loyalty visibility, perceived service ownership.
MARKETPLACE ORCHESTRATION
Xhawi
Owns: Discovery, seller onboarding, orders.
Borrows: Trust, payments, compliance from Omantel.
VALUE
PROVIDERS
Sellers / ISV Partners
Owns: Inventory, pricing, fulfilment, delivery, returns.
Does not own: Customer trust or primary support.
07 — DESIGN STRATEGY
Turning Diagnosis into Design Principles
Quick version
We now knew what was broken (the four failure themes) and what success looked like (the north stars). This section bridged the gap — translating each failure into a concrete design principle that would govern how we built the service blueprint.
Without this step, teams would have jumped straight from insights to screens which is exactly what had failed before. Instead, we needed shared rules that every team product, engineering, support, marketing could use to evaluate decisions. Each principle maps directly from a failure theme and forward into the blueprint:
FROM:
TRUST ANCHORING
Continuity over channels
PROBLEM
Users felt they left Omantel when entering Xhawi — breaking trust at the handoff.
DESIGN RESPONSE
CEP remains the perceived owner across all stages. Identity, visual cues, and language reinforce continuity at every transition.
FROM:
CROSS-PLATFORM CONTINUITY
Intentional handoff moments
PROBLEM
Invisible platform transitions amplified confusion and doubt.
DESIGN RESPONSE
Transitions treated as first-class service moments with explicit expectation-setting.
FROM:
FINANCIAL CLARITY
Transparency by default
PROBLEM
Wallet, loyalty, and refund rules discovered only
at failure.
DESIGN RESPONSE
All payment rules surfaced before commitment — which wallet, how loyalty applies, refund policy.
FROM:
OWNERSHIP & ACCOUNTABILITY
Governance by design
PROBLEM
Post-purchase, nobody knew who owned delivery, refunds, or resolution.
DESIGN RESPONSE
Explicit ownership at each stage — CEP for trust, Xhawi for orchestration, sellers for fulfilment.
THE CALLOUT
These four principles became the rules we designed the service blueprint against. Every row, every handoff, every ownership boundary in the blueprint traces back to one of these.
08 — JOURNEY MAPS
Current State vs. Future State
Quick version
The current-state journey exposed where trust breaks across the customer lifecycle. The future-state journey shows how continuity, clarity, and ownership are designed in applying the four principles to every stage.
These journeys then fed directly into the service blueprint.
So what did we change?
The future-state journey applies each design principle to the moments that broke in the current state. Continuity is now designed into handoffs. Financial rules surface before commitment. Ownership is visible at every stage — so even when multiple systems and partners operate underneath, the customer always knows where they stand and who to turn to.
The gap between these two journeys is exactly what the service blueprint
was built to close — turning the future-state promise into an organisational delivery model.
09 — SERVICE BLUEPRINT
The Hero Artifact
Quick version
The journey maps showed what the future experience should feel like. The blueprint answers the harder question, how does the organisation actually deliver it? Who owns what backstage, what systems support each stage, and where do failures escalate?
This blueprint turned an abstract future journey into an executable service model. It aligned CEP, Xhawi, partners, and backend teams around clear ownership — so trust wouldn't break as the marketplace scaled.
10 — KEY DECISIONS
What We Chose and What We Gave Up
Quick version
The blueprint revealed where scaling too fast would cause harm. Each decision below was a conscious
trade-off protecting trust over speed.
Blocked new seller categories until refund ownership was defined
Growth team wanted to onboard electronics and high-value sellers for a Ramadan campaign. We blocked it because the blueprint showed refund flows between CEP Wallet, Xhawi, and sellers had no clear owner launching would have generated support tickets with no resolution path.
Refund clarity
over
Ramadan launch
Added a wallet selection step instead of auto-deducting from CEP Wallet
Engineering proposed auto-deducting from the primary CEP Wallet to reduce checkout steps. We rejected it because analytics showed wallet confusion was the #1 payment-related support ticket customers needed to see which wallet, confirm Makasib eligibility, and understand refund rules before committing.
Payment transparency
over
Faster checkout
Replaced silent WebView redirect with an explicit transition confirmation
The original CEP → Xhawi handoff was a seamless WebView load visually smooth but it left users unsure if they were still in Omantel. We added a brief confirmation moment with context ("You're entering Xhawi Marketplace, powered by Omantel"). It added ~2 seconds but reduced post-handoff support contacts.
Trust at transition
over
Seamless UX
Wrote support playbooks before building automated ticket routing
IT wanted to invest in automated CRM routing rules. We pushed back — without defined ownership per stage (who handles delivery complaints? wallet disputes? seller returns?), automation would just route tickets faster to the wrong team. We defined the rules first, then automated.
Clear escalation paths
over
CRM automation
11 — OUTCOMES & IMPACT
What Changed
Quick version
Measured over 6–10 weeks using behavioural analytics, CRM data, and operational reviews.
~30%
Less handoff
drop-off
~28%
Fewer cross-team
escalations
~22%
Faster partner
onboarding
~18%
Faster time-to
first-action
BEFORE
AFTER
Less handoff drop-off
• 32–35% drop-off at handoff
• High retry events
• ~42s to first action
• 20–22% drop-off
• Retries down 25%
• ~35s to first action
Support & Ownership
• 38–40% tickets escalated cross-team
• 2–3 handoffs per resolution
• 26–28% escalation rate
• Better first-contact resolution
Partner Onboarding
• Multiple workshops per seller
• Tribal knowledge dependency
• Clarification cycles down ~22%
• Blueprint as canonical reference
These weren't dramatic conversion wins. They were signals that service-level clarity mattered more than short-term optimisation and that the foundation could now safely scale.
12 — REFLECTIONS
What I Learned as a Service Designer
01
Influence matters more than artefacts
The real impact came from using artefacts to change conversations, align teams, and reframe decisions around risk and accountability.
02
Governance is part of the experience
Ownership models and SLAs actively shape how safe a service feels to customers, especially after payment.
03
Service design is about sequencing
Success comes from deciding what to stabilise first and what to delay. Scale requires restraint, not just creativity.
04
Support teams are primary research partners
In environments with limited user access, designing with support not just for them uncovers systemic issues early.
