Aheeva is a contact-center SaaS provider whose customers are themselves operating contact centers — managing seats, billing cycles, and account changes on Aheeva's platform. Aheeva needed a customer-facing portal where their own customers could see and manage their subscriptions without going through Aheeva's support team.
The clarifying scope point: Linescripts built the portal that Aheeva's customers use to manage their relationship with Aheeva. It is not an internal back-office tool; it is the surface Aheeva's downstream customers interact with directly.
The Challenges Aheeva Faced
- Every routine account change went through Aheeva support. Seat changes, plan upgrades, billing-address updates, invoice retrieval — all support tickets. The support team became a bottleneck for routine self-service work.
- Billing visibility for the customer was poor. Customers couldn't easily see their own subscription history, invoices, or upcoming charges without asking.
- Back-office and customer-facing data drift. The risk in this kind of portal is that the customer sees one version of their subscription and Aheeva's back office sees another. Reconciling drift would have undone the value of the portal.
- Account-level user management. Each Aheeva customer is itself an organisation with multiple users on its own side. The portal needed first-class organisation-of-users semantics, not just a per-person login.
How Linescripts Built the Solution
Customer-facing subscription portal
A portal where Aheeva's customers log in to see their account, their active subscriptions, their billing history, and the controls they need to manage routine changes themselves — without a support ticket.
Subscription lifecycle visible to the subscriber
Customers see their subscription's current state, renewal date, upcoming charges, and history. Plan changes and seat adjustments happen through portal actions rather than email-to-support workflows.
Billing self-service
Invoices, payment status, and billing-address management are first-class portal features. The customer can pull their own invoice without contacting anyone.
Organisation-of-users model
Each customer is an organisation with multiple users on its side, each with appropriate permissions (admin, billing contact, technical contact). The portal supports the actual shape of how the customer's company works rather than forcing a single-user model.
Single source of truth with Aheeva's back office
The portal reads and writes against Aheeva's back-office system. There is no separate subscription store, no nightly sync, no risk of the customer and Aheeva seeing different states. Everything the customer sees is what Aheeva sees.
What Changed for Aheeva
- Routine account changes stopped being support tickets. Customers handle seat changes, plan upgrades, address updates, and invoice retrieval themselves.
- Support load shifted to the work that actually needs humans. The team's hours moved from administrative ticket work toward substantive customer success.
- Customers can see their own billing state. Transparency at the subscription level reduced billing disputes and follow-up.
- Portal and back office stay in sync by construction. No drift, no reconciliation, no "let me check with our system" moments.
Closing
The portal is the visible deliverable, but the architectural decision that made it work was reading and writing against the same back-office system the support team uses, rather than a separate portal database that would have needed reconciliation. One source of truth, two surfaces — Aheeva's support team and Aheeva's customers — both looking at the same data.