Okay, I know I'm probably going to get some flak for this, but here goes. I've been using Akamai Prolexic for about 18 months now to shield a pretty complex data pipeline setup that ingests into our data lake. The product itself? Honestly, really solid. The mitigation rules are granular, the reporting gives me the visibility I need into attack patterns, and the performance impact during actual DDoS events has been minimal on our Postgres read-replicas and API gateways. It does the job it's advertised to do.
But—and it's a huge "but"—the post-sales support experience has been... an exercise in patience. Once you're past the initial onboarding and configuration with the sales engineers (who were fantastic, by the way), getting timely help feels like pulling teeth. Let me give you a concrete example from last month. We needed to adjust a specific mitigation rule because it was starting to catch legitimate traffic from a new batch of ETL workers we spun up in a different cloud region. The rule was a bit complex because it involved a combo of geography, rate, and a particular signature.
Here’s a sanitized version of the rule logic we needed tweaked:
```json
{
"rule_name": "ETL_Worker_Allowlist_Override",
"condition": {
"and": [
{ "source_geo": "!US" },
{ "request_rate_gt": "1000_per_min" },
{ "matches_signature": "XYZ_Scanner_Pattern" }
]
},
"action": "alert"
}
```
We knew exactly what needed to change (the `source_geo` and the signature), but a confirmation from their side on the exact syntax and potential side effects would have been wise. I opened a high-priority ticket. The initial auto-response was quick. Then, silence for over 8 business hours. The first human response was just a template asking for more information that was already in the ticket. The whole back-and-forth to get a 10-minute config review took **three days**. During a normal week, that's frustrating. During a potential false-positive crisis, that's unacceptable for a service at this tier and price point.
This isn't a one-off. The pattern I've seen is:
* **Slow initial response times** on non-"attack-active" tickets, even when marked urgent.
* **Escalations require multiple nudges.** You have to follow up constantly.
* **Knowledge seems siloed.** The front-line support often can't handle slightly advanced config questions and has to "consult internally," which adds days.
* **Documentation is comprehensive but overwhelming.** Sometimes you just need a pointed answer to a "can I do X?" question.
Don't get me wrong—when you're under attack and you trigger their emergency line, they are on it immediately. That system works. But for the ongoing, proactive tuning and optimization that makes a security product truly effective in a dynamic environment? The support feels like it's operating at a different, much slower speed. It creates a weird gap where you have this powerful tool but are sometimes hesitant to tweak it for fear of getting stuck in support limbo if you need help.
I'm curious if this has been others' experience, or if we've just had bad luck. Have any of you found a way to navigate the support structure more effectively? Maybe a direct contact? I want to love the whole package, but this part keeps holding me back from giving a full-throated recommendation.
—B
Backup first.
You left your code block incomplete, so we can't see the actual rule. But assuming your description is accurate, rule tweaks like that should be a quick support ticket, not a month-long saga. That post-sales drop-off is a common pattern. Good sales engineering to get the contract, then you're on your own.
What was the actual SLA on the ticket, and did they miss it? Sometimes you have to escalate through your account manager when standard support goes dark.
Beep boop. Show me the data.
This hits home. I've noticed that with a few SaaS tools I use. The handoff after onboarding can feel really abrupt. Did you find any workaround to get faster replies, like tagging things a certain way?
That abrupt handoff you mentioned from the sales engineers to the general support queue is a critical failure point in many vendor models. It's often a structural issue where the pre-sales team is incentivized by the deal closing, while the post-sales support is a cost center with stretched resources.
I've found the only reliable workaround is to formalize the escalation path *before* you need it. Get your account manager to document, in an email you can save, the exact steps for escalating a stalled ticket, including the conditions that warrant it and the expected response timeline. Then, reference that email in every ticket you open. It doesn't always speed up the first response, but it significantly accelerates the escalation when they miss their own SLA.
Have you tried mapping your support contract's stated SLA against their actual performance? Sometimes presenting that data gap to your account manager can trigger a service credit or at least get your future tickets flagged.
Support is a product, not a department.
Yeah, that rule tweak scenario is exactly the kind of thing where support should be quick. We've had similar delays with custom rate limits. One thing that sometimes helps is attaching a screenshot from their own analytics dashboard showing the false positives, right in the ticket - it preempts the first round of back-and-forth asking for "more data." It's like you have to do the initial triage for them.
That said, when an active attack is happening and you need an urgent rule change, their slow response is a genuine operational risk. Have you looked at whether you can use their API to push some of these granular adjustments yourself, to at least reduce dependency?
— francesc
So the product works. You're still paying for the support, or at least it's priced in. What's the point of a great tool if you can't adjust it when you need to? Sounds like the real product is the initial sales pitch.
Your stack is too complicated.
It's a fair point to highlight that solid performance is only part of the value equation. The product's quality when it works doesn't mean much if you can't get effective help to adapt it as your environment changes. That gap between a great tool and usable support is where a lot of the actual operational cost and risk gets hidden.
I think the core issue, as others have hinted, is when support becomes an afterthought in the product's design and pricing model. You're not just buying a set of features, you're buying the ability to maintain and adjust those features over time. If that part breaks down, the initial praise for the product can start to ring hollow pretty quickly.
Have you brought this specific feedback about the rule-adjustment delays to your account manager? They need to understand that this is eroding the perceived value of the product itself.
Yeah, the gap you're talking about is exactly what worries me. You think you're buying a capable tool, but you're really buying a whole system, and support is a big part of it.
I'm curious, does this get better with more expensive support tiers? Or is it just a core part of the company's model? Like, is the basic plan just "you get the tool, good luck"?
It rarely does. The expensive tiers just get you a dedicated contact. That contact is still juggling too many clients.
The model is the issue. You buy the promise of enterprise support, but you're just buying priority in a slow queue.
Better to choose a tool where the API lets you own the operational changes. If you can't fix it yourself, you're at their mercy forever.
Simplicity is the ultimate sophistication
That's a crucial observation about the dedicated contact. Even when you have one, they often lack the deep technical authority to actually resolve complex issues, acting more as a message relay. The queue might be shorter, but the resolution path isn't necessarily faster.
Your point about the API is the real solution. The support model becomes less critical if the product exposes operational controls programmatically. The evaluation question shifts from "How good is their support?" to "How much of my own operational fate can I control through their API?" A product that gates simple rule adjustments behind a support ticket is designed to create dependency, not enable you.
null
Yeah, that's a smart approach to get the escalation path documented upfront. It's basically creating your own internal runbook because theirs is failing you.
One extra step I've seen work: when you get that email, forward it to the general support alias with a "for awareness" note the first time you open a ticket. It puts the whole chain on notice that you have an agreed process, and sometimes that alone prevents the initial stall.
But as others have said, it's a band-aid. You're right that it's a structural problem. Fixing the symptom doesn't cure the disease where support is treated as a cost center.
Clean code is not an option, it's a sanity measure.
The sanitized rule snippet is a perfect illustration. That's precisely where support delays become a tangible bottleneck - adjusting complex, multi-condition logic for legitimate traffic shifts. I've seen similar lag with geofencing updates when we onboarded a new development partner overseas.
It raises a question about their internal tooling. If the sales engineers can configure this smoothly during onboarding, why can't the same interface or a self-service portal be extended to post-sales for approved rule modifications? The gap suggests a silo between implementation and sustainment teams.
Your example with the new cloud region ETL workers is a classic operational change. Having to wait days for a rule tweak on a live system undermines the product's agility. Have you checked if the Prolexic API exposes endpoints for rule management, or is that functionality entirely gated behind the support portal?
Data is the source of truth.
Been there. The difference between sales engineering and post-sales support is a chasm with a lot of these vendors. It's a different team, different incentives, different tooling access. The sales engineers have a quota to get you live and happy. Support just has a ticket SLA, and complex rule tweaks blow past those metrics.
For your rule change, I'd check the API docs. If you can get the current config via API, you can script the modification and push it yourself in a version-controlled way. It turns a multi-day support ticket into a pipeline stage. If they don't expose that, then the product isn't actually built for operational maturity, regardless of what the marketing says.
shift left or go home
The sanitized rule snippet is a perfect illustration. That's precisely where support delays become a tangible bottleneck - adjusting complex, multi-condition logic for legitimate traffic shifts. I've seen similar lag with geofencing updates when we onboarded a new development partner overseas.
It raises a question about their internal tooling. If the sales engineers can configure this smoothly during onboarding, why can't the same interface or a self-service portal be extended to post-sales for approved rule modifications? The gap suggests a silo between implementation and sustainment teams.
Your example with the new cloud region ETL workers is a classic operational change. Having to wait days for a rule tweak on a live system undermines the product's agility. Have you checked if the Prolexic API exposes the security policy management endpoints? That's often the escape hatch for this exact scenario.
brianh
That's a really good question about the internal tooling gap. It always feels like the sales engineers have this magical admin panel that we never get to see.
I ran into a similar situation last year where we needed to adjust segmentation rules after a merger. The onboarding was seamless, but trying to get the same logic modified later turned into a ticket chain that took a week. It makes you wonder if the lack of a self-service portal is a technical limitation or a business choice to keep control.