Re-architecting a fragmented telecom commerce ecosystem

Turning disconnected retail, ecommerce, identity, credit, payment, fulfilment and self-service processes into one coherent customer and delivery model.

Impact: Coherent end-to-end commerce model
Parallel build and testing enabled
Reduced ambiguity and rework
System scope: Catalogue and configuration
Identity, account and credit
Checkout, provisioning and fulfilment
Self-service, admin and measurement
Engagement: Telecom digital commerce (NDA-safe)
Ownership: CX and service architecture
Commerce and decision architecture
Requirements and acceptance logic
Interaction and delivery specification
Signals: Systems ThinkingCommerceService DesignDecisioningOperationsProduct Architecture

The decision I owned

Design the operating model, not just the storefront

Translate fragmented business processes into one executable customer experience, then make the rules, states, ownership and dependencies explicit enough for teams to build against.

The engagement started inside a telecom estate where a seemingly simple purchase crossed retail and ecommerce, product and offer data, stock, customer identity, account creation, credit, billing, provisioning, payment, fulfilment and reconciliation. The customer experienced one journey; the organisation operated many separate processes.

I joined under a Digital Product Specialist remit, but the demonstrated scope extended well beyond interface design. I mapped the operating system behind the experience, simplified it into a customer-facing model, and translated that model into journeys, decision logic, requirements, data structures, interaction design and implementation guidance.

Final UI and proprietary internal artefacts remain under NDA. The diagrams shown here are reconstruction-based and focus on the architecture and decisions that made delivery possible.

What I recognised

The core problem was not a weak ecommerce funnel. It was a mismatch between how customers thought about buying a telecom product and how the organisation had evolved to fulfil that request.

A customer sees one purchase. Behind it sat catalogue, price, stock, identity, account, credit, contract, service, payment, provisioning, inventory, delivery or collection, and reconciliation.
Commercial configuration was dynamic. Location, variant, payment term, plan, accessories, credit eligibility and upfront contribution could all change the offer.
The experience could not stop at checkout. Provisioning, fulfilment, order status, reminders, collection and support demand were part of the same service.
The artefacts had to survive organisational hand-offs. In a highly intermediated decision environment, journey and specification work needed to be self-explanatory enough to reduce repeated interpretation.

The constraints I had to hold together

Telecom commerce constraints and design responses
Constraint	Why it mattered	Design response
Fragmented systems and ownership	One customer action crossed multiple operational processes, teams and sources of truth.	Map the AS-IS system, then define a TO-BE lifecycle with explicit states and hand-offs.
Limited existing product-design infrastructure	Journeys, reusable decision models and delivery specifications needed more structure than a screen-led process provided.	Create shared journey architecture, reusable patterns, requirements, acceptance criteria and design references.
High decision latency	Work moved through several layers before decisions could progress.	Make rationale, branching, dependencies and ownership visible so artefacts could travel without constant re-explanation.
Identity, credit and eligibility rules	Account status and risk decisions could materially change what a customer was allowed to buy and at what price.	Use conditional gating, explicit decision states, reusable credit results and recoverable fallback offers.
Operational dependencies	Stock, provisioning, payment, delivery, collection and reconciliation affected whether the promised experience could actually be fulfilled.	Extend the product model beyond checkout into fulfilment, notifications, self-service, admin and reporting.
Broad scope with limited specialist resource	The work crossed product design, CX, service design, requirements, information architecture and technical design.	Work across those layers as one connected system rather than waiting for each discipline to operate sequentially.

From business process to executable customer model

The AS-IS view exposed the organisation's machinery. The TO-BE model collapsed it into a smaller number of customer-facing stages, with branching only where customer type, account status or eligibility genuinely changed the journey.

Discover and configureProduct, location, stock, terms, plan, accessories and number choices establish the commercial intent.
Identify and linkUse guest, JT ID or existing-account relationships only where the proposition requires them.
Verify and decideIdentity, account and credit rules determine eligibility while keeping outcomes understandable and recoverable.
Checkout and paySeparate monthly and upfront commitments, handle payment states, and preserve recovery from failure.
Provision and fulfilTrigger service, inventory, delivery or collection and keep the customer informed through status changes.
Manage and measureCarry the lifecycle into self-service, support, repeat purchase, administration and reporting.

Browse discovery and customise flow — **Discovery and commercial configuration.**
Location, stock, product variants, terms, plans and accessories shape the proposition before checkout.

Progressive disclosure keeps a highly configurable offer understandable without removing commercial flexibility.

Authentication gating and JT Digital Identity flow — **Authentication as conditional gating.**
Identity is introduced only when the product or account relationship requires it.

Guest restrictions protect regulated/postpaid flows without forcing unnecessary friction into every purchase.

I treated commerce as a decisioning system

Price was not a static value and a telecom customer was not a simple ecommerce account. The interaction model had to represent relationships between product and variant, plans and payment terms, JT ID and customer accounts, services and mobile numbers, plus external and internal eligibility decisions.

Product and catalogue model: The requirements defined around 39 product-data fields spanning identity, content, imagery, attributes, pricing, discounts, stock, pre-order state, merchandising relationships and SEO. Ownership was separated across transactional, content and commerce systems rather than forcing one system to do every job.
Customer and account model: Existing customers could have multiple postpaid accounts, account-linking and signatory relationships. The experience had to make those relationships understandable without exposing the organisational complexity underneath.
Regulated onboarding: New-customer acquisition combined personal and banking data, address lookup, consent, identity verification, document/liveness fallbacks, Direct Debit, account creation and mobile-service provisioning.
Credit decisioning: Credit results could be reused when sufficiently recent, combined with internal customer information, and mapped to allowance rules that changed pricing or offered a viable fallback route.

New customer onboarding postpaid flow — **Regulated new-customer onboarding.**
The journey brings verification, Direct Debit setup, account creation and mobile-service choices into one understandable sequence.

High-stakes outcomes and recovery paths are explicit at verification points.

New customer credit check and allowance matrix flow — **Credit decisioning with recoverable outcomes.**
Allowance logic changes the proposition and pricing when eligibility changes.

Fallback offers preserve a viable route to purchase instead of turning an adverse outcome into a dead end.

Existing customer credit check caching flow — **Credit recency and caching.**
Existing customers avoid unnecessary repeat checks when a recent result can be reused.

The rule reduces avoidable friction while keeping the decisioning model explicit.

The specification was part of the product

In a fragmented environment, screens alone would have left too much open to interpretation. I created a design-to-delivery specification system that connected business process, product behaviour and implementation detail.

143 numbered requirements across 11 workstreams

The specification covered the lifecycle from browsing and authentication through onboarding, credit, checkout, fulfilment, self-service, backend administration and reporting.

ModelTurn operational processes and whiteboard decisions into explicit customer states, branches and dependencies.
SpecifyTranslate those states into requirements, user stories, acceptance criteria, priorities and system behaviour.
TraceLink interface requirements to Figma where a design was needed while allowing API, reporting and backend behaviour to remain correctly specified without mock-ups.

Roughly 47 numbered requirements linked directly to the early low-fidelity Figma work. Other requirements were intentionally marked as having no design because the important behaviour lived in APIs, state management, reporting, fulfilment or administration. That separation made the design artefacts one layer of a broader product specification rather than treating Figma as the product.

Customer experience continued into operations

I did not treat a successful payment as the end of the experience. Checkout had to trigger the right billing, provisioning, inventory and Direct Debit processes, while fulfilment had to keep customers informed across delivery, collection, delays, reminders and recovery.

Pay now checkout end-to-end flow — **Checkout recovery and system hand-offs.**
Payment, inventory and delivery states include failure and recovery paths rather than only the happy path.

Ownership and transitions between ecommerce, payment and fulfilment systems are made explicit.

Fulfilment and notification ladder flow — **Fulfilment and notification as part of the service.**
Collection, delivery, reminders and escalation are designed as customer-experience states, not downstream operations.

Explicit reminder and non-collection logic is intended to reduce avoidable status enquiries and support demand.

Post-purchase self-service: Order history, detailed status, invoices, account settings, payment and billing preferences, refunds and repeat purchase extended the model beyond acquisition.
Operational controls: Backend requirements covered customer-order administration, catalogue and promotion management, configurable credit rules, fulfilment completion and customer notifications.
Measurement: The product definition included sales, funnel, credit, verification, delivery/collection, customer behaviour and operational reporting so the organisation could measure and tune the system after launch.

I designed for the organisation that had to deliver it

The environment had limited established product-design maturity and slow, highly intermediated decision pathways. That made the communication system almost as important as the customer-facing one.

Journeys made customer and operational branching visible. Requirements captured behaviour, acceptance criteria and dependencies. Design references showed where interaction work was necessary. Explicit ownership and system triggers let product, engineering and operational conversations happen in parallel instead of waiting for a single linear hand-off.

The deliverable was shared clarity

The work created enough structure for different teams to make consistent decisions from the same product model—reducing ambiguity and rework while enabling parallel build and testing.

What changed

The strongest evidence from this engagement is architectural and delivery impact rather than post-launch analytics. I have deliberately not attributed conversion, support or revenue improvements without a verified analytics source.

Telecom commerce architecture outcomes
Change	Outcome
System coherence	Fragmented operational processes were translated into one end-to-end customer and delivery model.
Conversion resilience	Authentication, stock and credit constraints gained fallback and recovery routes rather than unnecessary dead ends.
Delivery clarity	Detailed states, dependencies, requirements and acceptance criteria reduced repeated interpretation and ambiguity.
Engineering readiness	Behaviour beyond screens—including system triggers, state handling and ownership—supported parallel build and testing.
Operational coverage	Fulfilment, notifications, self-service, administration and reporting were designed as part of the product rather than left downstream.
Scalability	Reusable product data, configurable rules and clearer system boundaries created a stronger foundation for future digital commerce.

NDA note

This is an anonymised, reconstruction-based case study. I cannot share final production UI, proprietary copy or internal source documents publicly, so I am showing the experience architecture, decision logic and delivery model that demonstrate the substance of the work without exposing confidential material.