♥
DIGITAL TRANSFORMATION · SERVICE DESIGN
Transfer of ownership for business accounts
A service design case study about turning an offline, ticket-led account ownership transfer into a clearer workflow for business customers, internal operations, and the backstage teams responsible for making the transfer safe.
ROLE
Service Designer
TIMELINE
4 months
SCOPE
Service Blueprint + digital customer journeys
A service journey hidden behind tickets
This split scenario case involved, admin authentication, error handling, expiry windows, and multiple teams whose work had to line up behind the scenes.
01 · PROJECT SNAPSHOT
The account transfer was simple to request, but complex to fulfil
A customer only wants an account moved to a new owner. Behind that request sits a fixed number, attached services, payment rules, recipient acceptance, authentication, and a chain of internal checks.
My role
I acted as the central service designer, connecting backstage teams while keeping the customer experience visible in every discussion.
Goal
The goal was to create a seamless workflow for customers and internal operations while revamping transfer of ownership for an account number.
Product details
The account was a fixed or landline number that could carry domains, email accounts, Microsoft 365, Copilot, and other third-party services.
Business rules
The location never changes; transfer charges are paid by the new owner; attached services stop once the request is sent; and if the recipient does not accept in time, the request expires.
02 · CURRENT PROCESS
A ticket could start the transfer, but nobody could really follow it
Ownership transfers usually happen in moments of organisational change: a company merges, gets acquired, is sold, or moves an account to a new business owner. Sometimes the new owner is not even an existing etisalat customer, which adds onboarding and verification to an already sensitive request.
Before this project, the journey was offline. Business customers raised a ticket through the portal or another service channel, then documentation moved through email. Customers had no tracking, internal teams had no structured steps, and the 10–12 business-day SLA often bled because information arrived incomplete or edge cases surfaced too late.
The four pain points
No customer tracking · Messy documentation through email · No structured step-by-step instructions for internal teams · A 10–12 business-day SLA that often slipped because incomplete information and unhandled edge cases kept reopening the work.
03 · DESIGN AT WORK
The visible part was tracking. The hard part was orchestration.
Borrow a working pattern
From my Order to Delivery work, we already had a milestone system that could let customers track many types of orders.
Locate the real blocker
Tracking solved the customer visibility gap, but the real challenge was backstage: internal teams needed precise instructions and fewer ambiguous handoffs.
Ask sharper questions
Before service blueprinting, I pushed on edge cases: what is happening, how often, and why were these cases not accounted for?
Turn errors into guidance
Instead of generic failure states, validations could explain what went wrong and what action the user or team could take next.
04 · BEFORE BLUEPRINTING
The customer structure shaped every edge case
Before drawing the blueprint, I needed to understand how business customers are recognised internally. A company is not just a customer record — it can contain trade licences, cost centres, admins, services, and critical authentication steps.
A business customer is a structure, not a single record
Every business customer is recognised internally by trade licence. Each cost centre has its own unique trade licence, and that structure decides who can request, approve, receive, or block an ownership transfer.
Admin authentication
Critical actions like churn, clone SIM, and account transfer require an admin user to authenticate through UAE PASS across channels.
Cost-centre logic
Most edge cases were not about the phone number. They were about donor and recipient cost centres, their rules, and eligibility.
05 · SCOPE SPLIT
Workshops turned one request into two very different journeys
The questions I asked in stakeholder workshops helped reveal that the transfer was not one flow. It had two major scenarios, each with different risk, authentication, and operational handling.
SCENARIO 01
Transfer within organisation
The account moves from one branch or cost centre to another under the same owner and admins. Since the admin is the same, the flow is more straightforward — but still needs validation and clear tracking.
SCENARIO 02
Transfer outside organisation
The donor creates a transfer request and the recipient accepts it. If the receiving organisation is not already a customer, onboarding becomes an extra step before the transfer can complete.
06 · EDGE CASES
The real work was designing for what could go wrong
After speaking with business and customer support teams, we realised most edge cases were cost-centre related. Luckily, we had worked earlier on cost-centre validations — treating error states as opportunities to tell users exactly what went wrong and what action they could take next.
“What is happening with these cases? How often are they occurring? Why were they not accounted for?”
These questions became the bridge between stakeholder workshops and the service blueprint.
Donor cost-centre validations
The donor side needed checks before the request could safely move forward. Instead of a generic “something went wrong”, the flow needed to communicate the specific issue and the next action.
Recipient cost-centre validations
The recipient side required its own checks, especially for outside-organisation transfers where acceptance, eligibility, onboarding, and expiry windows all affected the journey.
07 · FLOW & ARTIFACTS
The flow had to account for both straight-through and recipient-led paths
Within-organisation transfers are straightforward because the admin is the same. Outside-organisation transfers require a donor to create a transfer request, a recipient to accept it, and in some cases a new-customer onboarding step before completion.
CUSTOMER MILESTONES
Tracking all order types through milestones
This solved the first pain point: customers could see the state of the request instead of relying on offline follow-ups.
USER FLOW + BIRD’S-EYE VIEW
A shared view for the whole service
The final artifacts aligned donor creation, recipient acceptance, UAE PASS authentication, onboarding when needed, expiry rules, and the internal teams responsible for each step.
08 · CONCLUSION
A complicated transfer became a service the teams could run with more confidence
The project was difficult because ownership transfer did not live in isolation. Address verification, device eligibility, authentication, onboarding, expiry rules, and attached business services all touched the same journey.
10–12
Business-day SLA exposed by the old offline process
2
Core scenarios defined through workshops
4 mo
Cross-team work to align rules, checks, and flow
Why this became rewarding
Several projects had a major impact on this one, especially address verification, a TDRA mandate for all customers, and device eligibility, a special credit check for devices. We had to work with those teams separately to integrate their services into this transfer journey. It was four challenging months of work, but rewarding because it made a complicated service easier to understand, track, and operate. The same approach now needs to be applied to mobile accounts, with minor tweaks.
Thanks for reading · I’m open to opportunities and immediately available · Connect on LinkedIn or email ayesha@patelness.in