In the old days, bigcorps just wouldn't engage with ISVs directly at all. Instead, as an ISV, you'd engage the services of an 'integrator' or 'reseller' — a sma

In the old days, bigcorps just wouldn't engage with ISVs directly at all. Instead, as an ISV, you'd engage the services of an 'integrator' or 'reseller' — a smaller-scale but still-large entity that you'd have a support contract with — where the integrator would then have a support contract with the bigcorp. If you were having an issue with the bigcorp's product, you'd complain to the reseller, and then they'd complain to the bigcorp. And because the bigcorp only had a few such resellers as clients, each reseller would actually be able to get the bigcorp on the line. This was (and still is) the IBM model for B2B software; and it was also the industry-standard model for game developers (interacting with the platform owner through a "publisher" — essentially taking the role here of an integrator.) It's probably still the industry-standard model for musicians to engage with big record labels. I'm honestly not sure why Google doesn't push for this model. Their focus on "scaling services as much as possible using as few human support staff as possible" means this model is essentially perfect for them. But they ignore it. Maybe because they think it'd make them look like a dinosaur? (I know they do do it in some places — we use GCP, and apparently, to be able to switch from card-based billing to invoice-based billing, we're required to also switch from direct GCP support, to a support-contract with a GCP reseller. So we'd be paying the reseller — the invoices would be riding as accounts-receivable on the reseller's books, rather than on Google's!)