The #ops-requests channel
Every fintech of a certain age has one. Ops post requests: can someone update this customer's registered address, the app will not let them. Can someone unlock this account after too many failed logins. Can we get a list of customers who received the fee refund. Can someone change this payment's status, it is stuck.
An on-call engineer picks them up between other work. They open a database client, write a query, run it in production, and reply with a thumbs up. Sometimes they paste a result table into the channel. There is no record of the change except the message.
Why the admin panel never caught up
The first admin panel was built in the weeks before launch with the actions founders needed then. Since then the product has grown and ops has grown, but the panel is nobody's priority, because every engineer's roadmap is customer-facing.
- New ops tasks appear faster than admin features get built.
- Some tasks look simple but touch several tables, so nobody wants to expose them carelessly.
- Direct SQL is quick for the engineer in the moment.
- Nobody has counted the requests, so the cost is invisible.
The risk and the drag
Every hand-run query in production is a chance for a typo with real consequences, and a change with no record behind it. When a partner or auditor asks who changed a customer's details and why, the answer is a Slack message, if you can find it. Engineers lose focus time. Ops wait, and so do customers.
There is also a people cost. Ops staff who cannot fix things themselves feel stuck, and engineers resent being a help desk.
From SQL requests to safe admin actions
What we build turns the requests you get most into proper admin actions, with the checks and records an engineer's query does not have.
- We go through the request channel history with you and group requests into types, with a rough count of how often each comes up.
- For each common type, we write a named action, such as update registered address or unlock account, that calls your product's services or APIs rather than editing tables directly.
- Each action validates its inputs, shows ops a preview of what will change and asks for a reason.
- Sensitive actions, such as changing a payment status or a balance, need a second person to approve.
- Every action records who ran it, when, why and what changed.
- Read-only lookups ops currently ask for become saved reports in the tool, with personal data shown only to the roles that need it.
- Anything still unusual stays as an engineer request, now through a form that records it.
| Request type | Becomes | Approval |
|---|---|---|
| Update customer details | Admin action with preview | Single, with reason |
| Unlock or reset login | Admin action | Single |
| Correct a stuck payment status | Action that re-checks with the provider first | Second person |
| Balance adjustment | Ledger adjustment action | Second person, value limits |
| Customer lists for campaigns or refunds | Saved report | Role-based access |
The tool can be built in Retool if your team already uses it, or as a small custom app. Either way it calls your services, so business rules stay in one place.
A quieter request channel
Ops handle most of their daily fixes themselves, with a preview before each one and a record after. The request channel gets the genuinely unusual cases, which engineers are happy to look at.
When someone asks what happened to an account, the admin tool shows every change with the person and the reason, which is a much better answer than searching Slack.
Does this describe your ops and engineering?
- Ops post daily requests for engineers to change data.
- Engineers run queries directly in production.
- The only record of a change is a chat message.
- The admin panel has not had a new feature in months.
- Nobody knows how many requests come in each week.