Admin Tool
Before this, only engineers could manage which customers had access to which AI features — usually by hand, in code. We built an admin UI so anyone on the team could manage customers, feature access, and the API connections tying it all together.
Customers
Managing which customers had access to which AI features meant engineers making the change directly in code — slow, and it didn't scale as the customer base grew.
Built an admin UI for managing customers, toggling AI feature access per environment, and testing the API connections between each customer's AI Assistant and the legacy platform.
Support tickets dropped 60% — role-based permissions let customers safely self-serve their own settings instead of filing a ticket.
Problem
As the number of customers connected to the AI Assistant grew, someone still had to manage all of it by hand — which company had which features, whether their API connections were actually working. That someone was always an engineer.
Feature access required engineering — turning an AI feature on or off for a customer meant changing it directly in code.
No visibility into connection health — nothing showed whether a customer's AI Assistant and the legacy platform were actually talking to each other.
Didn't scale — as the customer list grew, routine account changes turned into a steady stream of engineering requests.
Research
This tool actually serves three different audiences — our system admins who manage every customer, engineers who think in terms of environments and API connections, and customers themselves, who just want to manage their own company. The design had to work for all three without feeling like three tools stitched together.
Role-based permissions, not one-size-fits-all
Our system admin sees every company. Each company's own admin only sees their own users and controls — enough access to self-serve, not enough to reach into someone else's account.
Environment-aware, not just customer-aware
Feature flags and API status are shown per environment — Development, Test, Production — since rollouts happen gradually, not all at once.
Make connection health visible and testable
A one-click test for every integration, so a broken connection shows up before it becomes a support ticket.
Design
Features · Mt Pleasant
The tool covers three things. A searchable list of every customer company, with status and quick actions. A per-customer configuration and features view, where flipping a toggle turns an AI feature on or off for that company, in a specific environment. And a live API management view, showing every connection — database, payment gateway, messaging queue, cache, storage, email — with its status, latency, and a one-click test, per environment.
Underneath all of it is role-based permission control. Our system admin sees every company. Each company's own admin only sees their own users and controls — enough access to self-serve, not enough to reach into someone else's account. That's what let a broken connection between a customer's AI Assistant and the legacy platform become something anyone could spot and test, not just an engineer with database access.
Outcome
Support tickets related to account and feature-access changes dropped by 60%, once customers could make those changes themselves instead of filing a request. Role-based permissions were what made that safe — customers could self-serve within their own company without ever seeing or touching anyone else's.
What we learned
The real win here wasn't just moving work off engineers' plates — it was giving customers enough visibility and control to solve their own problems, without giving them access to anything that wasn't theirs. Getting that permission boundary right mattered more to the outcome than any single screen in the tool.
