RFP 響應要求

您最近看到了很多關於網站設計的要求、合同和建議的帖子。 背後的原因是什麼？

這是因為如果你想啟動一個成功的網站設計，你需要的不僅僅是圖像、文本和軟件代碼。 以下是每個徵求建議書 (RFP) 響應必須包含的首要網頁設計要求。

網站設計的成功是可靠文檔和結構化流程的直接結果

執行有效的網頁設計項目以可靠的文檔開始和結束。 這種可靠的文檔可以是工作說明書、合同或建議書的形式。 本文件的名稱不如文件中包含的信息重要。

無論您是大型企業還是小型企業，都需要可靠的文檔來執行任何按預算、按任務和按時完成的 Web 項目。

您在銷售過程中對文檔的關注越多，整個過程就越順利，越容易對所有相關人員進行。 在本文中，我們闡明了評估和審查徵求建議書 (RFP) 響應的方法。 看一看！

評估 RFP 響應

審查和評估 RFP 響應聽起來很容易？ 但實際上，聽起來比實際練習時要容易。

如果處理項目的團隊向不同的設計機構索取報價，評估網頁設計提案的任務可能會讓他們感到不知所措。 好吧，他們不只是感覺到它——但實際上它可能是壓倒性的。

RFP 傷害的數量越多，這些提案中的變化和響應池就越大。 希望最終入圍時，在發送 RFP 之前製作了一個簡短的 Web 開發人員名單，這將保持這個數量有限，並使整個審查過程更容易一些。

一旦你得到一個網站建議，最好問你一些關鍵問題，讓你自己開始。 這些問題通常包括

• 是否可以在項目給出的時間表內提供提案？
• 該提案是否在項目的預算限制範圍內？
• 您收到的 RFP 響應是否滿足網站設計的所有要求？
• RFP 響應是否寫得好且易於理解？
• 您收到的 RFP 響應是否以專業的方式呈現？
• 是否在給定的時間範圍內提供了響應？

上面給出的問題無疑是高級問題，但它有助於消除任何明顯奇怪的網頁設計公司。 一個不完整、遲到或不專業的 RFP 響應應該被視為潛在網站開發的危險信號。 還涉及報價兩倍或三倍預算的 RFP 響應。

既然您已經收到了所有的回复，並且您已經向顯然不合適的公司發出了警告，現在是時候徹底審查每個 RFP 回复，以便您輕鬆比較 RFP 回复一個更蘋果對蘋果的方式。

必須在每個 RFP 響應中查看的網頁設計要求

有不同長度的 RFP 響應。 因此，最好不要關注頁數或文本量。 最重要的是響應中呈現的解決方案和內容。

在審查 RFP 響應時，請始終牢記每個響應都涵蓋了任何 Web 項目的一些重要元素。 確保這些網頁設計要求包括但不限於下面給出的詳細信息。

項目計劃：

這必須包括一個高級別的項目任務列表。 雖然這只是一個初步計劃，所以它不會像最終計劃本身那樣詳細，但應該包含足夠的細節，以便您可以輕鬆了解構建、開發、設計和發現的流程。

項目管理工具：

必須有一個適當的設計機構項目管理工具列表。 每家公司都有不同的項目管理工具集，因為在公司內部有很多很好的選擇。 最關鍵的是確保項目管理流程有適當的結構，並且以易於理解的方式記錄給定的任務、日期和所有者。

團隊成員：

不同的設計機構為其團隊提供不同的結構。 網頁設計機構越大，他們的項目團隊就越大。 作為買家，您必須知道誰將在您的團隊中與您合作，以及他們將提供什麼樣的工作能力。 沒有必要擁有每個團隊成員的完整簡歷，但至少你有一份未來幾個月與你一起工作的人員名單。

基線技術和內容管理系統：

如果您網站的 RFP 未指定所需的 CMS 解決方案，因為這將是提案的基本要素。 確保 RFP 響應列出了完整的 CMS 選擇以及部署和編碼新網站所需的任何其他技術。 特別注意任何專有的東西。 立即給專有的 CMS 軟件包一個危險信號，因為它在網站的生命週期內將您鎖定在該 Web 開發人員中。

可交付成果：

這是另一個最重要的列表，因為它告訴您在上線時將交付給您的內容。 這可能包括使用的插件、內容遷移量、設計模板以及與項目相關的更多內容。

功能清單：

如果您要設計的網站不僅僅是一個簡單的宣傳冊網站，這是另一個最重要的列表。 您的網站越複雜，功能列表應該越詳細。

內容遷移：

如果網站項目將包括內容遷移，請記住列出將遷移到新網站的內容量。 這可能包括附件、用戶、事件、產品、帖子、頁面等等。 如果未定義內容的數量和性質，則會給您和設計機構帶來額外的成本和範圍蔓延。

搜索引擎優化：

永遠不要忘記搜索引擎優化！ 這可能包括 301 重定向、元定義、頁面優化、頁面映射和關鍵字研究所需的關鍵字。 如果您依賴自然搜索引擎優化，請在重新設計期間保護此流量來源。 最好和最容易做到這一點的是確保在項目提案和範圍界定過程中這個主題是居中的。

圖片使用：

必須仔細了解設計師在網頁設計項目中使用的圖像的分配和所有權。 向網頁設計機構詢問負責放置、編輯、購買和選擇圖像的人員。 這將因項目而異，因此可以更好地在早期階段明確定義。

排除：

雖然沒有必要在您提出的每個提案中都包含排除項，但是當您和客戶討論任何不屬於網站項目的項目時，請不要忘記列出它。 這有助於買方在以後的流程中進行保護，同時也可以為客戶闡明您的可交付成果。

移動響應：

今天，沒有移動響應能力的網站是不完整的。 它應該是任何現代網站的主要部分。 但根據網站的大小而有所不同。 有許多大公司擁有單獨的移動應用程序或網站。 沒關係，如果您沒有單獨的移動網站，請確保您設計的提案必須包含可以輕鬆管理適用於平板電腦和手機的顯示的語言。

API 或/和第三方集成：

企業和中型市場公司通常在其組織內擁有大量軟件和系統包。 這些系統用於通過同步、推送和拉取數據輕鬆地與新網站進行通信。 如果有時需要使用 API 或集成，請確保提案定義了第三方系統、數據傳輸、數據點和責任方。

日程：

每個 Web 提案響應必須包含與項目里程碑相對應的列表。 這將告訴買方完成每個里程碑需要多少時間，以及項目是否符合您給定的時間表。

里程碑：

如果有設定的里程碑，團隊將更有效地工作以在網站設計過程的每個階段實現目標，然後再進入下一階段。 典型的里程碑通常包括 beta 測試或/和發布、內容遷移、主題編碼、圖形設計、信息架構、發現和上線。

延誤：

項目延誤通常是由於開發商和客戶雙方的原因。 了解如何成功處理這些延遲以及它將如何改變整個網頁設計項目的時間表和預算至關重要。

付款條件：

如果有一個較小的網站項目，買方必須在項目開始時支付 50% 的付款，而在完成後支付 50%。 另一方面，如果有較大的網站項目，則付款是基於設定的時間或里程碑。 確保您的提案中明確定義了付款條款。

花費：

費用通常包括庫存圖片、插件許可、託管費用、域名費用和/或差旅費。 確保提案中的每一項費用都必須有適當的詳細信息，並且買方負責付款。

用戶培訓：

如果用戶是 CMS 的新手，該提案可能包含一些編寫培訓文檔、交互式培訓課程或/和在線培訓工具的指南。 請記住，培訓方法必須與您的用戶群相匹配。

保修期：

保修期通常涵蓋網站內任何軟件錯誤的更正。 保修期，通常設置為特定天數，並且必須在合同或提案中說明。 此保修將涵蓋網站開發人員的編碼，但不包括第三方擴展或插件。

持續維護：

永遠不要將維護與保修期混為一談； 它們與保修期有很大不同。 維護協議必須按年或按月支付，它用於隨著時間的推移向 Web 開發人員提供系統和軟件的更新。 對於 WordPress 網站，持續維護將包括更新整個 WordPress 核心軟件和網站上安裝的任何插件。 持續維護還包括需要時的一對一協助、報告、備份、監控和安全。

需要時的後期支持：

沒有必要每個公司都需要或想要一份維護協議。 代替維護協議，一些公司將要求按需提供後期支持。 這通常按小時計費，並通過支持系統或票證進行管理。

網站 RFP 流程中涉及的後續步驟：

在您完成了整個 RFP 響應並縮小了所選供應商的範圍後，現在是時候關注下一步，即協商最終細節和合同了。

雖然互聯網上充斥著關於合同談判的建議，但不要在流程細節上停滯不前。 重要的是要記住，這一步是與選定的 Web 開發人員建立長期合作夥伴關係之前的最後一步。

該談判的重點是解決任何未解決的問題或疑問，這反過來將為您開始設計和實施過程提供堅實的基礎。 進行合同談判，注意解決任何未解決的問題並澄清任何混淆點。

如果選定的項目團隊在項目範圍界定方面做得很好，並且他們選擇了合適的開發商，那麼談判必須只是一個簽名。 如果團隊選擇了錯誤的網頁設計機構，該項目可能足以迫使團隊考慮排名第二的公司。