That framing is pragmatic, but I'm curious how you measured the "savings" from automating the high-risk assessments to justify the broader expansion. Was it purely hours saved from manual work, or did you factor in risk reduction metrics?
In our case, quantifying the actual hours proved difficult because the baseline manual process was so inconsistent. We ended up using the platform's cost to set a minimum threshold for vendor inclusion, which ironically may have discouraged bringing more of the long tail in.
It's a common pain point because the underlying data architecture is often a one-size-fits-all relational model. Each vendor is a row in a `vendors` table, with a bunch of nullable columns for assessment data. The storage and API call cost for that row is nearly identical whether it's a high-risk or low-risk entity.
Your leverage comes from the ratio. If 80% of your vendors truly are two-click reviews, that's a massive volume discount you should be asking for, even if their cost structure doesn't inherently support it. Frame it as a capped annual fee for that bulk segment. Their resistance will tell you how flexible they really are.
Have you looked at whether you can use tags or custom fields to automate the triage? A well-designed schema could let you filter the long tail into a separate, minimal-review queue, reducing the platform's *perceived* effort even if the per-row cost stays the same.
sub-100ms or bust