Bulk Actions landing: Change existing lines and Add new postpaid lines

Redesigning the bulk SIM activation experience from a manual process to an automated one.

Thousands of SIM activations, processed through email chains and manual data entry across three disconnected systems. One invalid record was enough to restart the entire batch.

OmantelTelecomB2B
Company
Omantel
Problem
Manual bulk activations
Focus
Reliability · Scale

Overview

Impact

  • Reduced batch creation and submission time by half using a template-based system.

  • 0 operators

    Required for Batch creation, request submission and error validation.

    Redesigned the fully manual experience with a single self-service flow.

  • -48hrs → 0

    From days to seconds Batch activations of up to 500 SIMs now confirm within the session — replacing a process where operators waited days for email confirmation with no visibility in between.

Overview

Omantel is Oman's national telecom provider. Work spanned a B2C eShop and a B2B bulk activation platform: enterprise customers need to activate, modify, or deactivate SIM services in bulk — hundreds of records at a time, governed by strict eligibility and credit rules.

The existing process ran entirely on email. A company rep would send a request to the Omantel team, who would manually verify details against a separate backend system, re-enter the data into the portal, generate the batch — and discover errors only after submission. Every request meant tab-switching between email, the backend, and the portal. Every error meant starting over.

There was no defined scope for research, as the vision was pre-defined from the business side.

Problem

Current scenario
Before

A company rep emails Omantel. An internal team member opens the mail, switches to a backend system to verify eligibility, switches to the portal to manually enter data, generates the batch — and discovers errors only after submission. Invalid records restart the process. Every bulk request requires staff time.

After

The company rep submits directly. Eligibility and credit limits validate inline, before the batch is created. Errors surface at the point of entry, not after failure.

Understanding the existing scenario

We were dealing with two sets of pain points — Omantel's and their business customers. It took some discussions to understand what a typical B2B telco journey looks like.

Conceptual map of B2B telco bulk activation — credit limits, enterprise process flow, and user guard rails
Conceptual understanding — credit limits, bulk activation process, and stakeholder guard rails.

Pain Points of the Business Customer

  • High Error Rate
  • Long Turn Around Time (TAT)
  • Inefficiency in Handling Bulk Requests
  • Lack of Automation
  • Difficulty in Managing Multiple Numbers
  • Limited Flexibility

Pain Points of Omantel

  • Operational Risk
  • Resource Intensive
  • Reduced Work Efficiency
  • Increased Human Errors
  • Lower Productivity
  • Inability to Scale

Mapping the User flows

A walkthrough of the entire manual process from Omantel's staff allowed us to put ourselves in their shoes, gather a better understanding of their pain points in the journey. They were juggling between three different platforms — a back office, a CRM, the customers mails.

Key Decisions

Key decision

Redesigning the manual batch request process to a self service system

Two input paths in one interface: CSV templates for bulk preparation offline, and a search-and-modify flow for quick single-record changes.

Rationale
  • Enterprise users already work in spreadsheets. The idea is to meet them there rather than reinventing the wheel — reducing the learning curve and adoption friction. Addressing both scenarios — smaller batches (less than 100) and large batches (goes up to 500 or even more) — through the self-service journey.
Impact
  • The entire manual entry pipeline was replaced with self-service. Company reps have zero dependency on internal staff for a clean batch submission and negligible wait time.
Key decision

Reducing error risk through context visibility and early validation

In the manual process, a single invalid entry could fail the entire batch and the operator would have to go through the entire process again. The users would receive confirmation regarding batch submission in a span of 48-72hrs.

Rationale
  • Two micro decisions — 1. Surfacing errors at the form level and file-upload stage would allow room for recovery and reduce the scope for errors. 2. Providing the context of the existing value against the value being updated would reduce reliance on memory and eliminate unnecessary overwrites.
Impact
  • The model shifted the error-handling from recovery to prevention. Bulk operations became reliable at higher volumes without increasing the cognitive load on the user.
Key decision

Tracking batch submissions independently

Enterprise users need to return later to verify outcomes or explain changes internally. A unified history view was designed to surface: overall batch status, individual order status within a batch, mixed outcomes when a batch contained both completed and in-progress requests.

Rationale
  • Dependency on Omantel staff for progress and updates added a layer of friction to the process. Making the system transparent meant making it trustworthy over time.
Impact
  • Bulk actions became traceable and verifiable. Users could self-serve status checks instead of raising support tickets. Users could refer to batch history details for internal discussions, planning their own timeline / making future changes.
Key decision

Limiting bulk actions on mobile

The experience needed to work across devices, but presenting hundreds of records on mobile risked turning simplification into confusion. Mobile was intentionally scoped to: creating or requesting new lines, updating a small number of known lines via manual search. High-volume bulk updates remained desktop-only, supported through structured CSV templates.

Rationale
  • The mobile was meant to support quick modifications or as a tool for reference. The Desktop experience remains the primary environment for high-volume actions.
Impact
  • The experience avoided cognitive overload on mobile while still supporting meaningful on-the-go actions. No features were broken by being forced into a screen size they weren't designed for.
Key decision

Ensuring error prevention through data validity

Using outdated/ invalid data to place batch requests can be a very costly mistake. To make it easy for enterprise reps to keep track of the latest data (associated with the numbers)- a logic was set for the system to self validate the data and prompt the user based on the same.

Rationale
  • The user will be informed by the system regarding outdated data and redirected to download the template containing the latest data. Reducing the effort required to recall information — keeping context intact.
Impact
  • Increasing efficiency by eliminating the need for the user to remember the latest data associated with each number.

Reflection

Reflection

To me this project was a good example of what proactive collaboration should look like.

  • With more time, I would have pushed for a lightweight usability study with 2–3 enterprise reps before final handoff — even without a formal research phase, watching someone navigate the journey would have surfaced friction I may have missed.
  • I would have also explored batch-level progress indicators for large uploads where processing time becomes noticeable.
  • Given the complexity that AI can perform — there are parts of this process that could have been made smarter such as the tracking, surfacing business rules to the user etc.