Why Not Use Salesforce? and Iterating Towards Success

In the course of championing internal systems, you'll run into a manager who will rightfully ask:

Why don't we just use Salesforce?

or, if you're working with certain types of individuals:

I simply can't work unless it's in Salesforce. If you don't buy it for me, it's your fault if I can't sell.

The latter are full of crap and can take a hike. If they can't sell with a piece of paper and a pen to keep track of things, Salesforce (or any tool) is not going to make it any better. These co-workers don't want to deal with engineering and they end up making horrible database design decisions. They can't (and shouldn't have to) grasp why dozens of boolean columns will bite them in the backside later.

Finding the way past off-the-shelf

One of the more difficult parts of building internal tools is convincing management that they're needed in the first place. Management may say "just do it in Google Docs" or "let's buy a license for [insert flavor of the month package here]. And often, that's what happens. Companies end up solving a bad software decision with excessive and exponential hiring. This leads to work moving through an ineffective and (un)designed pipeline.

So how do we iterate towards something that's not going to feel like a US Militay project taking 4 years and billions of dollars?

Prototype by (Digital) Duct Tape

There's a long standing joke that businesses are held together by the digital duct-tape of their Office suite. While this may not always be true, I'm constantly amazed what people can achieve with a beater ThinkPad and Microsoft Excel.

Google Docs can be a very effective (and cheap) prototyping tool for end users. They're comfortable in the spreadsheet paradigm and can often create a system that lets you know what's important and what is not. By using these simple tools, we can identify things that are repetive and ripe for automation. You may even extract business logic from some of the more robust tools that users have perfected.

The programming practice of refactoring is quite instrumental here. Refactoring is a process that lets you rework pieces of code but you don't do so until there is a pain point reached.

Is it worth your team's time to build a tool that ends up going unused because that business need has changed or was temporary?

If it's not hurting, there is something else that is.

It's difficult to admit that a rewrite isn't the solution. We realize that it is better to fix the pain points than dive down the "replace everything" tunnel. That may be our end goal, but the road is never straight.

At LivingSocial, we rebuilt our Customer Service app in parallel to the team working in SalesForce. During that process, we fixed lots of everyday pain points for users. These fixes came online long before we even had design sketches for the eventual system. It had an immediate impact on our customer support reps and their ability to do their jobs. They could give us prompt and detailed feedback on what was working and not working in the system.

We even extracted pieces from the design process and put them onto the existing system for extremely painful places. One such place was email subscriptions. The interaction was unclear with lots of buttons in a matrix. It was difficult to just turn them all off. The button was trying to be both the state and the action. So if a rep clicked "Subscribed" it would unsubscribe a user. Not clear or usable.

We switched it to a grid of CSS based Yes/No iOS-style switches (Pre iOS 8 style) and had the yes state be green, and the no state be gray/diminished. We added buttons to unsubscribe by market as well as an easy way to unsubscribe from everything.

Our customer support reps now had a tool that was a major improvement over their existing workflow. It took a day to ship on the existing system and saved countless hours and reduced call times.

The Slow March

Software is a tool to do a task faster than it could be by hand. If you forget that, you end up writing perfect code that will never ship or if it does, is not used.

While it's fun to start great rewrites they often bog down. Start small. Find the pain points.