Mike Wade, VP of Customer Success
During the sales cycle for your new SIEM, you were important. A sales engineer joined every call. Someone built a custom demo around your actual log sources because the "out of the box" claim is never quite 100%. There was a shared Slack channel, and questions posted at 9 PM got answers by 9:15. The account executive said "call me anytime" and meant it, because your signature wasn’t yet on the dotted line.
Then you signed. Within a quarter, the shared channel went quiet. The sales engineer got reassigned to the next prospect. Your lifeline to help became a support portal, a queue, and a case number. The people who knew your environment have moved on, and the people answering you now have never seen it.
There's a term for this: you got tossed over the fence. What makes it worse is what got tossed along with you.
The problem isn’t just that the experience gets worse after the sale. With a SIEM, poor support can become a security problem. When the platform at the center of your security operations isn’t working as expected, every hour spent waiting for help can mean another hour of lost visibility or delayed action against a threat. SIEM vendors should be judged not only by what their platform can do, but by how well they support customers throughout the entire product lifecycle, from resolving issues quickly to helping teams get the most value from the platform.
A SIEM outage is not a productivity outage
It can’t be overstated that if your project management tool has a bad week, work gets annoying, but if your SIEM has a bad week, you are blind.
The SIEM sits at the center of nearly everything a security team does. Detections run there. Investigations happen there. Compliance evidence lives there. Incident response starts with a query and usually ends with several hundred more. When ingest silently drops a source, queries hang, or an upgrade breaks half your scheduled searches, the team isn't just inconvenienced. It has lost visibility, and it may not find out until an auditor or an attacker points it out.
That means support responsiveness for a SIEM is not a nice-to-have line item. It's a security control. It is a compliance requirement. A detection that fires but can't be investigated because the platform is down protects nobody. If you would never accept a firewall vendor who takes two weeks to respond to a broken rule engine, you shouldn't accept it from the platform your entire detection program runs on.
Yet almost every enterprise SIEM vendor treats post-sale support as a cost center to be minimized rather than part of the company offering.
Anatomy of the support farm
If you've operated a big-vendor SIEM for more than a year, you already know the pattern. For everyone else, how the machine works once you're on the wrong side of the fence is as follows:
You open a ticket. Within the SLA window you get a response, because the SLA measures time to first response, not time to a human who understands your problem. The first response is a template asking for information you already put in the ticket. Tier 1 sends you the knowledge base article you read before opening the case. You re-explain. Tier 2 asks for the diagnostic bundle you attached on day one. You re-explain again, this time to someone who possibly never operated the product in production. Somewhere around week two, the case reaches an engineer who can actually help, assuming it wasn't auto-closed for inactivity while you were doing your actual job.
And running quietly underneath all of it is the upsell: for a significant additional spend, you can buy the premium success tier, with faster routing and a named contact. Read that offer carefully. It's the vendor telling you that competent support exists, but the contract you already signed doesn't include it.
The bill nobody itemizes
The direct cost of bad support is frustration, but the material cost is everything around it.
Your senior detection engineers become vendor liaisons, burning hours shepherding cases instead of writing detections. Broken ingest means blind spots that persist for the life of the ticket, and tickets like these are measured in weeks. Workarounds built under pressure calcify into permanent architecture that someone will curse in three years.
Then comes renewal season, and the ugliest part of the dynamic surfaces. The vendor knows that migrating a SIEM is one of the most painful projects a security team can take on. Years of detections, dashboards, automations, and tribal knowledge are locked inside their platform. So by year three, you are less a customer than a hostage, and neglecting your support experience carries no real consequence for the vendor. It isn't an accident or a staffing problem. It's a "rational" business decision enabled by your switching costs. They get their bonus, you get the pain.
Evaluate support like it's a feature, because it is
Whatever SIEM you're considering, including Gravwell, put support through the same scrutiny you put the query language through. A few tests that cost you nothing:
- Open a real support ticket during the POC. Not a softball; something environment-specific, and watch what comes back: a template or a person who read what you wrote.
- Ask who staffs support. Engineers who build and operate the product, or a contracted queue reading from the same knowledge base you can search yourself?
- Ask references about year two. Everyone's honeymoon is great. Ask what happened the first time something broke after the logo hit the vendor's website.
- Ask what fast costs. If reasonable response times are sold as a premium tier, you've learned what the base contract really includes.
- And note the simplest tell of all: if the pre-sales experience is the best support you will ever get from a vendor, the sales team just showed you the ceiling.
What Gravwell does instead
Gravwell's answer to this is a program called Mission Support, and the honest framing is that including dedicated customer service and engineering report with our product is structural, not virtue signaling. We built the company on a model that doesn’ t make support neglect rational: no ingest meter extracting money on renewal, no army of tiered support contractors, no assumption that switching costs will keep you here regardless of how you're treated. When those crutches are gone, support has to actually work.
Here's what that looks like in practice.
You get one dedicated support engineer. The same person, every time, who knows your environment because learning it is their job. No re-explaining your architecture to a rotating cast of case owners.
We have a ‘three email’ rule. If your issue isn't resolved by the third email, the next step is a video call with your engineer. Continuous email escalation is banned as a matter of policy because email ping-pong is where tickets go to die.
Broken query? Working query within 24 hours. If a query isn't performing the way you expect, you contact Mission Support and get back a correct one inside a day. Not a link to the query documentation, the query that produces the answers you needed.
Migration is our project, not yours. Mission Support runs from first contact through long-term operation. It starts with Flight Readiness, where we sit down with you and review every existing detection, dashboard, and automation to decide together what's worth bringing over (this review usually surfaces a pile of assets nobody has touched in years, which is its own small victory). Launch Sequence is where we deploy and configure your instance and migrate the assets, and nothing is done until you've reviewed and signed off. For cloud customers, that's a fully managed migration, ingestion to operational in about 90 days. Self-hosted customers get the same hands-on guidance over remote access. Either way, you get four live training sessions along the way, with the last one on whatever topic your team picks.
There is no risky switchover. We build Gravwell in parallel with your existing SIEM. You cut over when you've validated the new platform, not when a contract date forces your hand.
And the hostage dynamic gets addressed directly. If you're ready to move but locked into a contract with your current vendor, our Replacement Program lets you start the migration now and start paying only after your existing agreement expires. You should never have to pay two SIEM vendors because one of them was counting on your switching costs to lock you in.
Two things Mission Support deliberately doesn't do, because pretending otherwise is how vendors end up with the support reputation this post is about:
- We migrate the assets you have, and building net-new detections or custom integrations is a separate professional services conversation.
- Extracting data out of your old SIEM is on you or on a scoped engagement, since your outgoing vendor controls that door, not us. Clear scope up front is part of why the timeline holds.
Run the audit
Before your next renewal, pull your last five support tickets and read them cold. Count the days to actual resolution, not first response. Count how many times your team re-explained the same problem. Check whether anyone who touched the case understood your deployment.
Then decide whether that's the level of care the platform at the center of your security program deserves.
If the answer is no, talk to us. Better yet, open a ticket with us during a trial and compare it to the last one you opened with your current vendor. That comparison is our Mission Support pitch.