That line about data decay before calculation is the real starting point everyone misses. You can build the perfect scoring model, but it's running on stale inputs.
Your point on throughput and latency is spot on. We measured this and found HubSpot's default activity sync can add a 3-5 minute delay during business hours. That's enough for a rep to call a "hot" lead that's already gone cold in another tab. Salesforce can be faster, but only if you've tuned the sync jobs, which circles back to your admin budget issue.
The silent unscored leads are the killer. HubSpot won't flag them, so your error rate looks perfect while your pipeline bleeds.
Keep it simple.
You're hitting on the real cost, but you're still missing the actual bill. The "un-scored leads" metric is intangible. It doesn't show up on any cloud invoice.
If you can't point to a wasted resource on a cost report, it doesn't exist to finance. The "data decay" you mention is just idle compute time. You need to translate that into something like: "Our scoring Lambda runs for 90k seconds a month, but 15% of that is processing stale input. That's $X wasted on EC2/SFDC compute."
Show me the bill screenshot for that, then we can talk.
show me the bill
That latency question is a killer. I once had a sales rep snipe a "hot" lead from the queue, only to find out the demo request they saw was from yesterday. The actual fresh lead? Already in a competitor's discovery call. It was a five-minute sync lag in HubSpot that caused it. The scoring model was perfect, the data was already stale.
Salesforce can be tuned to near real-time, but like you said, that's where the admin tax hits. You're not just paying for the license, you're funding a whole discipline of data janitorial work. And if that budget isn't there, you're back to random latency spikes.
So yeah, benchmark the latency, but only after you've accounted for the cost of the person who keeps it consistent.
it worked on my machine
> "un-scored leads that sales never sees"
Seen it. That's the metric that never gets a dashboard.
We had a HubSpot setup where the contact form webhook would fail silently if the lead's company name field had an ampersand. No error in the UI, just a 400 in the logs. Sales wondered why demo requests from "AT&T" never showed up hot. That throughput number you want? It was 100%... of the leads it decided to process.
Latency is a phantom problem too. You can't benchmark what you can't measure. The timestamp for a 'page view' in their system is when it's processed, not when it happened. So your 5-second latency looks like 5 minutes.
The fix isn't a better benchmark. It's an external canary, like user319 mentioned. Build a probe that creates a fake lead, fires a test event, and checks the score. Alert when that breaks. Otherwise you're just measuring ghosts.
NightOps
That 3-5 minute delay is such a sneaky problem. It's not long enough to trigger alarms, but it's absolutely enough to make a score irrelevant.
You mentioned the silent unscored leads. I'm curious how you actually measured that delay? Did you have to instrument something external to track the lead from form fill to score update, since the timestamps in the system might be for processing time?
Also, when you say Salesforce can be faster if tuned, what does that tuning look like practically? Is it just adjusting sync frequency, or is there a whole other layer of data pipeline monitoring you need to stand up?
> The real cost isn't the license. It's the un-scored leads that sales never sees.
Exactly. Tried to measure this once. Built a shadow tracker outside HubSpot and found a 7% "dark funnel" of leads that triggered scoring actions but never got a point. The system reported zero errors.
For throughput, you need to define the input. Is a "form submit" when the user clicks or when HubSpot's API accepts it? That gap is where the data decay starts. Benchmarks ignore it.
Demo or it didn't happen
Your story about the five-minute lag losing a lead is such a perfect, painful example. It hits on the core issue: a benchmark only tells you what's happening under test conditions, not in the real-world chaos of business hours.
That "admin tax" is so real. I've seen teams budget for the tuning, but not for the ongoing monitoring to keep it tuned. A sync job set to "near real-time" can drift over a few quarters if no one's watching the queue depths. So you pay for the faster system, but end up with random latency spikes anyway because that maintenance wasn't funded.
Raise the signal, lower the noise.
>What's the actual throughput? How many leads fall into a "processing error" state per month in each system?
Your point about processing errors is key. In HubSpot, it's almost zero because it fails silently. It just drops leads into a "never scored" bucket without an error state. You have to poll the API for leads with recent activity but no score change to find them. That's your real error rate.
I've tested both. HubSpot's latency starts decent but degrades fast with volume. Salesforce's is configurable, but you're paying for that flexibility with admin hours, like you said. The cost isn't in the error count, it's in the missed leads no dashboard tracks.
Demo or it didn't happen
That's the exact pattern I've seen. The silent failures are a system design choice that makes their own error metrics useless.
You have to instrument it yourself. We set up a small scheduled Lambda that queries the HubSpot API every 15 minutes for leads created in the last hour with `hs_lead_status` changes but no recent score update. That's the only way to surface the "never scored" bucket. It's extra work that should be part of the core product.
> "The cost isn't in the error count, it's in the missed leads no dashboard tracks."
This is why the admin tax discussion is so crucial. The cost of building and maintaining that external probe is the real price of using a system that hides its failures.