Skip to content
Notifications
Clear all

Help: Jasper's support took 5 days to answer a simple question.

2 Posts
2 Users
0 Reactions
5 Views
(@infra_architect_rebel_alt)
Estimable Member
Joined: 2 months ago
Posts: 142
Topic starter   [#2588]

Let me start by saying I'm not surprised, just disappointed. This seems to be the new standard for SaaS companies that have scaled beyond their operational maturity. You build a complex, distributed platform promising AI magic, but you can't manage a basic ticketing system with reasonable SLA. The irony is palpable.

My specific issue was a straightforward infrastructure and billing question. I needed to understand how Jasper's "AI engine" selection maps to actual, billable API calls behind the scenes—specifically, whether switching between "modes" in the editor incurs different costs per token, and if there's any way to audit this via usage logs. This is critical for cost control, something any professional architect would ask before committing a team's budget.

Here's the timeline, because it's a masterpiece in modern support "efficiency":
* **Day 0:** Submitted a detailed query through their support portal, attaching screenshots of the ambiguous UI and my billing page.
* **Day 1:** Auto-reply acknowledging receipt.
* **Day 3:** A generic "our team is looking into this" message.
* **Day 5 (late afternoon):** Finally, a human response. The answer was essentially, "Different modes use different models with varying costs. Detailed breakdowns aren't available in your dashboard."

Five days for a non-answer that boiled down to "trust us, you're being billed correctly." If I designed a mission-critical system with that kind of latency for a simple metadata query, I'd be fired. Imagine if your cloud provider took five days to tell you how their instance types map to vCPUs.

This isn't just about slow support; it's a symptom of a deeper issue. When a company's architecture and pricing are so opaque that even simple explanations require a week-long triage, it signals a lack of operational discipline. In my world, we build observability and transparency *into* the system from day one. Your usage metrics and cost drivers should be as accessible as the generative text box.

Has anyone else hit this wall? Specifically:
* Found workarounds for getting actual, technical answers about model usage and infrastructure?
* Managed to get a proper, detailed billing report out of them?
* Seen any improvement in response times on higher-tier plans, or is it the same "scale without support" story across the board?

I'm evaluating whether to propose Jasper for broader team use, and this kind of operational opacity is a significant red flag. Building on a platform you can't debug or understand is like deploying a microservices architecture without distributed tracing—you're just asking for expensive, frustrating chaos.


keep it simple


   
Quote
(@sre_journey)
Active Member
Joined: 1 month ago
Posts: 13
 

Ugh, that timeline hits home. We run into this exact same pattern with some of our cloud vendors. The multi-day "we're looking into it" for something that should be in a public FAQ feels like a process failure, not a capacity issue.

I've started treating support SLAs as a key part of our vendor SLOs during procurement. If they can't be transparent about response times for billing and architecture questions, it makes me wonder what their internal incident response looks like. Your question about auditing API calls per mode is totally valid, we'd need that for our own cost attribution.

What was the actual answer on Day 5? I'm morbidly curious if it was helpful or just a deflection.


@sre_journey


   
ReplyQuote