معظم طلبات العروض لموقع تصل كعدد صفحات وتنتهي كعروض غير قابلة للمقارنة. هذا النموذج من اثني عشر قسماً يجعل العروض قابلة للمقارنة بنداً ببند.
ترسل طلباً واحداً لموقع إلى ثلاث شركات فتصلك ثلاثة عروض لا يمكن مقارنتها. أحدهم يسعّر بالصفحة، والثاني بالساعة، والثالث يعطي رقماً واحداً بلا تفصيل. لا تعرف أولوية أيها، لأن كل عرض يجيب عن سؤال مختلف عن سؤالك.
المشكلة ليست في الشركات. هي في وثيقة الطلب. إذا لم تحدد المشكلة والجمهور والتحويل والنطاق وقواعد القبول، فكل عرض سيخمّن. هذا النموذج من اثني عشر قسماً يملأ الفراغات قبل أن يبدأ المورّدون، فترد العروض على البنود نفسها.
لماذا تنتج معظم طلبات العروض عروضاً لا تُقارَن؟
أول سبب هو وحدة القياس. «عشر صفحات» وصف يجمع صفحة تعريف بصفحة خدمة تحتاج نموذجاً وجدول أسعار وأسئلة شائعة. بسعر بالصفحة، يدفع البعض أكثر للبسيط ويحصلون على أقل للمعقّد. القالب الوظيفي وحدة أدق: قالب خدمة، قالب مقال، قالب حالة عمل، قالب تواصل. لكل قالب حالات وحقول وقواعد، وعدد القوالب يحدّد التصميم والبناء بينما يحدّد عدد الصفحات المحتوى فقط.
السبب الثاني هو غياب معايير القبول. إذا لم تقل كيف تعرف أن الموقع جاهز، فكل عرض سيعرّف «جاهز» بطريقته. البعض يسلّم تصاميم، والآخر يسلّم موقعاً بلا تحليلات، والثالث يسلّم موقعاً يعمل بالعربية اتجاهاً لكنه لم يُختبر فيها. اكتب الرقم الذي تريد: سرعة، وإمكانية وصول، ولغتين، وأمان. فعندها يصبح العرض قابلاً للقياس.
السبب الثالث هو غياب مالك القرار وملكية التسليم. إذا لم تسمّ من يقرر، ومن يملك المحتوى والكود والنطاق بعد الإطلاق، ومن يجيب في أول تسعين يوماً، فالفرق السعري في العرض سيظهر بعد سنة كتكلفة تشغيل. للمقارنة بين الأنواع، اقرأ دليلنا حول تكلفة الموقع المؤسسي في السعودية قبل أن تطلب عرضاً، فهو يشرح ما يدخل في النطاق وما يخرج عنه.
هيكل الطلب من اثني عشر قسماً
هذا هو الهيكل الذي نطلبه من عملائنا قبل أي عرض، لأنه يجعل المقارنة آلية. انسخه بالترتيب، واكتب سطراً أو سطرين في كل قسم. إذا تعذّر عليك ملء قسم، فهذا هو القسم الذي كان سيكلّفك بعد الإطلاق.
1. المشكلة. سطر واحد: ماذا لا تستطيع أن تفعل اليوم؟ مثال: «لا نستطيع إقناع المشتري الحكومي». بلا مشكلة، لا يوجد معايير.
2. الجمهور. من المستخدم، وما أجهزته، وما لغته؟ مستخدم حكومي على جوال بالعربية يختلف عن شريك مؤسسي على مكتب بالإنجليزية. كلا الجمهورين في قسم واحد يتطلب تصميماً للاثنين.
3. التحويل. ما الفعل الواحد الذي يجب أن ينتهي إليه المسار؟ نموذج تواصل، أو طلب عرض، أو حجز مكالمة. موقع بلا تحويل شرع هو كتيّب.
4. النطاق بالقوالب. اذكر القوالب الوظيفية وعددها، وما سيبنى وما لن يبنى. «ثلاثة قوالب خدمة وثلاثة قوالب محتوى» قابل للمقارنة. «عشر صفحات» ليس كذلك.
5. ملكية المحتوى. من يكتب النص العربي والإنجليزي، ومن يراجعه، ومن يملكه بعد التسليم؟ إذا كان المحتوى ملك الشركة، فكل تغيير لاحق سيمر بها.
6. اللغات والاتجاه. هل التسليم ثنائي اللغة بالكامل؟ اذكر الخط، واتجاه RTL، وترتيب الحقول، واختبار لا عكس آلي بعد البناء. تكتب «العربية لغة أساسية لا ترجمة لاحقة».
7. التكاملات. سمّ كل تكامل بالاسم: نموذج CRM، وبوابة دفع، وإشعارات، ونظام تذاكر. لكل تكامل اذكر ما يحدث عند فشل الاتصال: إعادة محاولة وتنبيه وسجل. الاتصال وحده لا يكفي.
8. الأمن والامتثال. أين تُخزَّن البيانات الشخصية، ومن يصل إليها، وكم تبقى؟ هذه الأسئلة تنظيمية في السعودية مع PDPL الواجبة التطبيق منذ سبتمبر 2024. اكتب الجواب في الطلب، لا في العرض.
9. الجدول. حدّد أسبوع الإطلاق المستهدف، ومواعيد المراجعة، ومواعيد تسليم المحتوى من جهتك. إذا كان التسليم 8 إلى 14 أسبوعاً كما في نطاقنا المنشور للويب، فاكتب ما الذي يتحرك إذا تأخّر المحتوى أسبوعاً.
10. معايير القبول. أرقام تُقاس عند التسليم: LCP وINP وCLS ضمن حدود Web Vitals، وإمكانية الوصول وفق WCAG 2.2، وعمل النموذجين بالعربية والإنجليزية، واختبارات أمان. بلا أرقام، لا يوجد قبول.
11. مراحل الدفع. اربط كل دفعة بناتج قابل للفحص: اكتشاف، وتصميم، وبناء، واختبار، وإطلاق. «40% عند التوقيع» بلا ناتج يمول التأخير، لا العمل.
12. التسليم والملكية. اذكر ما تستلمه في يوم التسليم: المستودع، وقاعدة البيانات، وإعدادات النشر، والتوثيق، ووصول النطاق والاستضافة. إذا بقي أي بند ملك الشركة، فأنت تستأجر.
انسخ هذا الهيكل كما هو. إذا أردت مساعدة في ملئه، فابدأ من الاستشارة التقنية، لأن نطاقها المنشور 20,000 إلى 30,000 ريال خلال 6 إلى 10 أسابيع، وهي المرحلة التي تسبق أي طلب عرض جدي. بقية هذا المقال يشرح كيف تسجّل العروض بعد أن ترسل الهيكل.
كيف تسجّل العروض على خمسة بنود متطابقة؟
عند وصول العروض، لا تقارن الرقم الأخير. قارنها على خمسة بنود متطابقة، واطلب أن يرد كل مورّد على كل بند بنفس الصيغة. العرض الذي يرفض صيغة بند يخبرك شيئاً عن عمله. الجدول التالي هو ورقة التسجيل.
| البند | ما تطلبه | كيف تقارن |
|---|---|---|
| النطاق بالقوالب | قائمة القوالب الفريدة وما لن يُبنى | عدد القوالب المتطابقة، لا عدد الصفحات |
| اللغتان والمحتوى | تأكيد التسليم بالعربية والإنجليزية واتجاه RTL وملكية المحتوى | مَن يكتب ويراجع ويملك، ومتى تتوفر النسختان |
| التكاملات والأمن | اسم كل تكامل وسلوك الفشل ومكان التخزين ومسار الاطلاع | مخطط بيانات وصلاحيات، لا وعد بالسرية |
| القبول والجدول | أرقام القبول ومواعيد المراجعة وأسبوع الإطلاق | نفس الأرقام لكل العروض، ووسم ما لم يُذكر |
| السعر والتسليم والدعم | تفصيل السعر والدفعات وما تستلمه ودعم التسعين يوماً | سطر السعر جنب سطر التسليم، لا رقماً منفصلاً |
استخدم نطاقاتنا المنشورة للتحقق من الشكل قبل التفاوض: الويب من 10,000 إلى 25,000 ريال خلال 8 إلى 14 أسبوعاً، والاستشارة من 20,000 إلى 30,000 ريال خلال 6 إلى 10 أسابيع. هذه أرقامنا، لا نطاق السوق. العرض الذي يخرج عنها يجب أن يشرح في أي بند خرج ولماذا.
من القراءة إلى التنفيذ
تريد بناء هذا، لا قراءته فقط؟
أرسل لنا المشكلة التي تقف خلف المقال. سنخبرك بما يتطلبه الحل وتكلفته وما إذا كنا الفريق المناسب.
الفخاخ الشائعة التي تكسر المقارنة
أول فخ هو السعر بالصفحة. يعطي سعراً ثابتاً لكل صفحة إضافية بينما صفحة «من نحن» تحتاج صورة ونصاً، وصفحة الخدمة تحتاج نموذجاً وجدولاً واختباراً. اسأل عن سعر القالب الوظيفي وعن حالاته، واجعل المادة الإضافية تُسعَّر بالقالب لا بالصفحة.
الفخ الثاني هو المقارنة بين سعر ثابت وسعر بالساعة. السعر الثابت قبل الاكتشاف يبدو آمناً ويخفي التغييرات في بنود «إضافية». والسعر بالساعة بلا سقف يبدو مرناً ويخفي مسؤولية التقدير. الحل واحد: اكتشاف مدفوع قصير ينتهي بثمن ثابت أو بمراجعة اكتشاف فاشل. إذا كان الاكتشاف 20,000 إلى 30,000 ريال خلال 6 إلى 10 أسابيع كما في نطاق الاستشارة المنشور، فيجب أن يقول ما يحتويه، لا أن يعده وعداً.
الفخ الثالث هو غياب بنود الدعم بعد الإطلاق. كثير من العروض تنتهي عند الإطلاق، وبعدها تدفع عن كل إصلاح بأسعار لا تعرفها. اكتب في الطلب: مدة الدعم المشمولة، وكيف يُسعَّر التغيير الصغير، ومن يحدّث النظام. عرض بلا هذه الأسطر هو مشروع بلا صيانة.
مثال عملي صغير يمكنك نسخه
فيما يلي مثال جاهز لموقع مؤسسي ثنائي اللغة. عدّل الأقواس واترك البنية. النص العربي والإنجليزي من الأسفل مترجمان حرفياً، فيصلح أحدهما لأي لغة يقرر فيها المشتري.
- المشكلة: المشتري الحكومي لا يجد أدلة على سابقة الأعمال أو الترخيص، فتضيع الصفقات قبل الاجتماع.
- الجمهور: مسؤول مشتريات حكومي على الجوال بالعربية، ومقاول أو شريك مؤسسي على المكتب بالإنجليزية.
- التحويل: إرسال طلب عرض نموذج واحد خلال دقيقة، مع إشعار تأكيد بالبريد.
- النطاق: ستة قوالب: رئيسية، وخدمة، وحالة عمل، ومقال، وتواصل، وطلب عرض. لن نبني متجراً ولا بوابة عملاء ولا جوالاً في هذا الإصدار.
- المحتوى: المشتري يزوّد النصوص العربية، ويكتب المورّد الإنجليزية أو يترجمها، والمشتري يملك النسختين.
- اللغات: عربي أساسي ثم إنجليزي، وخط عربي مفتوح الرخصة، واختبار RTL على كل قالب قبل التسليم.
- التكاملات: نموذج CRM وإشعارات بريدية. عند فشل الإشعار، إعادة محاولة ثلاث مرات ثم تنبيه للمشترك.
- القبول: سرعة ضمن Web Vitals، وإمكانية وصول بدرجة AA في WCAG 2.2، وعمل النموذج باللغتين واختبار فقدان البيانات.
- الدفع: 25% عند اعتماد التصميم، و40% عند انتهاء البناء، و35% بعد اجتياز القبول. الدفعة لا تُستحق بلا ناتج لاحق.
- التسليم: مستودع كامل، وقاعدة بيانات، وإعدادات نشر، وتوثيق، ودعم 30 يوماً. النطاق والاستضافة باسم المشتري.
هذا المثال لا يصف سوقاً. يصف عقداً. إذا وردت العروض على هذه البنية، ستعرف في دقائق من يقصد القبول ومن يبيعه. لهذا يهم الاستثمار في هذا القسم قبل إرسال أي سطر.
قائمة التحقق قبل الإرسال
مر بثمانية بنود قبل أن ترسل الوثيقة. كل بند نعم أو لا، بلا «ربما». أي لا يعني أن العرض سيخرج ناقصاً في ذلك البند تحديداً.
المشكلة بسطر واحد. هل يستطيع من لم يعرف مشروعك أن يشرح سطراً أضفته؟
التحويل مسمّى. هل هناك إجراء وحيد مكتوب، ونموذج مذكور، وزمن متوقع له؟
النطاق مكتوب بالقوالب. هل كل قالب له عدد وغرض، وما لن يبنى مذكور صراحة؟
المحتوى والملكية محددان. من يكتب ويراجع ويملك، ومن يزوّد النص في أي تاريخ؟
اللغتان وRTL في القبول. هل ذكرت الخط والاتجاه والاختبار بكلمات لا تترك التأويل؟
التكاملات والأمن مكتوبان. هل كل تكامل له سلوك فشل وكل بيانات لها مكان تخزين؟
الدفع مرتبط بنواتج. هل كل دفعة لها ناتج فحص، وهل القبول أرقام لا انطباعات؟
التسليم والدعم مكتوبان. هل ذكرت ما تستلمه يوم التسليم ومدة الدعم وكيف تسعَّر التغييرات؟
الأسئلة الشائعة
ما الفرق بين طلب العرض ووثيقة النطاق؟ طلب العرض أسئلة للمورّدين. وثيقة النطاق إجاباتك عن مشروعك. أرسل الوثيقة أولاً، والطلب ليس إلا شكل العرض.
هل تكفي الصفحات الخمس عشرة؟ لا. عدد الصفحات لا يحدّد التكلفة. حدّد عدد القوالب وعدد الصفحات على كل قالب، فهذا هو الذي يُقارَن.
هل نحتاج اكتشافاً مدفوعاً قبل الطلب؟ إن كان مشروعك أول مرة، نعم. الاكتشاف ينتهي بثمن ثابت أو بمراجعة فاشل، ويوفّر عليك نقل الفرضيات إلى العروض.
كيف نقارن سعراً ثابتاً بآخر بالساعة؟ لا نقارنهما على الرقم. نطلب من صاحب الساعة سقفاً وتقديراً لكل قالب، ومن صاحب الثابت بنود «إضافية» كاملة.
ماذا بعد وصول العروض؟ سجّلها على البنود الخمسة المتطابقة، ثم تحدّث مع الأعلى درجة عشر دقائق حول التسليم والدعم، لا حول الصور.
المصادر
- McKinsey: The Business Value of Design — دراسة على 300 شركة مدرجة، ورصدت أن شركات الأداء الأعلى في مؤشر التصميم نمت أسرع بمقدار 32 نقطة مئوية خلال خمس سنوات.
- web.dev: Web Vitals — حدود LCP وINP وCLS التي نستخدمها كمعايير قبول.
- WCAG 2.2 — صدرت كتوصية W3C في 5 أكتوبر 2023، وأضافت تسعة معايير نجاح.
- اللائحة التنفيذية لنظام حماية البيانات الشخصية — مرجع الالتزامات في المعالجة والإبلاغ عن الحوادث.
