VisuallyMeta
← Work

Case study

Cloud Telephony

shipped

Making modern communications easier to manage and efficient, with everything handled in a secure data center off-site.

Role
Product Designer
Outcome
Successfully Deployed and have 15+ customers using it successfully.
When
7 May 2026 — 25 May 2026
Cloud Telephony

The infrastructure everything else stands on

Business phone numbers, IVR, routing, records and billing, built India-first

Role: Head of Design · Scope: Platform UX, role-based dashboards, onboarding, billing and plan logic, marketing website design and build

Context

Every product above depends on this layer. Before a business can run AI agents or audit calls, it needs phone numbers, call routing, recordings and a bill that makes sense. Telephony is usually designed as plumbing: functional, dense and built for whoever configured it first.

Infrastructure products are judged by their edge cases. The happy path is easy. The downgrade, the quota limit and the role that can't see a setting are what define the product.

What the platform covers

  • Virtual numbers (DIDs): provisioning and management
  • IVR builder: call menus and routing logic
  • Call records: history, recordings, search
  • Team roles: admin, manager and supervisor, each with a dedicated dashboard
  • Onboarding: getting a business live
  • Billing & plans: quotas, invoicing, upgrades and downgrades

Key design decisions

  1. Dashboards by responsibility, not by permission. Admins, managers and supervisors don't just have different access levels. They ask different questions. Each role got a dashboard built around what that person is responsible for, not a single dashboard with features hidden.

  2. Compliance built into the core. For Indian businesses, telecom regulation (TRAI/DoT), data protection (DPDP) and GST invoicing aren't optional features. They are built into the core flows instead of added as settings.

  3. Designing the uncomfortable edge cases. Plan logic is where trust is won or lost. For example: when a customer downgrades mid-cycle, what happens to the phone numbers that were included free in their old plan? There's no neutral answer. Revoking them breaks live operations, keeping them costs money, and charging for them surprises the customer. I treat these as explicit, documented decisions rather than leaving them to engineering defaults.

Project log

  1. Empty states are a product decision

    I almost treated empty states as an afterthought. But when I started listing them out for Claritel, I realized every empty state is a moment where the user either gets unstuck or gives up.

    I catalogued 20+ empty states and success states, each with specific trigger conditions, headline copy, and CTAs.

  2. The layer AI won't add unless you make it

    Our left nav was a flat list of ~14 items. Technically fine. Design-dead. Audio Library sat invisibly disconnected from IVR Design — even though it exists to feed IVRs. No badges on actionable items, no grouping, no semantic relationships.

    AI shipped the list. It won't tell you the list has no meaning. Grouping related destinations, surfacing pending callbacks, giving inactive items a reason to relate to each other — that's the thinking you have to bring. The build is cheap now. Knowing what deserves to be built is the whole game.

  3. Starting with Cloud Telephony

    Doing product design for the dialer is teaching me a lot. And with the world moving and adapting to AI, I'm taking a big risk. My deadline for Cloud Telephony is 20 days, and I want to use AI and Claude Code not just to design, but to implement the frontend directly. With current AI capabilities, it feels doable — in fact, I've already tried building a dummy app entirely with Claude Code.

    The risk is clear: if I commit to the AI approach and it fails, it derails my timeline and leaves me unable to fall back on designing and delivering in Figma within the deadline.

    But I'm going to give it a shot. Let's see.

  4. When the requirements are met but the client still wants more

    Context: A bank needed a video calling and scheduling platform for its relationship managers, connected to its existing CRM, with notifications and support for customers in India and abroad. My job was to build a full working prototype, not mockups.

    Why banks need this now

    Two shifts made video banking a priority rather than a nice-to-have:

    1. Bank calls became one-way.
    TRAI now requires banks to make service and transactional calls from the dedicated 1600 number series, so customers can tell a genuine bank call from a fraudulent one. That helps with trust, but these numbers don't take incoming calls. A customer who misses an RM's call can't simply call back. The bank needs a channel where the conversation is scheduled and two-way.

    2. Banks are competing for NRI customers.
    The RBI's special FCNR(B) deposit window in 2026 let banks offer NRIs higher rates on foreign currency deposits, and lenders began engaging more actively with NRI customers across key overseas markets. Those customers are in different time zones and countries, often unable to visit a branch, and expensive to reach by international phone call. A scheduled video call with their RM fits their situation far better. socialnews

    Regulation made outbound calls more trustworthy but harder to call back. NRI demand made distance the main obstacle. Video banking addresses both.

    What I did

    • Built the prototype end to end with Claude Code.
    • Covered every requirement in the brief.
    • Demoed it live to stakeholders as a working product rather than a slide walkthrough.

    What happened

    The prototype met their needs as written in the brief. The client still wasn't satisfied. They wanted a "cherry on top": something beyond the brief, and in some cases beyond what current technology can do.

    Meeting the requirements isn't the same as meeting the expectation. A brief records what a client can put into words, not what they imagine.

    What I'm thinking about

    • Was the gap in the brief or in the moment? A working prototype makes the possibilities feel real, so the client starts imagining further. That reaction suggests the prototype did its job.
    • Separating the impossible from the unfamiliar. Some of what sounds impossible is possible but hasn't been done in banking yet. Finding the one feasible thing in the wish list could be the real cherry.
    • Where to draw the line. Chasing features the technology can't yet deliver risks the project. The skill is saying "not yet" in a way that keeps the client excited.

    Status: Open. Let's see where it goes.

Next projectMarketing →