As a SaaS founder in the ever-evolving landscape of… just kidding.
No grandiose (*cough*AI-generated*cough*) fluff here.
What I did want to do was get a little more tactical on my post from last week and provide more context for some of the questions we think RevOps teams should be considering for 2025 planning starting with “What do we really need from our tech stack?”
Here’s some of the most common difficulties I encounter at organizations trying to figure it out.
𝗖𝗼𝗻𝗻𝗲𝗰𝘁𝗶𝗻𝗴 𝗼𝗹𝗱 𝗮𝗻𝗱 𝗻𝗲𝘄
Cloud apps may not be the sexy new trend anymore as many organizations have made that switch but most still use a blend of cloud and on prem apps. Integrating a cloud app to another cloud app can be pretty simple but what happens when these apps have to connect back to a good ol’ fashioned on-prem solution?
A common example I see of this is Finance using an on-prem solution like SAP and Sales teams using Salesforce Cloud but without either system “talking” to each other.
Without that full visibility into opportunities, contacts, activities AND credit status, payment history or invoices, both functions struggle with getting the clarity needed for better decision making and wasting time with manual updates.
While these tools can be integrated via an IPaaS solution or something custom built, the cost, risk, time and maintenance it takes to ensure it’s up and consistently working can be more than a lot of orgs can successfully manage.
So as much as shiny new tools can be appealing, how it works with the core platforms you have on hand matter more than some flashy features.
𝗚𝗼𝗶𝗻𝗴 𝗻𝗮𝘁𝗶𝘃𝗲?
This point is specific to CRMs since we built ARRow as a Salesforce-native tool due to the challenges I kept hearing in my consulting practice.
Native tools particularly for a CRM can be a huge benefit as it piggybacks off the same scalability, familiarity, customization, and security capabilities of a well-established brand like a Salesforce.
Even when using an external platform with a rock-solid integration, there’s an outside data hosting center to worry about crashing, more API calls to wonder if you’ll blow through, and a heavy reliance on outside provider to educate, onboard and consult on any issues.
And if the external platform skews black-boxish and exhibits questionable behavior, getting answers to the questions on how, why, and where the data is coming from always seem to dominate internal conversations over what to do about them.
Bringing more frustration, more distrust, and more manual workarounds or service provider calls.
NOT very effective.
So native or not, make sure your team can understand (and agree on) how the data is captured and used and without getting caught up in all the fancy ‘actionable insights’ promised in the courting phase of the buying process.
𝗛𝗶𝗴𝗵 𝗯𝗶𝗹𝗹𝘀 𝘁𝗼 𝗯𝘂𝗶𝗹𝗱
When new customers reach out to us at ForecaaS, many times it’s not another platform they’re looking to replace but an internal build that is no longer (and was never really) up to snuff. But to hopefully save a few dollars, they determine some requirements and try to build something custom themselves.
But then, someone leading the charge gets fired or quits and so does the base knowledge of what to do.
Or someone new comes in and decides the requirements changed.
Or a more complex fire comes up and suddenly resources are thin.
Or something unexpectedly comes up in the integration as a technical obstacle that becomes a bottleneck to progress.
Now, any costs-savings that building something yourself vs buying an established tested product brought is up in smoke and although teams may be more aware of what they need, they have less time and are under much more pressure to buy something and solve the problem once and for all.
Remember, the bill to build from scratch can be much more costly than anticipated.
𝗦𝗼 𝘄𝗵𝗮𝘁 𝗮𝗿𝗲 𝘀𝗼𝗺𝗲 𝗿𝗲𝗾𝘂𝗶𝗿𝗲𝗺𝗲𝗻𝘁𝘀 𝘁𝗵𝗮𝘁 𝘀𝗵𝗼𝘂𝗹𝗱 𝗯𝗲 𝗻𝗼𝗻-𝘀𝘁𝗮𝗿𝘁𝗲𝗿𝘀 𝗳𝗿𝗼𝗺 𝘁𝗵𝗲 𝘁𝗼𝗼𝗹𝘀 𝘆𝗼𝘂 𝘂𝘀𝗲?
The main goal for your stack should echo the true purpose of RevOps teams – to be the ⚡silo destroyer⚡. Your stack should make teams more effective across functions so look for tools that:
• Provide unified views of the system through dashboards and reports
• Has a core integration or is native to your CRM so the data can easily be captured and updated. It should be abundantly clear exactly how, where, and why the data is being used.
• Contains guardrails around importing and exporting data to ensure necessary data points are being included or excluded
• Can be adjusted to look at new data points as needs change and grow
Speaking of data, next week’s deep dive has to do with taking “data-driven” from a buzzword on your homepages values section to an organizational reality – stay tuned!