How to write your RFP
All Digital Asset Management and Web-to-Publish vendors will tell you that their system is the best, and in some cases the process of selling a DAM and Web-to-Publish system to a new client is very quick and easy. Everything seems like a Win-Win.
The imaginary sales story could go a little bit like this:
Vendor: Yes of course, we will come out and show you a demo of our system, lets meet up on Tuesday.
Vendor: Yes, we have received your 150-row spreadsheet with all of your team’s functional requirements. We will get cracking on that straight away. By the way, we have already had a first pass at it and the good news is that we can cover around 90% of your requirements.
Vendor internally: Sweet, they have invited us for a 2nd demo with the whole team, they didn’t push back on our pricing, and we have clients in their sector, I think it’s in the bag!
Vendor: Excellent news Ms New Client, your business is very much appreciated. I will get the client success team to organise a date for the kick-off.
Then three to six months later…
Client: Is that tech support? Yes hello, our agency has uploaded lots of large CMYK Photoshop PSD files with layers and transparency. But the previews are all wrong and the low-res downloads aren’t usable as the colours are off and the transparency is missing. We really need that fixed now as otherwise our creatives will get fed up with the system.
Client: Hi again tech support, it’s me. We would like to change the names of the top navigation entries because many of our business users don’t understand where to find stuff, can we do that? No, why not? Surely that’s an easy thing to do, we can do that on our WordPress site in 5 minutes.
Client: Hi tech support, yes I know, I know… it’s me again. We are in the process of creating a new Web-to-Print template but for this one we need the T&Cs at the bottom to change automatically depending on what country they are in, and we only want them to replace the main image with images from a certain section in the DAM. How do I do that? Oh, you can’t do that? What a shame – I guess we will have to send out the InDesign files to the dealers.
Client: Yes it’s me again. We have just launched our new Product X and all of our 500 sales partners worldwide need to download all of the new product images and videos today. However, my users are complaining that the system is running slow so now we have to put it on WeTransfer just to get it to them in time.
Maybe we will just abandon this whole thing and go back to our bad old ways.
Oh god, my boss is going to be seriously annoyed…
Damn! Now I’ve missed the appointment with my work-life balance coach – again.
So what went wrong?
Did the imaginary vendor lie when they filled in the RFP spreadsheet?
No, highly likely not because those particular features might have been asked for in a “tick box” fashion like this:
|Functionality item||Must/Should/Would/Could||Vendor response|
|Support for a wide variety of file format including PSD, Illustrator, InDesign, MS Office, etc||Must||Yes|
|Intuitive, modern user interface||Must||Yes|
|Web-to-Publish feature with ability to support a wide range of artworks||Must||Yes|
|Scale to 5000 registered users globally||Must||Yes|
|Ability to support the upload and tagging workflow as outlined below|
(step X, step Y, step Z)
This series of unfortunate events with a failing system as the outcome should hopefully illustrate that it’s not whether the DAM/web-to-print vendor supports something, it’s HOW they support it that really matters.
For example, if a vendor’s sweet spot was enabling organisations to maintain a strong, consistent brand and consistent marketing communications and they were to get an RFP for a DAM from a museum looking for an archive facility, they could probably think of ways to answer yes to most of the requirements in a “tick box RFP”. But would they do these really well? No.
So here is what we think should be included in a great RFP:
1. Describe your most important scenarios – aka user stories – including real-people personas
These will vary from company to company. Some will be end-user focused and others will be super-user/admin focused. The main aim here is to describe WHAT are you trying to accomplish on an overall level, WHY is this important to your business, WHO is involved and HOW each person would ideally like to complete their task within the process.
Here is a good example of a DAM user story: Technology Selection Quick Tip: An Example Narrative Scenario
This should probably be limited to 3-5 core stories, perhaps with some additional, much shorter, secondary stories.
2. Functionality check-list (as per above example)
By any means create one of those, including MoSCoW priorities (aka Must/Should/Could/Would), but remember that you are much more likely to succeed with a system which does your 5 core processes super-well, instead of a system which does 100 things through workarounds.
3. Supply vendors with representative examples of your actual files (images, videos, documents)
As per the Photoshop PSD example above, you can’t be sure if a vendor’s support of a particular filetype does what you need it to do until you try it with your files. Just within the PSD format there are lots of things that might get ignored by some DAMs which will render it useless for your particular usage.
The same goes for Video. Most DAM vendors will support transcoding of Quicktime files, but Quicktime is a “wrapper” format, and you can have any amount of compression codecs, screen ratios, multiple audio tracks, and so on within a .mov file which may get ignored by the DAM, or make it choke. So send YOUR files for upload to a trial system as part of the RFP process. You can then check if it does what you need.
4. Supply vendors with your worst-case examples of your artwork for converting into working Web-to-Publish templates.
In a similar vein, until the potential vendor has converted a couple of your actual artworks (typically InDesign or Illustrator) to a working template you won’t know what the real-life experience will be for your end-users. The vendor may give you access to some demo templates, but of course they will demo very well as this is what they are optimised for. You should – within reason – select a couple of your “worst case” artworks where you know or suspect that there will be complexities for the vendor to create a successful template, and also to make it intuitive for end-users to use.
In the imaginary story above there was a requirement for the system to cope with 5000 users, yet it couldn’t cope with just 500 users – that’s because the question was about registered users, not simultaneous.
Vendors may have clients with 40,000+ registered users, but if they all logged in at once without pre-warning from the client, their servers would probably melt.. If at all possible, describe how you have scalability needs.
Different companies have different scalability challenges, the most common ones are:
- High number of simultaneous users of the DAM or a particular W2P template (such as for global product launches).
- HD or 4K video files that need to be reliably uploaded and transcoded within an agreed timeframe.
- Large files that need to be transferred quickly over long geographical distances.
- Very large multi-gigabyte graphics files, e.g. PSD or PSB files, which can be problematic to create previews from.
- Very complex workflows which may tax the workflow engine.
- Custom integrations that will hammer the API.
- Large upload batches such as uploading thousands of assets within one upload session.
- Significant numbers of end-users in countries that have poor internet connectivity to the vendor’s hosting infrastructure.
On that subject, a CDN doesn’t necessarily mean that everything will work globally. A CDN may speed up downloads for end users, but it will not speed up uploads.
Therefore, get a couple of your actual end-users out in those countries to try out a demo system for real with your real files and web-to-print templates.
If you have any traffic stats or reporting from an existing DAM or Web-to-Print system which you are looking to replace, give those to your potential vendors as well.
6. Future proofing through configurability
As the saying goes, these days the only thing which is certain is uncertainty.
The same goes for DAM and Web-to-Print systems. Down the line you may have new departments or brands coming on to the system, perhaps you’ll have a re-brand, need additional UI languages and other changes. Consider which parts of the system you are most likely to need to amend in the future and then get the vendor to demonstrate their flexibility on these fronts. This goes both for admin-type functionality and end-user journeys.
Typical areas where you may need flexibility in the future are:
- Branding of the system itself in the case of a rebrand
- Additional brands/sub-brands coming on to the system which need to be partitioned off both in terms of permissions and on-brand look-and-feel.
- Permissions for new countries, departments, brands or
- Multi-step workflows for briefing, tagging and approvals and other activities.
- New classes of artwork for W2P templates such as banner ads, emailable case studies, event artwork, leaflets, POS, and so on.
And check if the vendor needs to implement this at a cost or whether it is something which the system allows you to do yourself.
7. Integrations needed
These days there is rarely an RFP which doesn’t mention that integrations with the client’s other existing systems such as a CMS, CRM or PIM, amongst others.
Once again, it’s the HOW that matters most here.
Consider this common request in an RFP:
“Integration with SalesForce required, ideally in the form of an out-of-the-box connector”.
Salesforce has as of now completed no less than 51 acquisitions, so not only is their core/original CRM a vast, sprawling platform, they also have dozens of other systems under their name that are in various states of being separate to or integrated with their main platform.
If the intention with such an integration is to do a cross-match of metadata assigned to a Salesforce Opportunity with your DAM, then you may be in luck. However, if you are actually after an integration with some other part of the system or an acquired app (like MuleSoft, ExactTarget, Pardot or others) you might not find anybody with a connector or perhaps not even the API calls needed to do the type of integration you are after.
So as always, outline the real-life user stories of how you would like the integrations to work.
8. Asset migration needs
Even if you don’t have a legacy system which you are migrating from you will have lots of images, videos, documents, etc dotted around which you need to import into a new system. This doesn’t necessarily have to be part of the RFP but certainly when you get to quoting stage, if you want to get any kind of realistic advice on time-scales, pitfalls and costs for this, you need to give the vendor a good overview of the state of affairs.
9. SaaS vendor Security checklist from your IT department.
It is of course vital for your IT department to ensure that any chosen vendor has an adequate level of security in place, as you will be entrusting the safekeeping of thousands of valuable files to your chosen vendor.
10. Don’t keep vendors too much at arm’s length from the real users of the system
We understand that in large companies the Procurement Department has an important role to play. However, in some cases the procurement department keeps such a tight grip on the process, severely limiting the vendor’s access to the actual users of a new system, that in my mind it becomes counter-productive. A DAM/W2P system is such a complex beast that unless the vendor to some degree gets under the skin of the real users (and vice versa) this in itself can add risk to achieving a successful outcome of the project.
11. Your exact budget and a list of the other vendors on the shortlist
Well, it was worth a try ; )