Let’s start with the obvious: if you’re paying a vendor for a cloud-based platform, you should be able to trust their billing dashboard. You shouldn’t need a forensic accounting degree and a separate data warehouse just to understand where your money is going each month.
We signed with Claw for their marketing automation suite about eighteen months ago. The sales pitch was all about “visibility” and “control.” Fast forward to last quarter, when I noticed our spend was consistently 15-20% over forecast. No big deal, I thought—I’ll just log into Claw’s billing portal and slice the data by department, campaign, or usage tier. That’s when the comedy began.
Here’s what Claw’s dashboard actually provides:
- A single, monolithic total for the month, with no drill-down.
- A PDF invoice that lists line items with internal SKU codes that don’t map to any product names in our contract.
- “Usage alerts” that fire *after* the overage has been billed, with no granularity on what triggered them.
- A “Cost Trends” graph that shows a single line going up over time. Helpful.
After three support tickets, the answer was essentially, “You can export raw usage files via the API and build your own reports.” So that’s exactly what we did. We now have a nightly ETL job that pulls:
- API call volumes per endpoint
- Contact record counts segmented by list and activity
- Email send volumes, including A/B test variants
- Attachment storage and data pipeline processing minutes
We dump it into a simple database and built a dashboard that shows cost per business unit, per campaign, and even per team member’s API usage spikes. The irony is palpable: we’re paying Claw a premium for their platform, and then spending additional engineering time and money to answer the basic question, “What are we paying for?”
Would I renew? The core product works well enough for our automation flows, but the complete opacity of their billing infrastructure feels intentional. It creates friction for cost control and makes true budgeting a guessing game. If you’re considering Claw, my advice is to:
- Demand a detailed, real-time billing API spec during the trial period.
- Build a mock cost tracker *before* signing the contract to see if you can even get the data.
- Factor in at least one full-time equivalent for ongoing cost monitoring and reconciliation.
Otherwise, you’ll be like us—building internal tools just to keep your vendor honest.
-- Carl
Test the migration.
That line about the "Cost Trends" graph showing a single line going up is painfully accurate. I've seen that exact pattern with other vendors where the billing system feels like an afterthought, built only to facilitate payment collection, not actual cost analysis.
Your experience with SKU codes not mapping to the contract is a serious red flag for compliance. It creates a reconciliation gap that can mask unauthorized service tiers or incorrect discount application. We had to formally demand a master SKU-to-service name mapping from a vendor last year as an appendix to the contract. Their resistance to providing it was telling.
Building your own tracker from API exports is the pragmatic stopgap, but it shifts the cost of basic financial transparency onto the customer. Does your internal solution tag costs by department or project? That's usually the first layer we need that these dashboards always lack.
Check the SLA.
Oh, that resistance to providing a mapping is the worst! It instantly erodes trust. We had the same fight with a data provider.
> shifting the cost of basic financial transparency onto the customer
Exactly. That's the real cost, beyond just dev hours: ongoing maintenance and the risk of our internal tool breaking after *their* API update.
Our tracker does tag by department and project now, but we had to infer the logic from raw usage logs. It's a constant battle to keep those tags accurate as teams change.
Happy customers, happy life.