As a strategic member of the sales team, ops plays a critical role in owning the sales tech stack. While sales leadership may sign on the dotted line for new vendor contracts, the responsibility of onboarding, implementation and training falls on the sales ops team. It’s important to be involved in every step of the process so you can effectively manage your organization’s sales technology. I recently spoke with other sales operators about their experiences with building and managing tech stacks, and gathered several lessons learned. 

Lesson 1: Evaluating Cost

Most new vendors will send you an invoice with a dollar amount attached, standard practice in capitalist America. But when evaluating tools you need to realize that the final dollar amount they send isn’t the only cost involved in purchasing and implementing a tool. Whenever making a build vs. buy decision (building it on your own or buying a tool) you need to incorporate the time spent implementing and maintaining the tool as well as time spent teaching your team to use the tool. No vendor is going to tell you that implementing their tool is a nightmare. Most of them are made for the masses so your workflow nuances are typically where the customization needs to happen. Be sure to ask enough questions during the demo and evaluation phase about how X functionality would handle Y workflow. Don’t feel bad about making the sales team prove their tool can do what you need it to – it’s their job to sell it. And, if the tool can’t do exactly what you want, think about workarounds and determine if you can scale it.

Lesson 2: The Endless Loop of Integrations

There’s a concept in transportation logistics called the “spoke-hub distribution paradigm” which routes are organized as a series of “spokes” that connect outlying points to a central “hub.” This makes it easier to get to the other spokes so long as you can access the hub. Contrast this with the streets of Boston where one wrong turn sends you on a series of one way streets until you finally lose all hope of ever leaving the city. Just like our founding fathers intended.

Why am I talking about transportation and horrible Boston city planning? Well this concept of a spoke and hub is also widely used in IT. In our case, we should have one system as the hub, typically a data warehouse or sometimes Salesforce, with all of the other systems fitting into that system and not talking directly to each other. This helps us avoid scenarios where system A updates System B which updates System C and then updates system A which updates System B. This will eventually cause some inaccurate updates to occur, or in worst case just endless loops of data updates. Instead, we should have Systems B and C only update System A. System A can then traffic control all the data and send it back to each system as needed.

Lesson 3: Tool Does Not Fix Bad Process

I once consulted for a small startup to help them reimplement their entire sales process within Salesforce. They had never taken the time to properly record data about what their reps were selling, in addition to several other critical data points. I remember having a tough conversation with them when they were considering purchasing a business intelligence (BI) tool. They thought the BI tool, and its reports would fix their problems. I explained to them that a BI tool doesn’t magically fix your data, or create data that doesn’t exist. If anything, without good data, a new system will do more harm. The moral of this story is that buying a tool isn’t going to fix a bad process, data issues, or managements issues. In fact, it’s going to exacerbate them in most cases. So, whenever you’re looking to solve a problem with a tool first, make sure it can’t be solved with training or management.

Lesson 4: Get In Front of New Tools

This is one I personally learned very painfully. If your organization is considering a new tool for the sales team, then you or a member of the ops team must be involved in the purchasing decision. This helps you keep your sanity, and it will help your company in the long run. At a larger organization, this should be much less of an issue as their procurement processes are more structured. In smaller companies, I’ve seen what I call “rogue buyers,” purchasing tools for the sales team without consulting the people that are actually responsible for implementing it or owning it after the sale. It’s a tough conversation when you have to tell someone that the tool they purchased overlaps almost completely with another tool, or that it’s just a pretty interface filled with marketing speak and doesn’t actually provide any real value (there’s a lot of these out there). If you have a good level of trust with your team then they will think to bring operations into these decisions without hesitation. However, I’d recommend defining and enforcing a process for purchasing new sales tools across your organization. It will save your company money, and you a headache.

If you are evaluating your tech stack, and considering a new data provider, check out our tips and recommendations.

Recent Posts