Compromise
A deep dive into key aspects of no-code sales.
It’s not always easy selling standardized products into a custom software space that for 50 years has been one big negotiation. There is an incredible headwind of IT understanding, bureaucratic inertia, executive policy and SOPs that dictate contract terms which are in contrast to the standardized terms and conditions that product companies offer. Sometimes a lack of understanding of how to navigate these tricky conflicts by a new-to no-code salesperson can result in lost opportunities. So how does a motivated salesperson bring these two parties together to create a sale? It happens every day.
Let’s begin by taking a look at the terms that usually create the most conflict in a no-code environment. First, there is code ownership, and the need for licensing. Some customers have a long history of “always controlling their own code”. In a no-code environment this is frequently not possible, or at the least non-standard. Second there are the “code escrow” provisions; not all platform as a service providers are willing to escrow their entire platform. Next, there are SLAs; whether the product provider offers them or not, the SLAs they do offer are frequently different from the standard requirements of the customer. And if all that isn’t enough to have conflicts over, when it comes to professional services, every element from T&M vs Fixed Bid, hourly rates, etc. is usually up for negotiation, and may be a source of conflict. And finally, one of the more interesting sources of conflict occurs when a customer insists everything should be fixed cost, in advance, but where the vendor is offering a consumption based model (we recently had to quote a 10 year RFP of our consumption-based model, but on a fixed price!).
But, before you throw your hands up in the air, know that you are not alone. The product companies are aware of all of these conflicts, and have been dealing with them the best that they are able. They aren’t looking to lose work either. Still, the demands of being a product company means they can’t always give in to every demand either.
So what do you do when one of these issues arise, and it’s a conflict?
Well, begin by realizing that the last person you want to ask to change their terms is the customer. Getting a large bureaucracy to turn is no small feat and usually tackled only by the most experienced of enterprise sales people and usually with the help of a breadth of relationships at the target organization as well as a motivated internal champion or two. But the competition may also have those same connections, and they are offering an easier sales path; it’s not worth losing a sale to them over something avoidable.
However, on the other hand, the larger the product company, the more difficult it is for them to change as well. And, if the product company is large enough, they generally have enough authority in the marketplace such that they don’t frequently have to make changes, or worse, they are perfectly willing to lose your opportunity to your competitor rather than do anything custom. Do take note though: despite what they will tell you, even the very largest product companies add special terms to contracts if the deal is large enough.
So as a point of fact, it’s this very balance that dictates where the most compromise will ultimately need to be made. Look at the relative strengths of the customer and the vendor, the size of the contract, and it’s importance to the vendor, and then ask yourself the question; “which party stands to gain the most by compromising to make this work?”.
And then ask that party the question. If you are asking the product company, don’t just ask the frontline support representative; they are typically not authorized to do anything but what standard policy dictates, and may not even be aware of an escalation path. Instead, be sure to make an inquiry at the executive level. Have that discussion with the right party. Then, get creative. What do I mean by that?
Well, assess the risks versus the rewards of any particular contractual change. For example, If the argument is over an SLA point such as “Recovery Time Objective”, which maybe the customer requires a faster RTO than the vendor’s SLA offers, then ask the product vendor the question “how many times has a customer needed to invoke the disaster recovery SLA?” Hopefully the answer is zero! And then ask; “what is the penalty of missing that SLA by an hour?”. Typically the penalty is a lot less than the value of the contract. So, if the likelihood is near zero, and if the cost is a lot less than the value of the contract, then might not this compromise be worth it? Hopefully your product vendor is smart enough to understand that risk-reward equation.
In the end, we can tell you from experience that it is exceedingly rare that a motivated sales person can’t get the deal done in the face of some sort of technicality like this. It does happen, but usually only over some structurally unchangeable term, for example a platform as a service company simply can’t offer its source code or even a perpetual license to it. But again, these scenarios are rare…probably around 1%.
For 99% of the scenarios, there exists a compromise, if you are motivated to find it. Happy Hunting!
