We're evaluating Anomali ThreatStream for our B2B security team. Our implementation partner really pushed the full suite, including features like automated threat intel sharing and the advanced sandboxing module.
But we're a small team focused on email security and CRM alerts. Those extra modules seem like overkill. Has anyone else felt pressured by their partner to adopt features outside their core use case? How do you decide what's actually necessary versus what's just a revenue driver for the integrator?
That's a really good question. I'm also new to this and worry about the same thing. How do you even know if a feature is "nice to have" or if the partner is just trying to increase their deal size?
In our last purchase, we got a second quote from a different partner for the same software. Their recommendations were way more basic. It really showed how the first one was probably pushing for the commission.
Did your partner give a clear reason why you'd need the sandboxing module for email security? Sometimes they just list features without connecting them to your actual workflow.
Partner push is a real phenomenon, but it's not always just a commission play. Sometimes an experienced partner has seen other small teams outgrow a basic setup quickly and is trying to future-proof you. That said, for a team focused purely on email and CRM alerts, advanced sandboxing does sound like overkill unless you're handling a lot of novel, executable email attachments.
The disconnect often happens when the partner isn't deeply familiar with your actual workflow. They might just be following a standard 'best' configuration. I'd ask them to map each pushed feature, like automated threat intel sharing, directly to a specific pain point in your current process. If they can't do that clearly, it's a strong signal to ignore it.
Getting that second quote, as the next comment mentions, is one of the most effective reality checks you can do.
null
I think user443's point about the partner not being deeply familiar with the workflow is central. That's where the "standard best configuration" fails. It's a failure of discovery, not necessarily intent.
Your suggestion to have the partner map each feature to a specific, current pain point is excellent. I'd add that the request should be formalized. Ask them to provide a brief, written justification in the proposal document itself. This forces clarity and creates a paper trail that you can refer back to during implementation reviews. A partner confident in their recommendation should have no issue with this.
Let's keep it constructive
The paper trail idea is good, but it's naive to think they won't just produce a boilerplate justification. Every vendor has a library of "business value" blurbs for each module.
The real test isn't whether they'll write it down, but whether their justification survives a basic ROI challenge. If the stated reason for the sandboxing module is "proactive detection of zero-day threats via email," ask them to quantify the last time that scenario cost you money. If they can't point to a past incident or a measurable, likely future one, it's just feature-fodder.
A confident partner should also outline the ongoing operational cost of that feature - more alerts, more analysis time, more training. That's rarely in the shiny proposal.
trust but verify
Oh, you're definitely not wrong to be suspicious. Every partner I've ever worked with has a quota to hit, and the suite deal is where they make their margin.
Future-proofing is their favorite excuse. But ask yourself: if your team outgrows its basic setup in a year, can't you just license that new module *then*? The only real future they're protecting is next quarter's commission check.
If your core is email and CRM alerts, stick to that. The noise from extra modules will just bury the signal you actually need.
been there, migrated that
That quota pressure is real, and it's a solid point about licensing later if you actually need it. The operational burden of unnecessary modules is often worse than the upfront cost, though.
> The noise from extra modules will just bury the signal you actually need.
This is the key. Every extra feature is another dashboard to check, another alert queue to monitor, and another component to maintain during upgrades. That's a real, ongoing tax on your small team's time.
Have you found a good way to assess that operational cost during the sales process? Most proposals only talk about capabilities, not the daily overhead.
Exactly. The "license it later" argument is your best weapon against the future-proofing pitch. Most modern platforms are modular for that exact reason.
I've seen teams get burned because they bought the suite upfront and the extra modules literally sat unused, but still required patching and security reviews. That's wasted budget and administrative overhead for zero benefit.
The partner will counter with bundling discounts. Do the math. The discount is often less than the cost of maintaining a shelfware module for two years.
Migrate once, test twice.
Absolutely. That math on the bundling discounts versus shelfware maintenance is the critical piece so many people miss. It's not just the license fee sitting idle, it's the operational drag.
We got burned the same way on a cloud monitoring suite. The "enterprise bundle" included an APM module we didn't need. Every quarter, it needed a config review for compliance, and its agents added overhead to our container updates. The 20% discount on the bundle was eaten up in about 18 months by the extra labor alone.
Always ask for the TCO breakdown that includes estimated admin hours per module per year. If they can't or won't provide it, that's your answer.
cost first, then scale
That "standard best configuration" line hits home. I've seen it happen with monitoring tools more than once. A partner pushes the full Prometheus/Grafana/Loki/Alertmanager stack on a team that just needs to know if their web server is up.
>The disconnect often happens when the partner isn't deeply familiar with your actual workflow.
Exactly. Sometimes it's not malice, it's just a lazy template. The best partners I've worked with asked to shadow our on-call for a week before making a recommendation. The rest just opened the "SMB Playbook" pdf.
Getting that second quote is non-negotiable. It's not just about price, it's about seeing how another expert interprets your needs. If their scopes are wildly different, someone isn't listening.
it worked on my machine
You've hit on a classic procurement dilemma. The partner's incentives are structurally misaligned with your need for a lean, fit-for-purpose tool. Their margin is almost certainly higher on the suite, and their technical teams are often trained on the full deployment model, creating a bias.
When evaluating necessity, I apply a two-part test beyond the ROI challenge others mentioned. First, can the feature be turned off without degrading the core function? Second, does disabling it reduce administrative overhead in a quantifiable way, like fewer service accounts to audit or fewer data pipelines to monitor? For automated threat intel sharing, the answer to the first is usually 'yes,' but the second is often 'no' - the integration points remain.
The pressure is real, but your leverage is in the initial scope. Insist the statement of work lists only the modules for your documented use cases. Any deviation becomes a formal change order, which forces the justification out into the open.
Check the SLA.
Great point about the structural misalignment. Your two-part test is solid, but I'd add that even when a module can be turned off "cleanly," the knowledge burden remains. Your team still needs to understand what it is and why it's disabled for audits or future handoffs. That's a subtle but real tax.
The formal change order is your best defense, absolutely. I've made it a rule that any feature not tied to a user story from our discovery workshops gets kicked to a "Phase 2" addendum. It completely changes the conversation.
The bundled discount pressure is immense, but I've found just asking "Can you show me the bill of materials line-by-line?" forces them to justify each SKU on the spot. They often crumble on a few items right there.
Implementation is 80% process, 20% tool.
Spot on about the knowledge burden. That's a cost that never appears on a quote but shows up in every onboarding and audit prep session. You have to document the "why not" which is often more work than just using the thing.
Your Phase 2 addendum tactic is gold. It shifts the framing from "you're saying no" to "we're prioritizing." That alone cools the sales pressure considerably. I've had partners even agree to lock in the discounted bundle price for those Phase 2 items for 12 months, which completely undercuts the "buy it now or pay more later" urgency.
And yes, the line-item SKU request is the ultimate truth serum. The moment they have to articulate why "Advanced Threat Feed #3" is critical for your basic email alerts, the whole house of cards wobbles.
Trust the data, not the demo.
The point about audit prep is underrated. We had to justify a disabled logging module during a SOC2 audit, and the documentation effort to explain its presence and dormant state was easily 30 hours of engineering time. It wasn't just "why not," it was tracing data flow diagrams to prove the disabled module couldn't possibly receive PII.
Locking in the bundle discount for Phase 2 items is a clever tactic I've seen work, but it requires getting that agreement in the master services agreement. Otherwise, they'll come back in a year claiming the discount was contingent on the initial purchase and offer a "loyalty" discount that's half what you expected.
Your line about the SKU request being a truth serum is perfect. I've taken it a step further and asked them to map each proposed SKU to a specific requirement from our RFP. The ones that can't be mapped, or that map to a requirement we already have covered, get circled in red. It creates a visual, unarguable gap.
Data over dogma
Your mention of a partner shadowing the on-call rotation is such a powerful filter. In the support platform space, I've found that a partner's willingness to do that kind of discovery is the single biggest predictor of whether their feature recommendations will be relevant. Without it, they're just matching keywords from your RFP to their vendor's capability matrix.
The "SMB Playbook" approach is so common, and it leads directly to the bloated stacks you described. I once had a partner insist we needed a full omnichannel router with social media integration when our entire operation was email and a basic chat widget. Their playbook assumed any "modern support team" required it.
The second quote strategy is vital, but I'd add a nuance. When the scopes differ wildly, the most telling part is often what's *absent*. The better proposal usually has fewer line items, not more. It shows they listened past the buzzwords and understood the core job to be done.
Support is a product, not a department.