Relevance AI after 12 months - honest review from a mid-market SaaS team

Thanks for this, it's really helpful. The pricing black box is a huge concern. We're currently trialing them for a marketing automation pilot, and our sales rep has been vague about how usage tiers actually work.

Can you share a bit more about what happened when you tried to get your data out? Was it a technical hurdle or more of a contractual/process one? That's my biggest fear right now.

And yeah, the feature emails during our trial have been constant. It does feel a bit scattered.

The data export issue was a frustrating mix of both, honestly. It wasn't a simple API call you could run - the "export" in the admin panel only spits out raw logs, not the processed/structured data from their AI workflows. To get the actual scored leads or categorized support tickets, we had to file a specific support ticket. That took weeks and they delivered it in a messy JSON format that was a pain to reintegrate with our BI tools. It felt intentional.

On pricing vagueness, your experience matches ours. Our "campaign spike" was from automating social media replies - their cost per "workflow execution" wasn't clear until we saw the invoice. I'd push your sales rep *hard* for written examples of what 10k vs 50k "executions" looks like in your pilot. If they can't map it to concrete actions, that's a red flag.

That processed data export hurdle is a classic move. I hit a similar wall with a different platform last year. Their "export logs" function was just timestamped API calls, completely useless for actually understanding customer intent or workflow efficacy.

The messy JSON delivery after a support ticket screams "friction as a feature." They're counting on most teams not having the bandwidth to parse and remodel that data, so they just stay put. It's not an engineering oversight, it's a business model.

Have you found any workaround, like scripting something to scrape the processed data from their front-end? It's a pain, but sometimes that's the only way to avoid their gatekeeping.

Your point about vendor lock-in really hits home. We're evaluating them for email campaign personalization, and easy data export is a must-have for our own reporting.

How much of a delay did that "support ticket for processed data" actually add to your analytics cycle? Was it days or weeks? Trying to gauge the real operational impact.

Thanks for the detailed rundown. Your "good" points on usability are really important - a tool that teams can actually adopt is half the battle.

The post-90 day support cliff is a serious red flag, and one that doesn't get talked about enough during sales. It often signals a team stretched too thin. Did you find any way to escalate those production issues, or was it just a ticket black hole?

And you're spot on about the total cost being more than the sales deck. It's always the operational friction - like the data export struggle everyone's chiming in about - that becomes the real tax.

That post-90 day support drop is exactly what we're worried about during our own evaluation. You mentioned escalation paths. For those production issues, did you ever find that going back to your original sales contact made a difference, or had they completely handed you off by that point? I'm trying to figure out if having a champion in the account management side helps, or if it's truly a universal cliff.

Your point about the real tax being operational friction is so true. It makes me think the total cost isn't just the invoice, but the internal hours lost to navigating those hurdles, like chasing data exports. We're building that into our TCO model now - adding a "friction multiplier" for any vendor that isn't crystal clear on data portability.

Great question on the escalation path. In our case, going back to the original sales contact did get a response, but it was just them forwarding our email to the support queue with a "please prioritize" note. Zero actual pull after the handoff.

Your "friction multiplier" idea is a brilliant way to model this. We started doing something similar, but we call it the "exit energy" cost. It's not just data export, it's the cumulative drag from unclear pricing, slow support, and poor documentation. That energy drain often outweighs the subscription fee over a year or two. Have you settled on a specific formula or metric for that multiplier yet? I'd be curious to compare notes.

Thanks for sharing this. I'm evaluating them for CRM integration, so this is exactly what I need to hear.

You mentioned the post-90 day support cliff. Did you notice if this drop in responsiveness applied to technical issues only, or did it also affect their willingness to help with strategic questions about scaling the platform? I'm trying to figure out if the hands-off approach is just for break-fix or if it's a broader abandonment of the partnership vibe.

Also, the "constant feature emails" point hits home. In your view, did the steady stream of new announcements ever materially break or change an existing workflow you'd built? Or was it mostly just noise?

The support drop absolutely hit both. We had a legit scaling question about sharding their Postgres connector for a high-volume pipeline. Took four days for a reply that just linked to a generic docs page about their generic "scalability features." That was the moment we knew the "partnership" talk was pure sales. It's a break-fix ticket mill after the honeymoon.

The feature emails were mostly noise, but twice they announced deprecations for older API versions with short timelines, which did break some sync workflows. Had to scramble to update. It felt like they were chasing shiny objects for new sales, not maintaining stability for existing customers. If you're building anything mission-critical on their API, subscribe to their changelog RSS and treat it like a critical alert.

Your experience on the post-90 day support drop mirrors ours. That cliff wasn't just about slow tickets, it was a complete shift in tone. They went from "how can we make this work for you" to "that's outside the scope of support."

Regarding the total cost, you're right that the invoice is only part of it. We started logging the internal hours spent on workarounds for their opaque pricing and data export hurdles. Over a quarter, that "friction tax" added up to about 15% of the actual subscription cost. Makes you question the ROI.

The tone shift is exactly it. That "outside the scope" phrase is their tell. It means their post-sale resourcing is a deliberate choice, not an oversight.

Quantifying the "friction tax" at 15% is more useful than you might think. We use that logged overhead figure directly in renewal negotiations. When they ask why we're pushing for a discount, we cite that percentage as the operational deficit we're absorbing. It reframes their poor service from an inconvenience into a quantifiable contract problem.

Absolutely, framing it as a quantifiable contract problem is the key move. We've done something similar, but we found we need to present it with a specific audit trail to be effective. Just saying "it's 15% overhead" got countered with "can you provide evidence?"

Now we come to the table with a simple spreadsheet exported from our ticketing system. It shows:
- Ticket #, date, summary (e.g., "Ticket #3429: Request for data schema for export")
- Hours logged internally (0.5, 2, etc.)
- Vendor response time (in business hours)
- Resolution: "Provided documentation" vs "Workaround built internally"

The "outside the scope" responses become a clear column. When you point out that 30% of tickets in a quarter were met with that phrase, it shifts the conversation from our "frustration" to their defined service boundary, which often contradicts the implementation scope discussed in sales calls.

Do you attach your logged hours to specific ticket IDs from their system, or do you keep your own parallel log? We've had pushback when our internal hours don't map 1:1 to a "support ticket" in their eyes.

Scraping the front-end is the pragmatic workaround, but it's a fragile, time-sink solution that becomes part of your "friction tax." Been there. We had to do it for a compliance audit once.

The bigger red flag for me is their architecture choice. If processed data isn't directly accessible via a sane API, it often means their internal data model is a mess. You're not just fighting gatekeeping, you're dealing with a system that can't easily expose its own outputs.

That said, if you're forced to scrape, do it with Playwright and tag all requests with a header from your internal monitoring (like a trace ID). At least then you can quantify the cost and have logs when it inevitably breaks after a UI update.

The contract fine print is the only reliable part of their offering. Ours had a clause capping quarterly price increases, which saved us from the worst of their opaque usage-based billing. If you're still negotiating, push hard for that.

Your point about new toys versus core stability is painfully accurate. We saw three separate UI overhauls for the workflow builder in one year. Each one broke our custom CSS snippets for white-labeling, requiring dev time to fix. Zero value added for us, pure churn.

We built our own usage monitoring and alerting before their billing cycle closes. A simple cron job hits their API for usage metrics daily, compares it to our forecast, and triggers a Slack alert. It's a stupid tax we have to pay, but it's cheaper than their surprise invoices.