This project focused on a bulk connectivity solution introduced for the Omani market, where sharing Wi-Fi connections across tenants is restricted by regulation. The product enables real estate owners to purchase and manage internet services for multiple residential units within a building. My work was scoped to the initial purchase flow on the Omantel website, where real estate owners select a combination of units and bandwidth plans when setting up connectivity for a property. As this was a new offering, the first phase supported a predefined set of recommended unit bundles. Requests for custom unit counts were routed to internal teams for further evaluation. A key consideration during this stage was helping owners understand that this was not a fixed or irreversible decision. After purchase, owners would have access to a management platform where connections could be started, modified, or paused for individual tenants, allowing connectivity to function as a managed building amenity.
Problem
From a business perspective, this solution represented a shift from individual household subscriptions to a higher-value, multi-unit offering. The goal of including this flow within the platform was to enable expansion, reduce dependency on manual sales processes, and ensure consistent application of pricing and regulatory rules.
For real estate owners, the purchase decision involved both cost and responsibility. Internet connectivity was positioned as a building amenity, and owners needed clarity and confidence that they could manage services for different tenants over time, rather than committing to a rigid, one-time configuration.
From an operational standpoint, the existing process relied heavily on offline coordination through email, which increased turnaround time, introduced the risk of miscommunication, and placed additional load on internal teams.
Understanding the existing scenario
Prior to this, real estate connectivity plans were presented as a static table on the Omantel website. The table outlined standard unit and bandwidth combinations, but did not support configuration or direct purchase.
For cases that did not match the listed options, real estate owners were required to contact Omantel through email. This resulted in manual coordination to clarify requirements, pricing, and feasibility before a request could be processed.
As a result, the digital experience functioned primarily as a reference point, with the actual transaction and validation occurring offline through internal teams.
Constraints
This was more of a placement constraint: the solution was required to replace an existing static table on the Omantel homepage. This meant the experience needed to fit within a predefined section of the page, rather than being introduced as a standalone flow or separate journey.
Key Decisions
- Progressively guide users through available unit and bandwidth combinations, prioritizing clarity and making sure that the user understands all possible options upfront. Presenting all packages, combinations, and service constraints at once risked overwhelming users and increasing decision friction.
- Allowing owners to actively configure packages within the website helped shift the experience from passive comparison to active decision-making, increasing confidence in the selected configuration before purchase. This reduces: • fear of commitment • post-purchase regret • dependency on offline reassurance
- Earlier explorations treated configuration as a distinct step—users would first view standard plans, then move into a separate package-building flow to configure units, review pricing, and request a callback. While this separation was logically clean, it introduced unnecessary context switching for a decision that required frequent reference back to standard plans and pricing anchors.
- This allowed users to: • reference standard packages while configuring a custom plan • understand how custom selections mapped to familiar benchmarks • maintain continuity without navigating away or restarting the flow and avoided loss of context
- From a system perspective, capturing location information early would have filtered out non-serviceable users quickly. However, it would also have prevented visibility into interest and demand from areas not yet covered by the service.
- From a user perspective, this introduced a risk of perceived wasted effort if a location was not yet serviceable. However, placing location checks later ensured users first understood the value and structure of the offering before encountering availability constraints.
- 1. This approach supported both business planning and user clarity, while acknowledging a calculated amount of upfront user effort as a trade-off. 2. Helped the team understand demand and plan future services efficiently based on the same.
Outcome and Impact
Enabled a more self-serve entry point for real estate connectivity, reducing reliance on offline coordination for early-stage configuration.
Improved clarity around available packages, service constraints, and next steps within a single-page flow.
Captured structured demand signals for locations and configurations beyond current service availability.
Reflection
1. This project reminded me of the importance of designing within real operational and business constraints. This wasn't a project about idealised user flows. Many of the decisions were less about adding capability and more about sequencing information, managing expectations, and preserving continuity in the decision-making process for the users. 2. This project highlighted how product experiences often sit at the intersection of regulation, backend readiness, and user trust. 3. Overall, this work shaped how I approach complex B2B flows—focusing on clarity, sequencing, and decision support over feature breadth.
Visuals