At any given time, I'm in the process of helping three or four Real Story Group research subscribers through a procurement process. Oftentimes, the most complicated part of the process isn't creating an RFP, determining the short list, putting together the evaluation team or use case scenarios. It's normalizing the pricing.

Take one recent DAM procurement I advised on:

Vendor A's pricing was based on the number of assets in the system - and the proposed pricing was for "up to 1 million assets." The number of users or servers the software was running on didn't effect pricing. This particular customer had planned to have about 2 million assets migrated into the system within 2 years, yet per-asset pricing over 1 million assets was not included.

Vendor B's pricing was based on the number of named users of the system, and a price was given for 50 users. The number of assets or servers didn't effect pricing.

Vendor C's pricing was based on a combination of "casual" and "power" user pricing. "Power" users, such as administrators, were more expensive ($800 per user) than casual contributors ($250 per user). They based their estimate on 20 power users and 80 casual users. An "unlimited" number of assets could be put into the system.

Vendor D's pricing was server-based, allowing for unlimited users and assets, with no benchmarks on the typical number of users that might log into to a single instance of the software.

Finally, Vendor E's pricing was based on a combination of 50 concurrent internal system users, unlimited users of the external portal application for 3rd parties to access assets, AND number of servers. 

Normalizing pricing and comparing apples to apples in such cases is a big challenge. I tend to do this in a spreadsheet, where I work to specify with our customers a 5-year plan for number of users, assets, and servers, and then normalize the pricing based on that. Adding services and support costs to that can bring you to a rough TCO, or total cost of ownership, over the near- and longer-term. What I often find after normalizing pricing is that the "cheapest" and "most expensive" vendors at first glance very rarely end up that way, when TCO over a five-year period is considered.

Web content management procurements can offer a similar myriad of pricing options, such as per domain, per user, per items, or per server. Staging and development instances of the software are sometimes, but not always, less expensive than the production instance. 

Search tools, by contrast, are sometimes priced by the size of the index, so the more content you make searchable - the more expensive it gets.

For every product we evaluate in our research, we outline details of how vendors typically price their software, and the range of a typical deal. This helps our customers narrow down to an appropriate short list based on their budget, which is often a key criteria for selection. 

But increasingly, vendors are offering multiple options, only adding to the confusion. In the last six months, I've seen one DAM vendor do a bid that was $800k for a large Fortune 100 corporation, and then bid $180k for a very similar package when pitching to a non-profit. I often say that buying enterprise software is akin to bartering for a handmade basket in a third-world market -- it's all negotiable, and $180k is better than $0.

But the point here is, don't just look at the price on the "investment" line of the proposal and think the story ends there. Uncovering the real story of vendor pricing takes diligence, investigation, and normalization against the competition.