The ScriptBuilder is a tool to automate the process of creating and updating the sales scipt for our Sales Operations and Sales Leadership team.
ScriptBuilder
-
Role
Product Designer -
Duration
1 Month -
Cross-Team
ProductSales OpsSales LeadershipCompliance
Problem
Every year Medicare plans change, those changes need to reflect on our sales script. These changes happen over multiple months of the year in preparation for the upcoming Annual Enrollment Period (AEP). To get these updates done, there are many stakeholders involved. There are also multiple repeated steps and multiple approvals, which means a lot of back and forth, this bottleneck uses up most our time and resources.
Solution
Build a tool where all the stakeholders will have one place to complete their responsibilities related to the sales script. From script creation to compliance approvals.
Context
The sales script is the most important project our team works on every year. It is used by 1,200 agents daily, it's a tool that guides agents to ask the customer the right questions in order to recommend plans that the they are eligible for.
Updating the sales script every year means a lot of teams involved and a lot of back and forth. This is where most of the time is used. Meetings and reviews, and although we have tried to make changes and automate some process to lessen the time, like shareable documents and regular scheduled meetings, there are still some things that are out of our control. For example: carrier approvals, legal approvals and compliance approvals.
Process
Understand the Scope
We've kept a pretty good record of the most common changes in the sales script that happens almost every year, and where the friction point of the process that takes the most time. We needed to think about (1) what we could automate. (2) What some teams can do independent of other teams.
For example: changing small copy, like adding “(POA)” and the end of every "Power of Attorney" on the script.
Another reason why we update our sales script that happens quite often is Carrier requests. Some carriers have special instructions and specific prerequisites for some of their plans, we must include these requests in the sales script but before we could do that, we need to make sure that these changes also abide by government rules. This means it will require reviews and approvals from our legal team.
Collaborators
With all the teams involved in creating the sales script, we needed to make sure that every key stakeholder in the process will find this tool useful and that they are able to do what they need within the tool. This is continuing our process in defining the scope.
The ScriptBuilder’s Anatomy
We dissected our script into blocks. Each block has a question and a type of answer, like checkboxes, radio buttons, and calendars.
Brokendown, A script consists of pages, that consists of questions and those questions need to have widgets.
We had to create components as our building blocks. The goal was to create components in it’s simplest form so that we can reuse as many components we have and create any combination. We had to go very simple, almost like building our own design system.
Design System
We were building a design component library that is very similar to a design system a designer would be familiar with. The difference is, instead of designers, sales ops were going to use the components. The components were going to be in the ScriptBuilder, and the sales ops team can choose a component they want to use for their script.
Widgets
We started off with predefined components that we called "Basic Widgets". These are your typical UI components like radio button, text area, dropdown widgets. We then added custom widgets that are specific to in our script. From the current script, there were some components we couldn't build from scratch. We considered them "Custom Widgets."
Drag & Drop
With the theme of simple, our interaction also needed to be simple and very easy. I had to keep the user in mind at all times, these users were not as technically savvy as someone that builds a website on a CMS. Creating the script is the main task this tool needed to do. The drag and drop interaction helped our main users to do their task fast and easy.
Additional Attributes
Once all the building blocks were set, we wanted to optimize them. This phase in the project we worked closely with engineers that built the script in the past. We wanted to understand how they built the script and some requirements that they had like form validation and shortcodes to make the script more dynamic.
These examples show what it looks like when a question requires an answer, or needs a tooltip. We also added the ability to use shortcode to display copy on the script to be more dynamic.
Other Features
There were many features that were included in the MVP requirements like a script dashboard, where we can create multiple scripts for different product lines. We also needed to create a Permission and Roles feature since the script is a sensitive document within eHealth. The ability to add upload a spanish version of the script, even when to deploy the script on specific environments.
This project was really thought out, working very closely with the PM, we really had to think about what features will be included in the MVP
Recreating the Script
After development, we needed to test this tool. The major test we did was recreate the existing Medicare Advantage script using the Scriptbuilder. Once we created it, we considered this a successful MVP for the ScriptBuilder.
Takeaway
More Time, More Features
This project has a lot of room to scale. In the MVP we weren't able to add the approval option for the Compliance team. As a workaround, they became a "viewer" of the script and still approve a script via email.
Another feature we did not include in the MVP is the collaboration between sales ops individuals. Similar to any word processing application, we wanted more collaborations like sharing the same file and working synchronously. These features will have to be added in the next update of the ScriptBuilder.