考慮數字標牌 RFP？不要這樣做！

已發表: 2022-06-01

老實說：RFP 對所有相關人員來說都有些糟糕。

長期以來，徵求建議書一直是各種規模的組織尋找和選擇技術提供商的首選流程。但它們非常耗時、過於官僚，而且在發現最合適的解決方案和供應商方面往往效果不佳。

雖然 RFP 可以強制執行結構和紀律，但由於評估和評分提交的方式，它可能會導致選擇錯誤的供應商。 RFP 甚至可以阻止最合適的供應商追逐業務，因為響應可能會或可能不會成功的機會需要所有時間。或者甚至是真實的。

如果您是最終用戶，第一次採購數字標牌技術，或者要替換或更新您已有的技術，請仔細考慮一下 RFP 是否是獲得解決方案的最佳方式。查找所需內容的勞動密集型方法要少得多，而且它們可能會更有效地幫助您確定正確的選項。

如果您在一家大公司或政府實體工作，採購流程嚴格，需要 RFP，那麼……Godspeed。你在做。

但如果沒有，讓我們看看一些更簡單的路徑。

首先，這裡有一些關於 RFP 的硬道理：

收件人往往不信任他們。他們擔心，無論是對還是錯，RFP 都偏向於已經首選的供應商，或者甚至 RFP 問題是由已經與最終用戶緊密聯繫的供應商精心設計的；
收件人還擔心 RFP 及其過程只是光學練習，並且已經做出決定（但“規則”說機會必須擺在多個供應商面前）；
收件人會查看機會的大小，並將其與做出回應所需的時間進行權衡。在很多情況下，銷售總監會選擇讓他們的員工專注於追逐他們知道真正有機會發生的機會；
RFP 文檔的大小與獲得響應的可能性直接相關。換句話說，如果 RFP 是一個 100 多頁的文檔，充滿了無窮無盡的問題，許多供應商將通過。如果 RFP 問題列表很短，而且提出的問題切中要害，就會有更多的供應商做出回應；
如果 RFP 在數十家潛在供應商之間撒下大網，供應商會認為這只是一次釣魚之旅，而發布 RFP 的人將在凌晨 3 點閱讀回复，試圖從一堆郵件中脫穎而出。沒有人贏。

就技術方面的需求及其在組織內的運作方式製定非常清晰、清晰的敘述。您想了解您需要技術做什麼，但更重要的是，您應該完全定義如何管理它。

例如，公司是否要購買軟件並將其託管在自己的服務器上，在自己的防火牆後面。或者它是否想有效地“租用”技術，使用軟件即服務 (SaaS) 來查看由服務提供商處理的雲託管基礎設施和中央操作。

誰將“擁有”組織內的屏幕網絡？誰來計劃、運行和觀察事物？那是一個人嗎？內部團隊？新員工？還是會將大部分或全部工作外包給服務提供商？

您的組織需要服務提供商具備哪些特徵？您想要一家製造和支持出色軟件但又不妨礙的公司嗎？或者，您是否想要一家可以從一開始就提供幫助的公司——在構思階段——成為貫穿規劃、推出和持續運營的合作夥伴。

在每一種情況下，以及更多情況下，這些公司都可能是非常不同的類型。問題是 RFP 並不是梳理這些信息的好方法。

只做一個迷你 RFP。製作一份只有少數關鍵問題的文件，重點放在真正重要的問題上：

還有一些其他好的問題和陳述可以插入其中，所以不要被上面列出的限制。只是不要繼續下去。您不應該浪費您自己或供應商的時間，喋喋不休地回答有關支持動畫 gif 或社交媒體提要等問題。許多 RFP 都充滿了關於供應商是否支持或做幾乎每個供應商都支持和做的事情的問題。

差異不在於技術，而在於工作方式、技術方法和垂直市場適應性。例如，有些軟件平台完全是關於廣告的，它們也可能在學校、工作場所或醫療保健中發揮作用，但也有一些平台專門針對這些垂直市場和用例進行了優化。

例如，Spectrio 有一個完全針對汽車經銷商環境的解決方案——根據其需求、動態和業務系統進行調整。

很有可能，特別是如果您已經部署了數字標牌網絡，您對自己想要什麼以及適合與誰合作有一些想法。將 RFP 發送給其中一些看起來合適的人選。他們沒有理由不回應。

如果您不了解技術或公司，請聘請數字標牌行業顧問。有些人可能想要一個固定人員和數週的工作。你可能不需要那個。其他顧問將有希望與您一起花幾個小時來幫助確定您的需求，然後推荐一份合適的服務提供商的簡短列表。

如果你能找到那個候選名單，發送那個迷你 RFP，篩選響應，然後可能有三個公司參加會議——最好是親自參加。不要讓它成為一個小時。讓它成為一個早晨。或者一天。您聊天的時間越多，您就越有可能超越功能和規格討論，進入有關想法和工作方式的高質量對話。

如果數字標牌技術對您來說是全新的，也許可以讓顧問旁聽演示以指導對話並過濾響應。擅長響應 RFP 和銷售演示的供應商不一定也擅長提供他們的服務。

這些會議會消耗一些時間，但考慮為這個過程分配兩到三天，而完成完整的 RFP 可能需要數周和數月。這要短得多，也容易得多，而且結果也很有可能會更好。