Context
Stanchion Payment Solutions runs a 24/7 payments operations team. When a client's service has an outage, the team has to find the right contact and escalate it to the client by email, fast. SwitchAssist is the internal tool I built for that team. It holds escalation contacts and client notes, runs the daily checks, tracks announcements and generates emails from templates. It did not exist before I built it, and the dev team still runs it.
My role
My title was Junior Postilion Engineer, and I worked in the operations team itself, not in the dev team. I built SwitchAssist after running into its problems as a user on shift.
- I designed and built the app end to end: the Nuxt front end, the Supabase data model and the Vercel deployment.
- I worked with team leads and managers on what it needed, since they own the contacts and post the announcements.
- When I left, the dev team adopted it and kept extending it.
Problem
The team's working knowledge was spread across places nobody owned. Escalation contacts and client notes were scattered and went stale, so finding the right person during an outage took time. Daily checks were tracked in a legacy tool, Stanchion Checks, and checks still went overdue. Announcements went to a Teams channel, and people on other shifts missed them. None of this was anyone's fault. The tools made it easy for things to go stale, overdue or unread, and hard to notice.
Constraints
- Round-the-clock shifts. The team works 24/7, so a message posted on one shift has to reach people who start hours later.
- Live operations. The team could not pause to change tools. Checks and escalations had to keep running while SwitchAssist replaced Stanchion Checks.
- Built from outside the dev team. I was an operations engineer, not a member of the dev team, so the tool had to be small enough for me to build and run myself.
- Confidential client data. It holds client contacts and notes, so it stays internal and screenshots are withheld.
Approach and architecture
SwitchAssist is a Nuxt app written in JavaScript, styled with Tailwind CSS and deployed on Vercel. Supabase holds the data: contacts, clients, events and notes. It has four parts, one for each problem.
Contacts and client notes
Each client has one record with its escalation contacts and notes. Team leads own and edit them, and everyone else reads the same version. That ended the stale links and notes, because there was one copy and a named owner.
Scheduled checks
Daily checks are scheduled in the app. It sends reminders when a check is due, and the team signs each one off. This replaced Stanchion Checks.
Announcements
Team leads and managers post announcements in SwitchAssist. Each person is pinged at the start of their next shift and has to acknowledge the announcement before they can use the app.
Email generator
Client emails, such as outage escalations, are generated from templates, filled in with the client's details, so nobody writes them from scratch during an outage.
Key decisions and trade-offs
Acknowledgement gates the app
- Chose
- Block the app until the latest announcement is acknowledged
- Over
- A notification people could dismiss, like the Teams channel
- Cost
- A moment of friction at the start of a shift, even when someone was in a hurry
Announcements in a Teams channel were easy to miss, and a dismissable notice would have had the same weakness. Making acknowledgement a step before using the app meant nobody could miss one without noticing. The cost was small because the app was already part of every shift.
Team leads own the contacts
- Chose
- Team leads edit contacts and client notes, and the team reads them
- Over
- Letting anyone on the team edit, like a shared document
- Cost
- A change on shift has to go through a team lead
The old contacts went stale partly because everyone could change them and nobody was responsible for them. Giving each record a clear owner is what kept them current.
Replace the legacy check tool
- Chose
- Rebuild daily checks inside SwitchAssist, with reminders and sign-off
- Over
- Keeping Stanchion Checks and adding reminders around it
- Cost
- Moving every check across and changing a habit the team already had
Checks went overdue in Stanchion Checks because nothing prompted anyone until it was too late. Putting checks in the same app as announcements and contacts meant the team was already looking at it on every shift.
Outcome
Stanchion reported all three measures monthly. The before figures are monthly averages over four months before rollout.
Average time to escalate an outage to the client went from about 30 minutes to about 5. The same tool measured both periods: it matched each outage's start time to the send time of the client's escalation email in Outlook.
Missed daily checks went from about 13 a month to none. The before figure is the monthly average in Stanchion Checks, the tool SwitchAssist replaced. After rollout, no checks were missed in SwitchAssist's first two months.
Announcements left unacknowledged went from about 12% to 0%. Before, the manager counted who hadn't read or acknowledged each one from Teams analytics. After, 0% is true by design, because the app can't be used until an announcement is acknowledged.
Beyond the numbers, contacts and notes stopped going stale because team leads own them in one place. The dev team adopted SwitchAssist and kept extending it after I left.
Reflection
The thing I'd change is the language. I wrote SwitchAssist in plain JavaScript because I was building it alone and moving quickly. The code didn't stay mine. The dev team took it over and kept extending it, and TypeScript would have given them the data shapes and contracts in the code instead of in my head. I now start projects in TypeScript, and the reason is the next person who has to change the code.
What I took into later work is where good internal tools come from. I didn't need a brief, because I had the problem every shift. The same position let me measure the before and after with numbers the team already trusted.
Write the code for the team that inherits it, not only for the team that uses it.
