Autonomous Retail Operating Model & Service Blueprint

Designing an Operating System for the World's First AI-Powered Autonomous Telecom Store

How might we design a reliable operating model for a fully autonomous retail experience when no proven regional precedent, technology stack, or service blueprint exists?

Etisalat by e& set out to launch the world's first AI-powered autonomous telecom store EASE, combining AI, computer vision, robotics, smart shelves, automated payments, and sensor-based technologies into a single customer experience.

While the technology was ambitious, the greater challenge was defining how customers, technologies, vendors, support processes, and operational teams would work together as a single, coherent service before implementation began.

The Challenge

No commercially proven autonomous telecom retail model existed in the region.

The client needed confidence that a complex ecosystem of AI systems, computer vision, robotics, payment platforms, hardware providers, operational teams, and customer support functions could deliver a reliable, scalable service.

Selecting the right technology was challenging, but the biggest challenge was making an invisible operating model visible.

Before any implementation could begin, the team needed a clear understanding of:

How customers would navigate the experience
How technologies would interact
How vendors would coordinate
How failures would be detected and resolved
Where human oversight would still be required
How accountability would be maintained across the ecosystem

Rather than treating the engagement as a retail design project, we approached it as a systems orchestration challenge. Through research, stakeholder alignment, service blueprinting, operating model design, and failure-mode analysis, we created a shared framework for how the ecosystem would function under real-world conditions.

All diagrams, maps, and visual artifacts were created by me unless otherwise noted.

My Role

Strategy Director — Human Factors & Systems Orchestration

I led the service design, human factors, and systems orchestration workstream.

My role was to understand how people, processes, technologies, vendors, and operational teams would interact across the end-to-end ecosystem and translate those findings into actionable implementation requirements.

Working across six countries and multiple stakeholder groups, I facilitated workshops, aligned business and technical teams, identified risks and dependencies, and converted research insights into operating model specifications, service blueprints, and RFP requirements.

The broader team handled: engineering architecture, API integration, product and AI systems (Amdocs Israel), development and QA (Colombia), and local compliance coordination (UAE).

What I Did

Mapped the Ecosystem

Identified key actors, technologies, vendors, workflows, decision points, and dependencies required to operate the autonomous experience.

Designed the End-to-End Service

Created future-state customer journeys and service blueprints that defined how customers, systems, and operational teams would interact across the entire experience.

Conducted Failure-Mode Analysis

Analyzed edge cases, breakdown scenarios, recovery paths, escalation procedures, and operational risks before implementation.

Defined Human Oversight Requirements

Specified where human intervention, monitoring, support, and governance would be required despite the autonomous nature of the service.

Aligned Cross-Functional Stakeholders

Facilitated workshops and decision-making sessions to create alignment between business leaders, technical teams, vendors, and implementation partners.

Translated Insights Into Implementation Requirements

Converted research findings and operating model decisions into system requirements, RFP specifications, and evaluation criteria used to support the client's investment decision.

Key Deliverables

Human factors analysis
Multi-vendor ecosystem map
Customer journey maps
End-to-end service blueprint
Operating model specification
Failure-mode and risk analysis
Human oversight framework
RFP requirements and vendor evaluation criteria
Stakeholder alignment workshops
Executive decision-support materials

Why This Work Matters

Although this project focused on autonomous retail, the underlying challenge is increasingly common across organizations adopting AI and automation.

Many organizations invest in technology before defining how decisions will be made, how work will flow, who owns accountability, and how humans and machines will operate together.

This project demonstrated how systems thinking, service design, and operating model design can reduce implementation risk by making complex ecosystems visible before deployment.

The same approach now applies to AI transformation initiatives, where success depends not only on the technology itself but also on designing the workflows, governance structures, decision models, and human oversight mechanisms that enable technology to be adopted, trusted, and scaled effectively.

The challenge was never designing a store.
The challenge was designing an operating system that allowed multiple technologies, vendors, and workflows to behave as one coherent service.

The Context

A Problem With No Regional Precedent

In 2023, Etisalat by e& (the UAE's leading telecom provider) set out to build EASE: fully autonomous, staffless retail stores operating 24/7 through AI, computer vision, IoT, and robotics. The ambition was clear. The path was not.

Amazon Go's "Just Walk Out" technology was not commercially available or deployable in the UAE. A turnkey solution would have been the obvious choice — but it didn't exist in the region. That meant the challenge wasn't selecting a platform. It was proving that a completely novel, multi-vendor autonomous retail system could be assembled, specified, and operated as a single coherent whole — before a single vendor contract was signed.

Amdocs was engaged to respond to this competitive RFP, with Accenture as the primary competing systems integrator. I was brought in as Strategy Director to lead human factors and systems orchestration — with three months to go from no regional blueprint to a fully defensible, evaluable system specification.

None of us — including myself — had prior experience designing an autonomous retail system. That meant there was no established playbook to follow and no precedent to borrow from. The diagnostic method had to be built alongside the specification itself.

The insight that defined the engagement:
"This is not about designing a store. It is about designing an operating system composed of multiple vendors that must behave as one."

The Constraint That Shaped Everything

Key constraints made this fundamentally harder than a standard retail design engagement:

No available out-of-the-box autonomous retail technology in the region
Hardware, AI, identity, payment, and operations each required separate vendor partners
Total removal of human staff meant every traditional recovery path — a lost item, a failed scan, a confused customer — needed an explicit system-level owner
Responsibility boundaries and failure modes had to be designed, not assumed, before any build began
The system had to function end-to-end without on-site staff

The RFP, therefore, required more than technical ambition. It required a defensible system specification that showed how a fragmented vendor ecosystem could behave like a single, reliable operating system — and could be evaluated as such by the client.

Vendor Stack

Because no off-the-shelf solution existed in the region, we architected a custom system through a global vendor ecosystem. Identifying, evaluating, and specifying how these vendors would coordinate was a core part of the human factors work — every vendor boundary was also a potential failure point.

Components

Computer Vision & Smart Shelves

Robotic Dispensing

Entry / Exit Gates

Self-Service Kiosks

Ecosystem Integration

Vendors

Trigo (via Amdocs)

Cleveron via SPAN

Amdocs + Trigo

Etisalat / Amdocs

Amdocs

Role in the EASE Store

AI shelf sensors and vision models for pick-and-go tracking

Smart lockers and robotics for secure device pickup

Facial recognition and mobile app-based access control

Device trade-in, plan browsing, and checkout support

Orchestrated APIs, AI systems, app flows, and payments

Diagnostic Approach

Treating an RFP as a Systems Design Problem

Most RFP responses start with the solution. We started with the system.

Rather than proposing technology selections up front, I used the RFP window as a rapid diagnostic — mapping feasibility, risk, and operational realities across every layer of the proposed store before any vendor commitments were made. The diagnostic and the specification happened simultaneously, not sequentially. That compression was intentional and necessary given the competitive timeline.

My approach combined:

Stakeholder workshops with engineering, architecture, operations, vendors, and Etisalat SMEs
Review of Etisalat's existing retail, identity, and payment ecosystems
Analysis of Etisalat brand guidelines and experiential principles — treated as system constraints, not visual inputs
Systems mapping across customer, AI, hardware, vendor, and operational layers
Scenario-based analysis of normal and edge-case behaviors across the full store operating lifecycle
Translation of findings into formal RFP requirements and SOW language in real time as the specification was being written

The pattern that emerged across every vendor track: Orchestration was the core risk, not technology selection. No single vendor could provide all required capabilities. That meant responsibility boundaries, failure modes, and human escalation paths had to be explicit, contractual, and designed before any build began.

Multi-Vendor System Architecture Map

This map was produced early in the engagement to establish a shared model of all actors, systems, and relationships involved in operating the EASE Store — external entities, in-store experience layers, backend systems, hardware providers, Amdocs, Etisalat partner roles, and digital user experience touchpoints.

It became the reference document for structuring vendor interviews and identifying where responsibility boundaries were undefined — where the highest operational risk resided.

Multi-Agent Workflow Architecture & Failure Mode Map

The service blueprint was the backbone of the proposal — a single view connecting customer behavior, AI decision-making, hardware orchestration, vendor responsibilities, and human escalation paths across the entire store operating system.

What it mapped:

Customer layer: Every action from app download through post-exit receipt
Visible touchpoints: Entry gates, kiosks, smart shelves, smart lockers, demo stations
Behind-the-scenes actions: AI decisions, payment flows, session management, recovery systems
Software and systems: IDP, Trigo OS, SAS, billing platforms, POS, SMS systems
Hardware layer: Cameras, e-gates, QR readers, body-tracking systems, SAS kiosks, vending lockers
Data layer: User login states, session QR codes, shopping cart data, order history
Human factors: Remote restocking, remote monitoring, emergency overrides
Risks and gaps: Failure modes identified at each stage
Opportunities: Intervention points for experience improvement

How it was used:

Unified a globally distributed cross-functional team around a single shared operational model
Structured interviews with Trigo, Cleveron, and internal technology leads
Validated scenarios including group entry, failed scans, mixed payment flows, and empty-cart exits
Served as both a design document and an educational tool for vendors and internal stakeholders who had no prior exposure to human factors methods in technical documentation

Failure Mode Analysis: Where the System Could Break

Through service blueprinting, scenario analysis, and requirements definition, I identified and documented predictable failure modes in a multi-vendor autonomous system — embedding them directly into the RFP and SOW as contractual requirements rather than post-launch discoveries:

Gaps between vendors in exception handling and recovery ownership
Identity and session management breakdowns during group entry or mixed payment flows
Inventory discrepancies caused by disagreement between vision systems and weight sensors
Customer trust erosion from opaque error recovery in a staffless environment
Operational blind spots once stores transitioned to remote monitoring

These were not theoretical risks. They were predictable failure modes in a multi-vendor, autonomous system that needed to be explicitly addressed before any vendor contract was signed.

The Human-in-the-Loop Problem

Once a store operates without staff, every failure mode that previously had a human recovery path needs an explicit system-level owner. This engagement defined exactly where AI decision-making ends and where human operator intervention must begin — and embedded those handoff boundaries directly into the RFP and SOW as contractual requirements, not design recommendations.

Stress-Testing the System: Scenario Analysis

These scenarios were not created for user research. They were designed to stress-test two fundamentally different identity verification and session management paths through the same autonomous system — and to expose where the AI decision-making logic would need explicit fallback paths.

Hana is a non-Etisalat customer looking for a phone charger. She has no existing account, no registered payment method, and no prior relationship with the brand. Her journey exposed every assumption the system made about customer identity, onboarding friction, and payment verification for first-time users.

Omar is an Etisalat subscriber upgrading his phone and plan. His journey surfaced the complexity of handling high-value, plan-linked transactions — device selection, payment splitting, trade-in processing, and locker pickup — across multiple vendor systems without a staff member to resolve conflicts.

Together, these two personas mapped the outer edges of what the system had to handle reliably — not the happy path, but the conditions under which it was most likely to fail.

Global Coordination Under Uncertainty

The RFP was also an exercise in cross-functional leadership across genuine complexity. The delivery team that would implement the solution post-win was distributed across six countries — each handling a different layer of the system:

Israel

Amdocs product and AI teams

India

Engineering and test automation

Colombia

Development and QA

UAE

Etisalat stakeholders and local compliance leads

Eastern Europe

Architecture and systems integrations

United States

Strategy, human factors, and facilitation (my team)

Coordinating this team around a shared operational model — with no prior playbook for this type of system, under a live competitive deadline — required the service blueprint and scenario artifacts to function as alignment tools as much as they did as design documents.

Every team needed to understand not just what their layer did, but how it connected to every other layer, and what happened when it didn't.

Agentic Workflow Orchestration: Artifacts & Deliverables

Rather than proposing isolated solutions, I designed a set of human factors artifacts and requirements that functioned as coordination mechanisms across vendors and internal teams — translating real-time diagnostic insight into contractual system specifications that enabled a custom multi-vendor stack to operate as a coherent whole.

Key deliverables:

Multi-vendor system architecture map — full ecosystem of actors, systems, and relationships across the store operating model
EASE Service Blueprint — comprehensive mapping of customer actions, AI decisions, hardware behavior, vendor handoffs, data flows, risks, and human escalation paths across the full store lifecycle
Scenario and failure mode analysis — stress-testing normal and edge-case journeys, including group entry, failed scans, mixed payment flows, non-subscriber access, and remote monitoring transitions
RFP and SOW requirements — user, system, and operational requirements embedded directly into formal procurement language, defining scope, vendor responsibilities, acceptance criteria, testing expectations, and support obligations
Operational readiness definitions — RACI models, SLAs, escalation paths, and post-launch responsibilities across the vendor ecosystem
Executive proposals and presentations — internal alignment and client-facing delivery materials

Organizational Constraints & Decision Context

The outcome validated the approach: Amdocs was awarded the $3M autonomous retail innovation contract, and Etisalat publicly announced the EASE Store concept shortly thereafter.

My role concluded at the bid award. Post-award delivery was handled by regional Amdocs teams consistent with the engagement model.

At the RFP stage, Etisalat and Amdocs leadership were required to commit to a complex, multi-vendor system in a region where no turnkey autonomous platform existed. The system specification I authored ensured that a decision was made with clear visibility into tradeoffs, risks, dependencies, and operational implications.

Impact

The engagement produced durable results:

Secured a $3M autonomous retail innovation contract against Accenture
Enabled Etisalat to pursue autonomous retail without reliance on unavailable turnkey platforms
Established a repeatable operating model for staffless telecom retail using a custom vendor stack
Created a shared system of record used for evaluation, vendor alignment, and delivery planning
Demonstrated the value of human factors analysis embedded directly into technical procurement specifications
Produced the first contractually specified autonomous retail operating model in the UAE

Key Takeaway

When turnkey solutions don't exist, success depends on systems thinking.

"Great product design emerges when system behavior and user experience are designed together — especially in automated environments where trust, clarity, and recovery matter as much as functionality."