I've been running iboss for about 18 months now, and this pattern has become impossible to ignore. The pre-sales engineering team was, frankly, brilliant. They mapped our entire network topology, ran a flawless proof of concept, and promised a support model that would be "proactive."
Fast forward to post-implementation. Getting a substantive response to a *production* issue feels like pulling teeth. We had a critical email deliverability problem last month—our marketing automation platform was getting flagged because of an iboss rule—and it took three business days and multiple escalations just to get a diagnostic.
Meanwhile, our account manager is already circling to talk about adding more user licenses. The disconnect is palpable.
* Is this just the standard playbook? Fantastic sales engineering to get you in the door, then you're handed off to a generic, overburdened support queue?
* Has anyone actually measured the delta between promised SLA and actual mean time to resolution? I'm betting the numbers wouldn't look great for them.
* What's the trick to getting actual engineering-level support after the contract is signed? Do you need to threaten churn?
It feels like they invest heavily in the funnel top and let the customer success part run on fumes. I'd love to be proven wrong here.
- martech_auditor
martech_auditor
Your observation aligns with a recurring cost structure I've seen in vendor contracts, particularly around resource allocation. The brilliant pre-sales team is a direct revenue driver, often compensated from the sales budget. The post-sales support is a cost center, and its staffing is frequently calculated against a pessimistic utilization metric. The promised "proactive" model usually assumes a perfect, static deployment, not the dynamic reality of a live environment.
Regarding your question on measuring the delta between promised and actual SLA, that's the crucial step. You need to formalize it. Track every ticket. Document the initial response time guarantee in your contract versus the actual time to a diagnostic or workaround. This data is your only leverage in renewal discussions; it moves the conversation from subjective frustration to a breach of contractual service levels. It's often the only language an account manager, whose quota is based on expansion, will truly hear.
The trick isn't to threaten churn, but to demonstrate the operational cost their slow support imposes on your business. Quantify the labor hours your team spends chasing them, or the revenue impact of that three-day email delay. Present that as a discount or service credit requirement on the next license expansion they propose.
Always check the data transfer costs.
Yep, that's the classic vendor bait-and-switch. The pre-sales team is full of solution architects who *build* things, while support is a separate, lower-cost org that just keeps the lights on.
My trick, learned the hard way, is to never let the SEs leave your contacts. I pester my original sales engineer directly for post-sales issues, even if it's "off books." They have more internal clout to get the right eyes on a ticket than you ever will through the portal. It's a bit unfair to them, but it works.
Also, absolutely start logging response times against your SLA. That document becomes your only ammo when the renewal call comes and they want a 15% price increase. Ask them to justify the hike against their own breached metrics.
state file all the things
Your point about measuring the delta between promised and actual SLA is spot on. In my experience, that data isn't just for renewals, it becomes critical for internal justification when you need to build a business case for bringing a function in-house or switching vendors.
The "trick" I've found is to embed yourself in their community or user group forums, if they have them. The engineers who built the product sometimes monitor those channels more closely than tier-one support tickets. Getting a solution architect to comment publicly on a problem can work wonders for internal prioritization.
It's a frustrating cycle. Fantastic sales engineering proves the product can work, then you're left on your own to make it work consistently.