How Many Procurement Templates Does a Company Need?

One company I know of has only a single procurement template that covers purchase of “all works, products, and services.”

Another company has a different template (in both one-off and master versions) for purchase of each of the following:

  • Professional services (in other words, consulting)
  • Other services (such as catering and cleaning)
  • Software (without related services)
  • Software (with related services)
  • Technology equipment
  • Other equipment
  • Commodities (for example, office supplies)

Where does your company fall on the spectrum from minimalist to exhaustive? And why? Sorry to be asking such a basic question, but I haven’t had much of a chance to see the procurement forest, what with my focus on individual template trees.

I could probably cover all permutations in a single Contract Express automated template. But for this exercise, let’s assume we’re in a Word-template world.

About the author

Ken Adams is the leading authority on how to say clearly whatever you want to say in a contract. He’s author of A Manual of Style for Contract Drafting, and he offers online and in-person training around the world. He’s also chief content officer of LegalSifter, Inc., a company that combines artificial intelligence and expertise to assist with review of contracts.

7 thoughts on “How Many Procurement Templates Does a Company Need?”

  1. The “one size fits all” procurement template is one of those attractive nuisance concepts that companies fall for with alarming regularity, largely because companies don’t think much about procurement and when they do they only think about how much money they can save. I spent a decade as the chief procurement lawyer for a large company, and on my watch we had templates that understood the difference between goods, services, technology, SaaS, products vs. systems, types of support, ancillary professional services, one-off deals, long-term commitments, strategic and tactical suppliers, etc.

    Every type of deal has unique features. If you give a procurement officer a single template (s)he’s going to think the vendor must be bludgeoned into accepting every clause in it. The vendor will resist, and the officer will have to go back to counsel time and again for clarification. The omnibus form pretends to save money, but it ultimately wastes it.

    That was the diplomatic response. Ask me what I really think about the subject.

  2. I completely agree with Vance. I spend most of my time on the vendor side of IT products/services deals and dread when a customer wants to use their one-size-fits-all template. You end up spending much of your time on things that aren’t relevant to the deal at hand. It’s particularly a problem with non-tech companies who don’t see any difference between a contract for watering the plants and running a data center. A particular challenge are forms that try to treat everything, whether hardware, software, or services, as a “service” or vice versa.

    On our procurement side, we have templates for (at least) hardware purchase, software license, consulting and general services, cloud services, maintenance and support services. There are probably a bunch of others, but I don’t spend enough time on that side of the house to have dealt with them.

    Of course, the unspoken question here is who controls the paper. We’d much rather lead with our form that we humbly think is better suited for our products than a general-purpose template, but how that plays out is a matter of bargaining power and salesperson desperation.

    • I sit on the other side of the fence – I advise on procurements for a large organization that procures hundreds of millions of dollars worth of goods and services each year. (I don’t know our exact figures but it wouldn’t surprise me if it’s actually in the billions). There are a number of other lawyers on my team, but I have an IT background so typically the IT procurements end up on my desk.

      And I confess that yes, aspects of our standard procurement documents are not well suited to IT procurements. IT procurements are only a small percentage of our total procurement budget, so our standard documents tend be drafted with other procurements in mind. This does drag the process out somewhat – for example, we have provisions governing IP ownership that make sense when we’re hiring a consultant to design mechanical devices for us, but make no sense when we’re purchasing a cloud service. I do my best to accomodate for this at the negotiation stage of the procurement by stating right up front “We are willing to strike clause X, Y and Z as we recognize they make no sense in this context”, but that’s not a complete solution by any means.

      But the IP clauses are low-hanging fruit. In my experience, clauses which are clearly irrelevant (or worse) are easily dealt with. What takes up the most time in negotiations are discussions around clauses which are relevant and over which there are genuine disagreement – for example, the insistence of IT vendors in limiting liability for any consequential or special damages and in any event limiting total liability to fees paid. Those limitations are simply unacceptable to us in many cases. So we’ve considered drafting procurement templates specific to IT or and we’ve considered using the vendor contracts as a starting point, but those ideas never get any traction internally because they don’t seem like they’ll really speed things up much.

      Sorry to hijack the comment thread. I’m certainly not trying to be argumentative – I fully appreciate the frustration IT vendors feel when they deal with us. I just wanted to provide some perspective from the other side.

      To try and bring this comment back on topic: we have about 8 procurement documents we use, depending on what is being purchased, how its being purchased (competitively or sole-sourced), the complexity of the purchase, whether we’re willing to negotiate terms and conditions etc. Each one of these allows for some customization and depending on the complexity, lawyers will have some involvement in their preparation, either at the drafting or review stage.

  3. Absolutely agree that the one-size approach is not ideal. As a vendor attorney, there’s nothing more painful than trying to make an MSA work for software services that was designed to work just as well for buying pencils. Like InHouseGuy says, though, sometimes you have to suck it up if you want to get the deal done!

  4. Ken:

    I agree with everything said so far, except that I’ve seen one really intelligently designed alternative. I wish I could name names, because they deserve kudos.

    They have a master agreement that is quite short. It deals with what we’d think of a boilerplate, for the most part — ordinary confidentiality, independent contractor status, etc.. Then they have exhibits that add terms related to particular but broad categories of things they buy. Professional services that are like consulting is one of them. Another is software as a service. They have others; I bet they have one for building-related services, for example. Then you and they write schedules that are governed by the master and one or more exhibits. If they don’t have an exhibit that fits, that just means a longer schedule and more negotiating time.

    I think their setup must also have the incidental effect of weeding out the kind of bull-headed linear thinker that Vance describes, because they have always been smart to work with — and I say that having been on the losing end of some negotiating points with them.

    For ourselves, there’s one thing that we buy a lot of from multiple vendors, and it only has a fee variables (price, quality, speed). So we have a form contract for that, which is very specific. Beyond that, we prefer to use the vendor’s contracts. They know their stuff better than we do, so their form is probably a better starting point in substance than some generic thing I create would be. (Style is a different problem.)



Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.