Building flexibility

Onboarding at a company requires specific attention to processes that can be improved using the unique perspective that being new to something provides. At my last position, we had a system to build automated communications for anyone who received a diagnostic kit from us. This allowed us to offer enterprise customers great control over how they wanted us to communicate with the members who had had a kit purchased on their behalf. The problem with this process was that there was no way for us as a business to respond to our customers request to communicate with members outside of the pre-contracted build. Requests like these required engineers to run a script to grab the data needed to see who we should communicate with and then a separate script that ran that data to our communications platform to send those messages.

There had to be a better way. And with software, there usually is. The team and I developed an application that would allow any team member the ability to send communications to members at any time for any reason. This required creating new models within our business’s primary monolith to store each ad hoc request and creating a new worker to house the logic of finding the user data necessary to send a communication to a member who had not yet returned their kit, including scoping by shipped date, state, gender and age. We then exposed these models and workers through an API that could then receive requests from our new front end application written in React.

However there was a snag. In the original design, a user would have to use the application 3 different times for the same request if a partner wanted to send different kinds of communications. For example, a partner might want to remind their members with an email as well as a text message and a phone call. If we shipped the original design, a user would need to use the tool once for the email and then again for the text message and finally for the phone call. I knew that as a user I would find this experience incredibly tedious. I wanted build a tool that would be a delight to use. So I proposed that we add support to send multiple requests with one input of the user. This required creating an additional model that would store the kind of communication that was being sent with the ad hoc request, related to the parent object with a one to many relationship. We adjusted the worker logic to iterate over the associated communication type objects to send the appropriate message to our messaging platform. On the front end, I created a button that would allow a user to create as many communication type inputs as needed and wrote logic to communicate this to our newly minted API.

The result was a tool that unlocked the operations team the ability to communicate with members about their pending kits without requiring engineering support. By spending a little more time on a more complex implementation we empowered our team members to do more with less. And we delivered an application that was easy to use. They could use the tool to respond to our customers requests and engineering was freed to focus on continuing to enhance the platform and build new features.