We’re all aware of how companies’ go-to-market tech stacks have grown rapidly in terms of both size and complexity. And as your tech stack in particular grew, so did the number of data sources you had to manage. On top of that, your go-to-market teams didn’t want to waste time navigating between systems and tools to do their jobs; they wanted a single place where they could seamlessly fulfill their wide variety of duties, tasks, and activities. Many of the products in your stack might’ve had large ecosystems with a wide range of apps and integrations available. But, you inevitably found yourself with a piece (or pieces) of your tech stack crucial to your process that didn’t have these native connections. It was only natural that you reached out to your internal development team or looked externally for the custom development of an integration. If the integration was supposed to be custom-built for your business, why isn’t it working as you hoped it would?
If you were to dig in, you’d find any number of reasons that your custom integration is ineffective. But, you’d also likely see that all of those reasons can be summarized with a single statement:
Your business process did not sufficiently drive how the custom integration needed to work or how it would be built.
You shouldn’t add any technology to your tech stack without considering the job it does within your business process. Custom integrations are a part of your tech stack just like your marketing automation platform, CRM, or any other tech you use in your business. They cannot be an exception to this principle. But what does it mean to have your business process “drive” how a custom integration should work or be built?
It starts on paper, or a white board and definitely before anyone writes any code. You and whoever is building your integration should be 100% clear on the flow of the business process involved in the integration. If you don’t take time to outline and clarify the entire, overarching process, you missed the first crucial step to ensuring the success of your custom integration. How can your business process be sufficiently driving how the custom integration needs to work, and therefore be built, without a clear outline of the flow of that business process? And if it’s a new process, never before implemented, that’s all the reason to draw it on paper first.
When you do that, you (and your integrator) must stay anchored to reality. The integration’s functionality will be triggered by real-world activities and behaviors. It’ll support and enable tangible processes carried out by actual, physical people. And material, physical outcomes will come out of using the integration and systems involved. It’s much more valuable and considerably less time consuming to call out the things grounded in reality than to get in the weeds on integration middleware, algorithms, or logic.
And with custom integrations, it’s easy for the amount of time spent on it to spiral out of control, relative to the value it might provide. There’s no way to address every possible scenario that might occur in the integration because there’s no way to know every possible scenario until you start using the integration. On top of that, you can’t and don’t want to wait for your integrators to build every possibility into the integration.
It’s a widely accepted rule that in a given situation, 80% of your output comes from 20% of all of the potential inputs. The same is true for your process. 80% of the time, your process handles only 20% of all the situations it might encounter. You and your people know what situations you’re most likely to encounter, because they’re the ones you normally encounter. These situations are the ones that don’t stick out in your head, which makes them very easy to ignore. Make sure those situations are accommodated first. Then work with your integrator to deal with situations outside of that 20% as they come up during your use of the integration (and good integrators should be open to that type of ongoing collaboration).
It’s inevitable that something will change during the development of your integration and integrations rarely function at 100% on day one. There will be issues. You need to keep an open line of communication with your integrator(s) and make them aware of these changes and issues. Your integrator should also ensure that everyone involved knows how these changes affect the development of the integration and the flow of the business process the integration supports. You and the integration’s stakeholders need to stay informed about progress on the integration’s functionality as a “check” that ensures your real-world business process is what’s driving the technology.
All stakeholders should be represented, especially the front-line users affected by the integration. If a salesperson is working with data going through the integration, they need to be there. If a marketer is using reports enabled by the integration, they should be heard. If a manager needs to make sure their team follows a particular process, they should get a say about that process. They’re the ones who actually use the integration. They’re also the ones who are most affected by the friction created by a custom integration. You need them to buy into the changes created by implementing the custom integration, and inclusion in its development process is a great step towards achieving buy-in. After all, they have to use the integration to do the real-world activities and business process that the custom integration is supposed to enable (A.K.A.: Their jobs).
But you’re here because your custom integration isn’t working for you right now, at this moment. You notice that your front-line users no longer want to use the expensive SaaS product(s) that you attempted to integrate with. You’re hearing from them about how it’s been harder to use the tech to do their jobs. You see all of the ways that they aren’t following your process as a result. And you definitely feel the dip in productivity and lost value. It’s affecting your ability to do your job as well. You can’t trust the reports on your dashboards, because you know the data has been dirtied up by integration issues. You’re struggling to orchestrate the activities of your team(s) and people. And you find yourself increasingly playing the role of tech support, compared to the duties in your actual job description.
All of these are symptoms of when an integration has added complexity and friction to your process, instead of enabling and supporting it. This ruins your tech-stack’s user-experience for your people. Your employees are going to do what they feel they have to do to carry out their day-to-day duties. If they think the technology and integration is getting in their way, they aren’t going to use it. They might still follow aspects of your process, but observing, measuring, and enforcing the process will become increasingly difficult, inaccurate, and untrustworthy. When you can’t trust measurements and observations about your process, you’re no longer able to identify insights and make data-driven decisions. You’re handcuffed when it comes to finding ways to adjust your processes and maximize the value they create. You also know that you can’t just leave the bad integration alone, because that’s how the workarounds your people created end up superseding the actual, thought out business process that needs to happen.
Unfortunately, you aren’t left with a ton of options once the integration has been implemented. You’re going to need to figure out if it’s forcing your team(s) and people out of compliance with your process and if there’s parts of it delivering enough value for you to stick with it while you decide what to do next. Regardless, it’s crucial that you go back to the beginning. Clarify and lay out the actual job(s) the integration needs to do and the flow of the business process it’s supposed to enable. You can then use those resources to find the areas where the integration is out of alignment with your process, to then adjust the integration. Of course, if you find your integration is totally out of alignment with your process, you might be better off cutting your losses and starting over from scratch.
Now that you know how to make sure your business process sufficiently drives your next custom integration, you can take the measures that set you up for a successful implementation starting at the integration’s launch. You know that your integrator needs to work collaboratively with you to support your team(s) and enable them to do their jobs more effectively after the integration is implemented. At the very least, you know how to find one that will.
