Request for proposal concept with a laptop on a desk.
PHOTO: Shutterstock

Every vendor that sells a digital asset management (DAM) system will tell you that its system is the best, and in some cases the process of selling a DAM system to a new customer is quick and easy.

Unfortunately in cases like that, the story too often goes like this: After researching various products and issuing a request for proposals (RFP), an organization chooses a vendor that has experience with similar customers and ticks the requisite boxes on the RFP checklist. But after a brief honeymoon, challenges arise and the customer realizes that the platform can’t perform specific tasks that are critical for its business.

So what went wrong? Did the vendor’s representatives lie when they filled in the RFP spreadsheet?

In almost all cases the answer is no, because the customer may have just requested particular features in a “tick box” fashion like this:

Functionality Item

Vendor Response

Support for a wide variety of file formats including Photoshop, Illustrator, InDesign, Microsoft Office, etc.


Intuitive, modern user interface


Web-to-publish feature with ability to support a wide range of artworks


Scale to 5,000 registered users globally


Ability to support the workflow as outlined below
(steps X, Y, Z)


The problem with a checklist like that is that it only shows whether a DAM system supports something, when what really matters is how the system supports certain functions — and how the vendor fulfills user needs.

You Need a Great RFP

If you want to have a true win-win relationship with your new DAM vendor, make sure your RFP reflects your real needs.

To help you make your next RFP a work of art, here are 10 tips that will help you find the DAM vendor that best meets your needs.

Related Article: 7 Tips to Improve Your Marketing Technology Request For Proposals

1. Describe Scenarios That Illustrate Your Most Important Needs

Your RFP should include user stories with real-world examples of how you want to use your digital asset management system. Those stories will be especially effective if they feature descriptions of how real people will use the system.

These stories will of course vary from company to company, and some will feature end users while others focus on power users and admins. But the main purpose is to describe what are you trying to accomplish on an overall level, why it is important to your business, who is involved and how each person would ideally like to complete his or her tasks.

This is by far the most important section of the RFP. It should have no more than three to five core stories, with perhaps some additional (much shorter) secondary stories.

2. Include a Functionality Checklist

Your RFP should have a checklist of the functionality you’re looking for. One way to determine the items to include on this list is to identify your “MoSCoW” priorities — the things your new DAM system must, should, could or would have.

But don’t let the list get too long. You are more likely to succeed with a system that handles your five most important processes super well, instead of a system that does 100 things through workarounds.

Related Article: Don't Let MarTech Vendors Sweep You Off Your Feet: A Guide for the RFP Process

3. Provide Vendors With Examples of Your Actual Files

You should give prospective DAM vendors samples of image, video and document files that you would actually use.

You can’t be sure if a vendor’s system will do what you need it to do with files unless you try it with your own files. For example, just within the Photoshop file format there are lots of elements — including transparencies, layers, vector objects, clipping paths and ICC color profiles — that some DAM systems might ignore, thus rendering files unusable. Moreover, some systems cannot handle multi-gigabyte file transfers.

The same goes for lots of other file types, such as QuickTime, TIFF, InDesign, etc. So send prospective vendors actual files for upload to a trial system as part of the RFP process.

4. Provide Vendors With Worst-Case Examples of Your Artwork

In addition to determining whether DAM systems can handle your files, you need to see how prospective vendors’ systems perform when converting your actual artworks (typically in InDesign or Illustrator files) into editable templates. This is especially true if web-to-publish functionality is a requirement of yours.

Until a prospective vendor has converted a couple of your artworks to working templates, you won’t know what the real-life experience will be for your end users.

5. Describe Your Scalability and Hosting Needs

In the sample checklist I included above, one of the customer’s requirements was for a system that could support 5,000 registered users. But in practice, it could turn out that a system that supports 5,000 registered users slows down when just 500 people are using it because the checklist only covered registered users, not simultaneous users.

Just as you need to describe usage scenarios in detail in user stories, you need to make sure that your RFP accurately describes your scalability needs.

When it comes to scalability, different companies face different challenges, including these:

  • High numbers of simultaneous users (perhaps during global product launches, for example).
  • HD or 4K video files that need to be uploaded and transcoded within an agreed-upon time frame.
  • Large files that need to be transferred quickly over long geographical distances.
  • Large multi-gigabyte graphics files, such as Photoshop PSB files.
  • Complex workflows that may tax the workflow engine.
  • Custom integrations that will hammer the API.
  • Large upload or download batches of thousands of assets within one session.
  • Significant numbers of end users in countries that have poor internet connectivity to most vendors’ hosting infrastructures.

If the last point applies to you, and your organization has a lot of employees in, say, China, Australia or South Africa, get a couple of end users in those countries to try out a demo system with real files and templates.

To help prospective vendors get a sense of your scalability needs, provide them with traffic statistics from your current system, if you have them.

When it comes to hosting, I have often heard users say things like this: “Oh, you host on AWS? That’s great. We know it will work well.”

But it isn’t a given that a system will work well just because it is hosted on one of the leading cloud infrastructures. For example, AWS is a fantastic platform, but a vendor could run its system from a single box on AWS, forget to put any kind of firewall in front of it and not back it up. That would be the most unscalable and unsecure system imaginable.

Get vendors to explain why and how their systems will cope with your specific needs.

6. Look for a Configurable, Futureproof System

As the saying goes, the only thing that is certain is uncertainty. You don’t know exactly how your needs will change as time goes by, so if you want a DAM system that you will be able to use for a long time, look for one that can be reconfigured to accommodate changing needs.

Consider which parts of the system you are most likely to need changes to in the future, and then get prospective vendors to demonstrate their products’ flexibility.

Here are some typical areas where you may need flexibility:

  • Branding of the system itself, in the event of a rebrand.
  • The addition of sub-brands to the system that need to be partitioned off, with both new permissions and a new look and feel.
  • Permissions for new countries, departments, brands, user types and franchisees.
  • Multistep workflows for briefing, tagging, approvals, etc.
  • Changes to tagging/metadata taxonomies and search.
  • Image and video transcoding.
  • New classes of artwork for web-to-print/web-to-publish templates, such as banner ads, emailable case studies, event artwork, leaflets, etc.

7. Inform Vendors of Any Integrations You Will Need

These days, it is rare to see an RFP in which the customer doesn’t mention the fact that the new system will need to be integrated with existing systems, such as a content management system, customer relationship management software, an ecommerce platform or product information management software. Once again, what matters most is how a vendor’s system handles integration, not whether the product can be integrated with other systems.

Consider this common request: “Integration with Salesforce required, ideally in the form of an out-of-the-box connector.”

Depending on the scale of your operations, that request could be very simple or very difficult for a vendor to fulfill. So, as always, make sure your RFP includes real-life user stories of how you would like the integrations to work, to give vendors a sense of the scope of the integration project they will have to undertake.

8. Describe Your Asset Migration Needs

Even if you don’t have a legacy system to migrate from, you will have lots of images, videos and documents scattered across various networks and systems that will need to be imported into the new system.

A detailed account of the assets that will need to be migrated doesn’t necessarily have to be part of the RFP, but when you get to the quoting stage, if you want realistic estimates on time frames, potential pitfalls and costs, you need to give the vendor a good overview of your existing assets, including the good, the bad and the downright ugly.

Asset migration can be a messy business, and it is too big of a topic to cover thoroughly here, but you need to keep in mind that a successful asset migration will be crucial to the success of your new system. I will discuss this topic in more detail in an upcoming post.

9. Include a Vendor Security Checklist From Your IT Department

It is of course vital for your IT department to vet prospective vendors to ensure that they can provide an adequate level of security, because you will be entrusting that vendor to safely handle thousands of valuable files.

10. Allow Vendors to Interact With Real Users

This tip isn’t so much about what is included in the RFP as it is about the process of negotiating with vendors. I think it can be counterproductive to keep vendors at arm’s length from the people who will really use the system. It is understandable that procurement departments have important roles to play in large companies. However, in some cases the procurement folks keep such a tight grip on the process in the name of objectivity that they place overly severe restrictions on the access vendors have to real users, and vice-versa.

A digital asset management system is a complex beast, and the success of a DAM rollout can be compromised if the real users don’t have an opportunity to, say, visit the vendor’s offices to get a feel for the company and, to some degree, get to know the vendor’s representatives.