Designing a Staffless Retail Operating System

How Systems Thinking Helped Win a $3M Innovation Bid Against Accenture

Client Engagement · Stellar Elements (Amdocs Studio) · 2023

| $3M innovation contract secured | 3 months from blank slate to full system specification | 6-country distributed team coordinated under a single operational model | Accenture as primary competing integrator |

Overview

Role: Strategy Director — Human Factors & Systems Orchestration

Client: Etisalat by e&

Employer: Stellar Elements (Amdocs Studio)

Industry: Telecom / Autonomous Retail

Engagement Type: Competitive RFP Strategy, Human Factors Analysis, Multi-Vendor System Specification

Focus: Multi-vendor orchestration, failure mode analysis, human-in-the-loop guardrails, cross-functional alignment

Tools: MIRO, Zoom, Figma, Microsoft Word, Trello, Slack, PowerPoint

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

My Role

I was responsible for connecting technical feasibility with human experience and business goals. I led all human factors analysis, systems orchestration, and facilitation work for the engagement — directing a service designer embedded in the project and owning the translation of human factors findings into contractual system specifications, RFP requirements, and SOW language.

This engagement produced no screens or UI. The work was system-level: defining how customers, AI, hardware, and vendors would interact across an operating model that had never existed in the region before.

I was solely responsible for:

Human factors journey maps for both Etisalat and non-Etisalat customers
The full service blueprint mapping customer actions, AI decisions, hardware behavior, vendor handoffs, and human escalation paths
Scenario and failure mode analysis for normal and edge-case operating conditions
Technical writing for the RFP — translating human factors findings into defensible system requirements and SOW language
Facilitation of co-creation workshops with internal teams across 6 countries and Etisalat stakeholders
Executive proposals and presentations for internal alignment and client delivery
Assumption and risk mapping to surface failure points before build

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

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.

Component

Computer Vision & Smart Shelves

Robotic Dispensing

Entry / Exit Gates

Self-Service Kiosks

Ecosystem Integration

Vendor

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

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.

Diagnostic Approach

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."