Beauhurst makes a software as a service data platform. Subscribers get access to data on interesting companies in the UK.
A Salesforce plugin was our most requested feature at the time of this project as many of our subscribers use it to keep track of their customers. Beauhrust is a natural fit because we can provide more potential customers for our subscribers to approach. Our Sales team had heard during demos that the lack of a Salesforce plugin was the reason a company didn't sign up.
I spoke to around ten of our subscribers to ask the about how they use Salesforce. I noticed three themes during my interviews:
We have strong product principles based on the idea that we don't want to just be a database to our subscribers. Similarly we don't want to encourage companies that cold-call thousands of potential customers with no effort to understand them. This meant that the first two needs above were incompatible with our principles without a lot more careful thought.
I would design a plugin which would half-meet the first theme ("Fill their database with our data"), but would focus mostly on the third theme ("See our data as context").
This project was mostly about data, so I wanted to understand that data well.
On the Salesforce side, I looked into what fields an account page offers by default. I listed these in a spreadsheet and mapped them to similar fields in Beauhurst.
I also listed these against the data offered in our API since that would be feeding the plugin. If we needed to make changes to the API it's better to know early.
Research into SaaS platforms is not normally easy. They're subscription only do it's difficult to get access as a competitor. Luckily Salesforce has a plugin marketplace called the "appexchange", where I could see what our competitors offered with their plugins.
I learned that our competitors mostly took the easy approach: A full screen view of their platform inside Salesforce. This does not help someone with seeing data as context, when they're looking at company details. It was an opportunity to be more useful than our competitors.
I created some wireframes to show the flow of the plugin as I imagined it. This helped the rest of the company, as well as the third party developers we hired to build the plugin, to understand and agree on the approach.
As we discussed this plugin flow, we decided to remove the feature that would let our subscribers fill their Salesforce fields with Beauhurst data. We hadn't been sure of the feature from the start because it did not match our principles, and removing that step from the plugin would make it less complicated. Instead, the first version of the plugin would only provide data as context.
I also created a style tile to show what visual style I expected for the plugin.
Next I provided a step by step mockup to show the flow of the plugin, minus the company data. Unlike the earlier wireframes, this was much closer to the final visual design.
The third party developers were fantastic—responsive, and they understood our requirements well. They sent me each draft of the plugin, and I would send back feedback and ask for tweaks. After a few of these feedback loops, the plugin was ready to show to subscribers.
I booked calls with subscribers who were interested in the plugin and walked them through it. The feedback was very positive—subscribers were excited to get their hands on it once they had seen it.
At the same time, I was showing the finished plugin to the commercial teams at our company. They would sell or upsell the plugin so they needed to understand it well. The internal feedback was also very positive.
Version 1 of the plugin is now finished. I looked at activity for our API, and saw that it had jumped from 6,000 calls over a period of time to 26,000 calls over the same period of time. Subscribers have really taken to the plugin.
I've also heard from the commercial team that they've sold more subscriptions thanks to the plugin being available.
This project was one of the first at Beauhurst to use the "MVP" approach, where we build something small to learn more about it, and build on that success more later. Since this project, that approach has become standard at Beauhurst.
We are also, as a company, less afraid to work with third party developers because of the success seen in this project. It had not been considered because of bad experiences in the past. The development team is now looking at outsourcing more development work for smaller, stand-alone projects.
We had plenty of ideas for how to improve the plugin, like collapsible sections for the company information. To set a direction for these improvements, I mocked up what version 2 might look like. We have not yet returned to the project to make these changes.
One thing I would change about this project is to have learned more about Salesforce development ourselves. We have not had the time to learn about it, internally. This means that if we want to make more changes to the plugin, we'll need to engage the third party developers again..