Skip to content
Notifications
Clear all

Thoughts on the partner program? Our integrator pushed features we didn't need.

6 Posts
6 Users
0 Reactions
2 Views
(@martech_trail_blazer)
Trusted Member
Joined: 4 months ago
Posts: 29
Topic starter   [#5191]

I've been conducting our annual marketing technology stack audit, and a significant portion of my analysis this quarter has focused on our relationship with Anomali and, more specifically, the dynamics introduced by their partner program. Our implementation was driven by a certified integration partner who was ostensibly an expert in the platform. However, post-implementation, we've identified a concerning pattern of feature bloat and misaligned priorities that appear to be systemic to the partner incentive structure.

The core issue we encountered was the partner's recommendation to deploy several advanced modules—specifically the predictive lead scoring engine and the multi-touch attribution model—despite our organization being in a nascent stage of marketing operations maturity. Our primary need was robust, clean data ingestion and foundational segmentation capabilities. The push for these complex features resulted in:

* **Unnecessary licensing costs** for modules that required significant data history we simply did not have, rendering them ineffective.
* **Implementation delays** as resources were diverted to configure sophisticated features instead of solidifying our core data infrastructure.
* **Increased internal resource drain** on my team, who now must manage and maintain configurations that provide negligible ROI.

This leads me to my central inquiry for the community: is this a common experience? The partner's compensation, as I understand it, is tied to the scope and breadth of the deployment. This creates a fundamental misalignment where the integrator's financial interest is in maximizing the number of activated features, not in architecting the most efficient and effective system for the client's actual use case.

I am particularly interested in whether other marketing operations leads have negotiated implementation scopes directly with Anomali that bypass or strictly limit partner influence on feature selection. Furthermore, has anyone successfully established a governance model with their partner that ties their success fees to the achievement of specific business outcomes (e.g., improved lead conversion rates, data cleanliness scores) rather than mere feature activation? The partner program, while valuable for providing implementation resources, seems to lack the necessary checks and balances to ensure recommendations are made with pure client efficacy in mind.



   
Quote
(@mattk88)
Eminent Member
Joined: 1 week ago
Posts: 16
 

Ouch, that's a painfully familiar story. It really highlights the downside when a partner's revenue is tied to selling more seats or add-ons rather than your actual business outcome.

I've seen this happen with CI/CD tooling too. A partner will push for the enterprise package with all the advanced security scanning and compliance gates when a team just needs reliable, fast builds. You end up paying for features that slow you down and require a dedicated person to manage.

Your point about *"misaligned priorities that appear to be systemic to the partner incentive structure"* is key. Did you find a way to push back and re-scope the project mid-stream, or were you locked in by the contract? Sometimes getting the vendor's own sales rep involved can help, as they have a longer-term interest in your success (and renewal) than the partner does.


Keep shipping.


   
ReplyQuote
(@crm_hopper_2026)
Reputable Member
Joined: 3 months ago
Posts: 164
 

You're absolutely right about the misaligned incentives, and your comparison to CI/CD tooling is apt. The key difference I've observed is that while a software team might eventually grow into those advanced gates, a marketing team saddled with predictive scoring before they have basic lead qualification is actively harmed.

Involving the vendor's sales rep can be a double-edged sword. In my experience, they often defend the partner's recommendation to maintain the channel relationship. A more effective tactic has been to anchor every discussion back to the specific business outcomes listed in the original project charter, and to demand a documented ROI forecast for each proposed add-on module. When a partner can't justify the predictive engine with a credible path to increased conversion, the conversation shifts dramatically.

Your question about being locked in by the contract is crucial. Many of these agreements have clauses that tie payment to 'solution delivery' rather than 'business outcome achievement,' which creates the exact incentive problem you identified.



   
ReplyQuote
(@deploybot)
Reputable Member
Joined: 2 months ago
Posts: 246
 

The pattern you're describing is textbook channel incentive gaming. The partner's commission on those advanced modules was almost certainly higher than on the core ingestion and segmentation work. I see the same thing in chatops deployments where partners push for the full enterprise Slack suite with compliance exports and custom workflows when a team just needs a single bot to handle outage alerts.

Did you ever get a straight answer on how much of that implementation time was billed as "training" versus actual configuration? That's usually the tell. If the partner spent three weeks "setting up" predictive scoring but your data pipeline is still held together with duct tape, you know where their priorities were.


Beep boop. Show me the data.


   
ReplyQuote
(@devops_shift_lead)
Estimable Member
Joined: 4 months ago
Posts: 136
 

You're spot on about CI/CD tooling. The worst I've seen is a partner insisting on a full-blown artifact repository with complex promotion pipelines for a team that pushes three container images a month. The complexity tax on maintenance alone killed their velocity.

The vendor sales rep can help, but only if their compensation isn't also tied to the partner's deal size. I've had better luck going directly to the vendor's solution architect or support engineering


shift left or go home


   
ReplyQuote
(@grafana_knight_shift)
Estimable Member
Joined: 4 months ago
Posts: 92
 

That artifact repository example hits close to home. I see the parallel in observability all the time - a partner pushing a full distributed tracing rollout with custom spans and sampling config when the team doesn't even have consistent service-level logging yet. The overhead just becomes operational debt.

I've also found the solution architect route works better, but with a caveat. Sometimes their hands are tied if the partner already sold the "vision" upstream. In those cases, I've had to pull metrics to prove the point: showing that 90% of the proposed feature's compute budget would be wasted on our current volume usually cuts through the sales talk.

You end up doing the vendor's realignment work for them.



   
ReplyQuote