Share what you know with millions of people
Focus is the best place to turn what you know into remarkable content
0
How can services vendors protect themselves from unreasonable enterprise customers?
Usually we think customers need protection, but how should reputable services firms deal with difficult enterprise customers.
Events
- Dos and Don'ts of Small Business Marketing May 29 @ 11 am PT
- Lead Nurturing 202: The Next Generation May 31 @ 11 am PT
- The Tricks to Paid Media June 6 @ 11 am PT
- Display Advertising for Brand Awareness June 20 @ 11 am PT
Related Activity
6 Answers
This is a great discussion.
First off, in my experience as a lawyer and an ERP contracts negotiator, ambiguous contract terms do a disfavor to all. I think smart vendors AND smart customers strive for a "meeting of the minds" and a clear expression of intention. After all, the purpose of a contract is to formally express the parties' intentions with respect to the relationship.
There are two disturbing trends that I see way too often. In one case, parties on all sides spend a disproportionate amount of time worrying about CYA language, and insufficient time building an agreement that promotes mutual performance (more on this below). In the second case, I see buyers who sign contracts that they barely read, let alone understand. The commonality in both cases is that the parties have failed to adequately turn their minds to structuring a relationship that promotes and incentivizes ERP success.
Here's a brief example of how contracts can be used to drive success. I recently completed contract negotiations on behalf of a category-leading manufacturer and distributor. Typical implementation services agreements require full payment by the buyer, regardless of ultimate performance. Our client wanted the service provider to put its skin-in-the-game - to incentivize a successful implementation project. So, we reached a deal that broke the client's payment obligations into five. Each payment obligation would only be triggered upon the service provider's successful completion of project phases. This way, the buyer only pays for what's successful and the vendor only receives payment when it performs. Since the timing of payments depends on the timing of performance, the service provider is incentivized to deliver on time.
This is just one example of how contract terms can be used as drivers of ERP success. The same approach needs to be applied to all contract terms, across all contracts (license and maintenance as well).
As an unreasonable and difficult enterprise customer myself, I can say that vendors should be very clear and direct about what they will deliver, how they will deliver it, and when they will deliver it.
Enterprise customers will always interpret obscure and ambiguous terms in their own favor. Clearly stated deliverables and scope keep menacing customers like me at bay!
:-D
John, to what extent should the contract specify customer responsibilities in addition to vendor deliverables and obligations?
In addition to your great points, I think smart vendors gain a "meeting of the minds" with the customer, regarding key expectations. In your experience, does clear, upfront discussion of mutual expectations help create a smooth project and working relationship?
You need to have realistic expectations set from day one. The expectations set by the Sales Rep will live for a long time regardless of what the contract states. If the Sales Rep states that this service will never go down, it doesn’t matter if your SLA is only three 9’s. The customer will remember the statement of no down time.
Beyond that it is important to set service levels in an easy to read table format. If your service levels are buried 8 pages deep into a lawyered document they will never be read or understood.
Michael,
To your first point, I’ll start with the contract process itself. This is an area that I believe could use some adjustment. Negotiators on both sides (customer and vendor sales) rarely have sufficient input from their respective operations team leaders (front-line managers). This opens a gap in the expertise needed to properly craft these agreements. Consequently, contracts tend to focus too much on the unproductive and unspecific language that Jonathan pointed out and not enough on the specifics of the engagement.
That said, I think contracts should include more language around specific technical details. If the details are too “in the weeds” for the contract itself, the contract should at least refer to supporting documentation. Deliverables referenced in the contracts should be supported and defined by specific detailed templates. This includes technical design docs, requirements docs, implementation plans, etc.
The vendor should also insert conspicuous language explaining that the customer MUST provide clear and accurate information about their internal business and IT environment. Delivery teams should also be empowered to halt activity if vital information is incomplete or ambiguous rather than be forced to press ahead in the wrong direction.
In regards to clear, upfront discussion, again I think this discussion needs to be more specific than it typically is. Customers and vendors alike often hide how poorly managed and documented their internal processes are. This is really the heart of the problem as I see it. When internal processes are immature and undocumented, requirements gathering is tedious and the results are unreliable. This leads to re-work and blown timelines and budgets. Vendors can protect themselves from this situation by requiring the customer to sign off formally on requirements and corresponding design documents before moving into delivery phases. This gate firmly sets the delivery scope and holds the customer responsible for approval to move forward.
Great question and great responses. I have personal insight into this topic and find many of the things recommended to be practical advice.
Effective scope management can make the contract quite easy. Instead of trying to eat the elephant in one bite, divide the work up into 1 - 2 week projects. If you can't get the bite swallowed in 2 weeks, it is too big of a bite.
John identified that the immature processes that are undocumented can bite requirements gathering in the rear. Enterprise software needs to be agile enough to document and fix each process in quantifiable ways before moving on to the next process. The underlying enterprise systems that created the immature, undocumented process should be left alone. There is no way it is nearly agile enough to drive immediate benefit.
This approach allows the contract to be pretty easy. I, the vendor will deliver X value to you in 2 weeks. At the end of that time, I've eithered delivered the value and you continue to invest in the solution or we part ways, no harm, no foul. Latent expertise resides in every company. These employees know which processes are utterly broken and in need of instant repair. There you will find the passion to finally be able to fix it that provides instant user adoption of their own solution. The elephant is way too big to swallow.
Answer This Question