Intro

Everyone familiar with “Sales” understands the profession’s reliance on Salesforce as a must-have piece of software. Boasting the ability to track prospective-deals, contract-renewals, and overall account-management, Salesforce seemingly has no answer for the question, “what can’t I do?” with regards to sales. As is common with many CRM systems, however, the breadth of what users can do often eclipses the need a frictionless experience when navigating and interacting with the limitless possibilities. At Troops our goal is to empower users with intelligent, conversational software that acts as an assistant of sorts, mitigating friction and delivering business-critical information from Salesforce, to users in Slack, on demand.

Background (General)

As organizations mature, the need to establish approval processes that provide oversight into how deals are getting done becomes immediately apparent. These processes are usually enacted after a period of either no deal-oversight (i.e. the wild west) or a more controlled, albeit ad-hoc, informal approval-chain (i.e. tap the shoulder of the CEO, email threads). Either way, the implementation of an approval process is often reactive, put in place after noticing a sales-cycle inefficiency. In implementing approval processes, sales-teams hope to identify areas for improvement, ultimately developing a more stable, predictable, and streamlined path to closing deals.

Background (Troops)

A large number of our customers requested that Troops support the Approvals use case. These were all customers that either existed in the mid-market (MM) tech segment (300-700 employees using internal tiering-definitions) or were rapidly growing and would soon (most likely) enter that tier. Additionally, several deal-cycles stalled with potential MM customers who noted the lack of an approvals feature as an objection to buying.

From a product-vision standpoint, we believed supporting Approvals would get us closer to both capitalizing on our relationship with Slack as a system of engagement (reducing users’ reliance on Salesforce by ushering them to interact with the Troops Slack App instead) and becoming a system of intelligence (providing intelligence around which deals users should approve and why) in our own right. Our broad idea was to foster visibility, accountability, and collaboration for a singular purpose - to close a deal.

Problem

Because Salesforce is widely accepted as the industry standard, organizations often build their approval processes through Salesforce’s Standard Approvals feature. Unfortunately, much like users’ typical experience with Salesforce, the Standard Approvals feature caused enough headaches for users to proactively ask us when we would consider building any kind of solution. Among the litany of frustrations, three specific problems stood out among the rest:

1. Approvers, approval-submitters, and other interested stakeholders do not know the status of an approval at any given time.
2. As Salesforce sends approval-updates through email as a messaging medium, updates often go overlooked, resulting in deal-cycle lag time.
3. The emails that are sent through Salesforce do not have enough information to make an informed decision, forcing the approver to hunt for pertinent details.

Research

While our Eng Lead began her technical discovery into a potential integration with Salesforce's SOAP API, the PM and I spoke with 13 customers who fit the Sales Operations persona: six customers who raised their hands (acknowledging that they wanted approvals) and seven customers who swiftly responded after we worked in conjunction with our Customer Success team to identify mid-market organizations who’d be receptive to the idea of Troops-approvals.

In learning about the user-problems listed above we learned that approval processes for sales generally take shape in one of (but not limited to) the following ways:

• Discounts
  Is the discounted percentage so high that we're "giving away our product for free"?
• Floor Rates
  We must sell at least _n_ in dollars for this sale to make sense
• Product Minimums
  We must sell at least _n_ in quantity-of-product for this sale to be beneficial
• Payment Terms
  Are there any other conditions on payment that may not be price-specific?

Additionally, we uncovered current "players" in the sales-approvals space through competitive research that included: Salesforce (Standard Approvals), Salesforce CPQ (Advanced Approvals), and Workato. While all three had a broad approvals-feature-offering, they all seemed to fall short of the mark in one key area: Approval Chain Efficiency. We immediately identified this area, as our largest potential for opportunity.

Trade Off

Despite understanding the many-sided pains and frustrations that our customers experienced when interacting with Salesforce Approvals, we knew we weren’t going to create a Troops Approval Process Builder™ from scratch. Doing so would have committed our team to an inordinately long undertaking, an undertaking that would have consumed the majority of our engineering resources and ultimately delayed our ability to quickly ship, learn, and subsequently iterate.

Instead, we chose to only integrate with Salesforce’s Standard Approvals. As 42% of our paid customers use Salesforce to run their approval processes, this meant that we did not have to reinvent the wheel and/or educate users on the utility of an structured approval process. Rather, we sought to improve upon a well-documented, troubling experience with Salesforce Approvals, for our users. The decision allowed us to to narrow scope (in order to build a leaner MVP) and specifically tackle Approval Chain Efficiency, further learn about what constitutes a “successful approval process”, and aggregate new feedback that could inform whether or not investing in developing a complete Troops Approval Process Builder may be viable in the future.

User Stories

Before diving into solutions we began drafting user stories that stemmed from our user research. The final, four stories, listed below, only pertain to the Administrator persona, as they would be the users who frequented the approval router most often.

As an Administrator, I want to be able to...

1. Specify for which Approval Process I’d like to set up a workflow and understand how it functions, so that I can power the workflow through Troops
2. Create a group-direct-message (for Slack) as an approval-notification-destination containing the Submitter and all pertinent Approvers while customizing each message
3. Send a message to each approver in individual direct-messages and customize the Slack messages sent at each step
4. Design actions and curate fields at each step so that I can standardize how an approval moves through the entire approval-chain

Design Jam

To kick-off the solution-discovery phase (with user stories in tow), I organized a small design jam comprised of engineers, PMs, and members from our leadership team. The purpose of the session was for everyone to bring their ideas, opinions, and assumptions to the table and channel them into proposed solutions to the problem without worrying about the constraints of feasibility and viability (yet). The earlier we were all able to surface our individual biases, the quicker we'd be able to tackle the problem at hand. The only requirement was that jam-participants adhered to the tenets of the design jam outlined on the whiteboard before their arrival

Following the Design Jam, the PM and I kicked everyone out the room to discuss which ideas had the most merit. Luckily there were very similar threads among all the participants' designs, so starring the most feasible and least expensive ideas was relatively fast. Everyone seemed to adhere to the "get in, get out" philosophy. We were in accord that the primary purpose of this GUI was to facilitate quick configuration while clearly illustrating the system status to the user.

Design Exploration

In adhering to the design principles that I established during the jam, I endeavored to create an approval-routing experience that didn't consume an inordinate amount of the users time and clearly illustrated the available routing functionality. Configuring routing, in and of itself, was relatively easy, and I set out to make sure that the layout and components complemented the ease of configuration.

As you'll notice, immediately after the third image in the carousel, the potential complexity drastically decreased because the team decided to narrow scope (see Trade Off). Whereas the first three images illustrate potential pages within an Approval Builder (i.e. creating an Approval process in Troops, from scratch), the five that follow illustrate the routing process alone.

High Fidelity Prototype

Slack Experience

While I'll discuss the Slack-side of approvals in a separate study, I think it's important to briefly mention Slack within the context of this case study as it's the "final destination" of the already-detailed approval-routing. The images and prototype above outline the admin user's experience when configuring Approval Routing, but the end-user experience (with regards to Approvals) exists for approval-submitters and approvers exclusively in Slack.

Within the Slack experience, we included the ability to do the following:

• Approve or reject an approval (with optional comments)
• View the approval-chain-history of any past or current deal
• Nudge an approver to take action on a stale deal
• Receive automated, real-time messages when someone took action on a user's submission

in order to fulfill our commitment to the initial user need of replacing the complexity of living in Saleforce with a streamlined workflow in the destination where our users spent the majority of their time, Slack.

Using Slack's design-system is simultaneously wonderful and maddening. It's wonderful because Slack is very strict about the intent/purpose of each individual component. Both the creator and the end-users immediately understand the interactivity that each component affords them. BUT it's maddening because that "strictness" (Note: Some of this inflexibility has been mitigated by Slack's transition to Block Kit) can occasionally force us, the builders, to get creative in constructing new interactions to compensate for unavailable components/functionality in Slack's design system.

"Handoff"

At Troops, our project teams worked extremely close, so as to avoid the usual pitfalls of lapses in communication. Especially with only four people on the team, there was no need for a prototypical handoff. Instead, I created a list of ux acceptance criteria for the feature, and we reviewed the criteria as a team, ensuring that it made sense and was achievable given our deadlines.

We also experimented with a new Design QA workflow where the engineers would tag me on any Pull Request that dealt with customer-facing UI. I was able to suggest/recommend styling (LESS & Styled Components) directly in GitHub in places where the build deviating from the ux-acceptance criteria. The experiment helped keep our feedback loop cyclical and perpetual, everyone on the team had a finger on the pulse of what needed tweaking before release. And, albeit selfishly, I was able to contribute to our codebase AND prepare for our eventual component-audit (Design System 🙂 )

Outcome

We shipped the product within a quarter's time, and we released to our customers in the second week of Q4 2019. Following a concerted marketing push, we immediately saw in increase in activity from MM and ENT prospects (in addition to several "cold" deals where talks were revived). Additionally, we established a baseline with two of our alpha-users so that we'd be able to accurately track the improvement in approval-chain efficiency.

One of those alphas, Stack Overflow, noticed that once implementing Troops Approvals, their average Enterprise Approval Time plummeted from 527 hours to 35, a 93% improvement. One of their Senior Salesforce Administrators noted, “Ever since we rolled out Troops, it’s just been so seamless that I have just forgotten about the dark times. I don’t need to ever think about our old approvals process again.”

In revisiting the primary pains that our users experienced (pre-Troops), our team:

1. Enabled users to view an approval's status on-demand by creating functionality that helped users summon the list completed or outstanding approvals from the Slack CL
2. Helped users funnel and route approvals through the platform where they communicate, Slack (rather than email)
3. Provided users with tools to customize the content of their own approval workflows, so that recipients weren't hunting for context

Retrospective Thinking

MVP...or MVPish? - Throughout the majority of this project, every facet of the work progressed without a hitch, uncannily so. From problem discovery to solution discovery, our team established clearly defined roles, ruthlessly validated initial assumptions, and set clear deadlines...at least until we "finished". While we hit our already aggressive targets (and were prepared to ship before the end of the aforementioned quarter), we collectively decided to work on two "delight" features before release. To date, our users genuinely love the two features, but once we finished building them, our initial decision begged the question: Would users have loved the Approvals product without the inclusion of delight features? Furthermore, had we decided to postpone work on the delight features, what could the extra time have afforded the team, especially in preparation for release?

Action Item

• The above questions may seem rhetorical but it made us think, albeit probably too much, about what really constitutes a Minimum Viable Product? At times it feels like the "MVP" acronym is thrown around like a catch-all for "just enough shit to get it out the door", which is troubling because that suggests the target/goal is always shifting, that there's no codified definition. In our case, deciding to tackle the delight-features likely wasn't necessary, or not yet necessary, as it extended beyond the MVP that we initially agreed to. To mitigate this potentially happening during future projects (and with the help of learnings from a great article) we established strict, unyielding rules for the development of MVPs. We eliminated any idea of "fast-follows" (read: incomplete work), and committed to building the MVP as initially agreed upon. All work beyond the MVP will now require a collective discussion about why it merits inclusion in a sprint and why it should be prioritized over other competing initiatives.