Support by Slack message to a developer
A customer needs their account moved to a new email address. Another wants a deleted project restored. A third asks why their invoice is wrong. Support cannot see or change any of this, so each one becomes a message to a developer: "can you look up this account?", "can you run the fix?". The developer stops what they are doing, opens the production database, runs a query and hopes they typed it correctly.
It works, slowly. Customers wait. Developers lose focus several times a day. And somewhere in the background is the thought that one mistyped query on production could do real damage.
Why admin tools never got built
Early on, the founders or first developers handled support themselves, with direct database access. Building an admin panel felt like a distraction from the product customers pay for. Then the team grew, support became someone else's job, and the gap appeared.
Internal tools also have no obvious owner. They do not appear on the product roadmap, they are not visible to customers, and they are always slightly less urgent than the next feature. So they keep not happening.
What manual support costs
| Cost | Effect |
|---|---|
| Developer interruptions | Slower feature work, broken concentration |
| Customer waiting time | Simple requests wait for a developer to be free |
| Risk of damaging data | Hand-written queries on the live database |
| No audit trail | No record of who changed what for which customer |
| Wide database access | More people with production access than should have it |
The access point matters for security reviews too. Larger customers will ask who can see their data and how it is logged, and "several developers, directly" is a hard answer to give.
How we build SaaS admin tools
- List the real jobs. We go through recent support requests and developer interruptions and group them: lookups, account changes, resets, restores, billing adjustments, data corrections.
- Build search and account views. Support can find any customer and see their account, users, plan, usage and recent activity on one screen.
- Turn frequent fixes into safe actions. Each common job becomes a button or form with validation, a confirmation step and a clear explanation of what it will do, instead of a hand-written query.
- Add roles and permissions. Support, finance and engineering see and do different things. Sensitive actions can require a second person's approval.
- Log everything. Every view and change is recorded with who did it, when and why, which also helps with security questionnaires.
- Allow safe impersonation. Where useful, support can view the product as a customer sees it, with the session logged and restricted.
- Pick the right way to build it. For some products an internal tool builder such as Retool is enough. For others we build the panel into the app itself, so it shares its permissions and business rules.
We also remove the need for direct database access for day-to-day support, which shrinks the list of people who can touch production.
What support looks like with proper tools
The admin panel also becomes a place to spot patterns. When the same action is used over and over for the same reason, that is a sign the product itself should handle it, and the log shows you exactly how often it happens.
Support resolves most requests themselves, straight away, while the customer is still in the conversation. Developers are interrupted only for genuine bugs. Changes happen through tested actions instead of typed queries. And every change leaves a record, so when a customer asks what happened to their account, you can tell them.
Is this how your support works?
- Support regularly asks developers to look things up or fix data.
- Developers run queries on the production database for support requests.
- There is no record of changes made to customer accounts.
- Customers wait for simple fixes because a developer is busy.
- More people have production database access than you would like.