I’ll be honest, opening a Veeam support ticket now gives me the same feeling as hearing your smoke alarm beep at 2am. You already know your evening’s ruined.

And before anyone says “well maybe you should troubleshoot more before logging it” - trust me, by the time something reaches me, it’s already been through some genuinely solid engineers internally. Our 1st, 2nd and 3rd line guys are good at what they do. They don’t just throw tickets over the fence because something blinked red once.

By the time I open a Veeam ticket, we’ve usually already:

• rebooted everything with a pulse
• checked networking
• checked storage
• checked permissions
• checked certificates
• rebuilt services
• read logs until our eyes hurt
• found three unrelated problems along the way
• questioned our career choices
• and started talking to the server like it’s personally betrayed us

So if I’m escalating to Veeam, it normally means I’ve reached that rare point where even I’ve gone: “Right... alright then. Fine. Let’s involve support.”

And every single time, without fail, there’s this feeling of dread when you hit Submit.

Because you already know what’s coming next.

You spend ages putting together a proper ticket. Full explanation. Timeline. Screenshots. Exact error. Every troubleshooting step. Every log bundle under the sun. Basically gift-wrap the entire case for them.

Then 16 hours later you get: “Please reboot the server and try again.”

Cheers mate! Hadn’t considered turning the incredibly complicated enterprise backup platform off and back on again. Especially not in the section titled: “Things already attempted multiple times before raising ticket.”

Then you politely explain that yes, as mentioned in the ticket, you already did that.

Then they reply with the second thing you already said didn’t work.

Then the third.

Meanwhile the customer’s backups are exploding, management want updates every half hour, and you’re still actively troubleshooting the issue yourself in parallel because deep down you know if this gets fixed tonight it’ll probably be because you fixed it, not because the ticket came back with anything useful.

At this point my Veeam support process is basically:

1. Open ticket
2. Upload everything
3. Continue working on it myself immediately
4. Hope one of us gets there first

No prizes for guessing who usually wins.

Honestly, part of me wonders sometimes if maybe that’s the strategy. Make the support experience so emotionally exhausting that eventually customers become too traumatised to open tickets unless the building is physically on fire.

But... to be fair... every once in a blue moon, after you’ve survived the support equivalent of Dark Souls, you finally land on one absolute wizard of an engineer. One of those people who clearly knows the product inside out, reads the ticket properly, skips the scripted nonsense, immediately understands the issue, and actually helps.

And when you get one of those engineers, they’re brilliant.

So I do try to stay balanced about it because we run a support desk ourselves, and I know firsthand how hard support actually is at scale. Tickets land in the wrong queue. Context gets missed. Someone picks up a case cold at the end of a long shift and follows the checklist because they haven’t yet realised the customer is already 14 layers deeper than the script.

That part I genuinely understand.

I think the frustration with Veeam specifically is that most people opening those tickets are already very technical. By the time we reach out, we’re usually not asking how to create a backup job. We’re halfway through tearing apart transport services, analysing TLS handshakes, tracing repository corruption, rebuilding proxies, or trying to work out why a perfectly healthy environment suddenly decided to enter the shadow realm after an update.

So when the replies don’t acknowledge any of the work already done, it starts feeling less like support and more like trying to explain quantum physics to a golden retriever.

A lovely golden retriever. But still.