/The sales ops tech stack (Part 1)…

The sales ops tech stack (Part 1)…

Guest blog by Joe Rodden, Sales Systems Manager at Catalant Technologies

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. Here’s part one:

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.

Stay tuned for part two. In the meantime, if you are choosing a new data provider, check out our tips and recommendations.

Source link