حين تبيع شركة تسويق موقعًا إلكترونيًا تحت اسمها، لا يكفي أن تجد جهة تنفذ التصميم والبرمجة. القرار الأصعب هو تحديد ما الذي ستستلمه، ومن يملك كل أصل وحساب، وكيف تنتقل المسؤولية من البريف إلى الموقع الحي ثم إلى الدعم. يقدم هذا الدليل طريقة عملية لصياغة نطاق تصميم مواقع وايت ليبل لشركات التسويق السعودية والخليجية: صفحات ووظائف ومحتوى ومعايير قبول، ثم حدود دور الوكالة والشريك والعميل. يشرح كذلك تسلسل البريف وتجربة المستخدم والتطوير والاختبار والإطلاق، وما ينبغي فحصه في الجوال والعربية ونموذج الاتصال والزحف والأداء وقابلية الوصول. الأمثلة الواردة افتراضية لتوضيح القرار، وليست نتائج مشاريع أو صيغة تعاقدية ملزمة. الغاية أن تستطيع بيع خدمة واضحة، ومراجعة التنفيذ بثقة، وتسليم موقع يمكن للعميل تشغيله دون بقاء مفاتيحه أو ملفاته رهينة لطرف واحد
ابدأ من حدود الوعد الذي بعته، لا من شكل الصفحة الرئيسية
قد تعرض الوكالة على عميلها «موقع شركة» ويعرض شريك التنفيذ عليها «تصميم خمس صفحات». يبدو الوصفان متوافقين حتى يسأل العميل عن كتابة النصوص، وربط نموذج الطلب بالبريد، وصفحة الشكر، واللغة الإنجليزية، ونقل الموقع القديم. عندها يظهر أن كلمة «موقع» أخفت قرارات لم يتخذها أحد. قبل تثبيت موعد التسليم، حوّل العرض التجاري إلى نطاق يمكن اختباره: ما الصفحات؟ من يقدم المحتوى؟ أي وظائف تتطلب حسابات أو خدمات خارجية؟ ما الذي يعد عملًا منجزًا؟ وما الذي ينتظر قرارًا من العميل؟
هذه زاوية تشغيلية داخل خدمات وايت ليبل، لا شرح عام لفكرة الاستعانة بشريك ولا مقالًا عن هامش إعادة البيع. إذا كانت الوكالة تقيّم نموذج الشراكة نفسه، فصفحة خدمات وايت ليبل لشركات التسويق هي نقطة البداية. أما هنا فالسؤال أضيق: كيف تمنع الخلاف على حدود التنفيذ والملكية والتسليم في مشروع موقع محدد؟
افترض مثالًا توضيحيًا: وكالة تسويق تبيع موقعًا تعريفيًا لشركة خدمات لديها نسخة عربية ونسخة إنجليزية. اتفقت الأطراف شفهيًا على «تصميم متجاوب مع نموذج تواصل». بعد الموافقة على التصميم، طلب العميل أن تظهر خدماته في صفحات مستقلة، وأن تصل الطلبات إلى قسمين، وأن ينتقل أرشيف المقالات من الموقع القديم. هذه ليست تفاصيل لون أو خط؛ إنها توسعات تمس بنية المحتوى والوظائف والاختبار والوقت. النطاق الجيد لا يمنع الطلب، لكنه يجعل أثره مرئيًا قبل التنفيذ
ما الذي يجب أن يرد في نطاق العمل؟
اكتب وثيقة قصيرة يفهمها مدير الحساب والمصمم والمطور والعميل بالمعنى نفسه. ابدأ بهدف الموقع: تقديم خدمات الشركة، توليد طلبات اتصال، إتاحة حجز، أو بيع منتجات. ثم اربط الهدف بمسارات استخدام محددة؛ زائر يأتي إلى صفحة خدمة، يفهم العرض، يصل إلى نموذج أو وسيلة اتصال، ويتلقى إقرارًا واضحًا بما حدث بعد الإرسال. إذا كان الهدف متعددًا، رتب أولوياته بدل جمع كل شيء تحت عبارة «تجربة مستخدم مميزة»
بعد الهدف، سمّ الصفحات والقوالب. الصفحة الثابتة ليست قالب المقالات، وقالب الخدمة القابل للتكرار ليس إعداد كل خدمة فعلية. حدد عدد الصفحات المشمولة أو قائمة أسمائها، والقوالب القابلة لإعادة الاستخدام، والعناصر العامة مثل الترويسة والتذييل والقائمة والبحث. بين هل يتضمن العمل إدخال المحتوى النهائي، أم تجهيز أماكنه فحسب، وهل توجد لغة ثانية مع ترجمة معتمدة أم مجرد تمكين تقني لها. لا تكتب «ثنائي اللغة» إن لم تحدد من يترجم ومن يراجع اتجاه الواجهة والروابط بين النسختين
صف الوظائف بوصف سلوك يمكن تجربته. «نموذج اتصال» تعني حقولًا معلومة، قواعد تحقق، مستلمًا أو نظام استقبال، رسالة نجاح ورسالة فشل، وسياسة للتعامل مع الرسائل المزعجة. «ربط تحليلات» يحتاج تحديد الحساب المالك، والأحداث المطلوبة، وطريقة التحقق، وحدود ما يمكن اعتباره طلبًا حقيقيًا. «لوحة تحكم» قد تعني صلاحية تعديل النص والصورة، لا صلاحية إدارة الخادم أو حذف المستخدمين. عبارات مثل «جميع التكاملات» أو «سيو كامل» تنقل الخلاف إلى نهاية المشروع
اذكر الاستثناءات بنفس وضوح المشمولات، لكن دون تحويل الوثيقة إلى قائمة دفاعية طويلة. إن لم يشمل العمل شراء الصور، أو كتابة المحتوى، أو تصوير الفريق، أو دفع رسوم أدوات خارجية، أو ترحيل قاعدة بيانات قديمة، فقل ذلك وأشر إلى المسار المتاح لإضافته. الاستثناء المفيد يفتح قرارًا: من سيقدمه؟ متى؟ وهل يتوقف عليه اعتماد التصميم أو الإطلاق؟
من المخرجات التي يسهل نسيانها: خريطة صفحات معتمدة، ملفات تصميم قابلة للمراجعة، نسخة اختبار، سجل ملاحظات، قائمة قبول، موقع مباشر، توثيق حسابات وصلاحيات، تدريب مختصر، وسجل لما بقي خارج النطاق. لا يلزم أن تكون كلها ملفات ضخمة؛ قد تكون صفحة واحدة منظمة. المهم أن يستطيع طرف آخر فهم ما سُلّم وما لم يُسلّم دون الرجوع إلى محادثة متفرقة
ملكية الموقع: افصل الأصل عن صلاحية استخدامه
قبل أن يبدأ التصميم، ضع سجل ملكية وتسليم لكل عنصر. الدومين، الاستضافة، مستودع الشيفرة، نظام إدارة المحتوى، البريد المرتبط بالنطاق، حسابات التحليلات، ملفات التصميم، الخطوط، الصور، النصوص، إضافات مدفوعة، ونسخ احتياطية ليست شيئًا واحدًا. قد يستطيع الشريك تشغيل الموقع داخل حسابه، لكن ذلك لا يجيب عن سؤال من يحق له تجديد الدومين أو إيقاف الاستضافة أو تنزيل ملفات المصدر عند انتهاء العلاقة. الترتيب الأفضل عمليًا أن يُعرَف صاحب القرار وصاحب الفاتورة وصاحب صلاحية الإدارة وآلية النقل لكل أصل على حدة
في الدومين تحديدًا، اسأل من هو المسجّل الفعلي، وفي أي حساب، وعلى أي بريد تصل إشعارات التجديد. إن كان النطاق موجودًا أصلًا لدى العميل، فغالبًا يكفي تفويض تقني محدود لتعديل السجلات المطلوبة بعد اعتماد التغيير. لا تجعل سهولة التنفيذ سببًا لنقله خفية إلى حساب الشريك. وإن كان شراء الدومين جزءًا من العرض، فليُسجل مسبقًا اسم الجهة التي سيُنشأ الحساب باسمها، ومن يتحمل التجديد، وكيف تُستعاد السيطرة عند تغير الوكالة أو الشريك
الاستضافة مسألة مختلفة عن الدومين. اكتب نوع البيئة ومن يديرها ويدفع رسومها، وماذا يحدث عند انتهاء فترة الدعم. إذا استضاف الشريك النسخة التجريبية، فميّزها من البيئة النهائية. حدد من ينشئ النسخ الاحتياطية، وتواترها ومكان حفظها وطريقة اختبار استعادتها، ومن يملك حق طلب نسخة قابلة للنقل. لا يكفي أن يقول أحد الأطراف «الموقع لك» بينما لا يملك العميل سوى دخول محرر الصفحات
في ملفات المصدر، فرّق بين الشيفرة التي أُنشئت خصيصًا للمشروع، والأدوات أو القوالب أو المكتبات الموجودة مسبقًا، والتراخيص التابعة لطرف ثالث. حدّد ما الذي سيُسلَّم: مستودع، حزمة ملفات، قاعدة بيانات، إعدادات بناء، ملف تعليمات تشغيل، أو تصدير من نظام إدارة المحتوى. ليس كل موقع يحتاج مستودعًا مستقلًا، لكن كل موقع يحتاج طريقة واضحة لإعادة تشغيله أو نقله ضمن ما يسمح به ترخيص مكوناته. النص الذي يقول «تسليم المصدر» دون وصف الصيغة ومتى يتم التسليم يترك بابًا لخلاف غير ضروري
المحتوى أصل آخر. على الوكالة أن تعرف هل النصوص مقدمة من العميل، أم يكتبها فريقها، أم يجهز الشريك مسودات تحتاج مراجعة. من يعتمد دقة أسماء الخدمات والوعود والصور والشهادات؟ من يحتفظ بالنسخة المعتمدة؟ لا تنقل نصًا من عرض قديم إلى صفحة جديدة لمجرد ملء الفراغ. وينطبق الأمر على بيانات الأشخاص في صور الفريق أو الاقتباسات؛ لا تفترض أن وجودها في عرض تسويقي سابق يعني جواز إعادة استخدامها في كل سياق
أما الصور والخطوط والأيقونات والقوالب والتصاميم المشتراة، فالسؤال ليس «هل وجدنا ملفًا؟» بل «ما حق الاستخدام الذي يغطي هذا الموقع وهذا الطرف وطريقة التسليم؟». سجّل مصدر الأصل، والترخيص أو الإذن المتاح، والقيود العملية التي تظهر في شروطه، ومن يحتفظ بإثبات الشراء. لا تفترض قاعدة قانونية موحدة للسعودية والخليج، ولا تعد بنقل حق لا يملكه المنفذ. عندما يكون النص التعاقدي أو الترخيص ملتبسًا، اطلب مراجعة مختصة بدل أن تُحل المسألة بعبارة عامة في المقال أو العرض
الحسابات تستحق جردًا منفصلًا: من أنشأ حساب الاستضافة، وإدارة النطاق، والتحليلات، وSearch Console، وأداة النماذج، والبريد المرسل، ومستودع الشيفرة؟ لكل حساب عيّن مالكًا إداريًا ومستخدمين مفوضين بقدر الحاجة، وطريقة استرداد لا تعتمد على بريد موظف قد يغادر. يجب ألا تظهر كلمات المرور في ملف التسليم أو في محادثة مفتوحة. التسليم الآمن يعني نقل الصلاحيات وفق قناة مناسبة، التحقق من دخول صاحب الحق، ثم سحب صلاحيات من انتهى دوره بعد اكتمال النقل
ثلاثة أطراف، ومسؤولية واحدة واضحة عند كل قرار
الوكالة هي وجه العلاقة التجارية أمام العميل حين تبيع الخدمة تحت علامتها. عليها إدارة الوعد والجدول والموافقات وترجمة احتياج العميل إلى بريف واضح، لا مجرد إعادة توجيه رسائل بينه وبين المطور. شريك التنفيذ مسؤول عن تقدير العمل الفني، والتنبيه المبكر للتبعيات والمخاطر، وإظهار ما يحتاجه من قرارات، وتنفيذ المخرجات المختبرة ضمن النطاق. والعميل مسؤول عن توفير ما يملكه من معلومات وأصول وموافقات وصلاحيات، وعن اعتماد القرارات التجارية والمحتوى في وقت معلوم. يمكن تعديل هذا التقسيم باتفاق صريح، لكن لا تترك قرارًا بلا صاحب
مثلًا، إذا كانت صفحة الخدمة تتضمن ادعاءً عن مدة استجابة الشركة، فالعميل يعتمد صحته، والوكالة تضبط صياغته واتساقه مع العرض، والشريك يضعه في الموضع المتفق عليه ويختبر عرضه. لا يجوز تحميل المطور وحده دقة وعد تجاري لم يصدر عنه. وفي المقابل، إن وجد المطور أن نموذج الاتصال لا يرسل إلى الجهة المحددة، فهذه مشكلة تنفيذ واختبار لا تعالجها موافقة العميل على شكل الصفحة
حدد قناة التواصل أيضًا. هل يتحدث الشريك مباشرة مع العميل في اجتماع تقني تقوده الوكالة، أم تمر جميع الأسئلة عبر مدير الحساب؟ في عمل وايت ليبل قد تكون سرية هوية الشريك جزءًا من العلاقة، وقد يكون الظهور التقني المحدود مسموحًا. اكتب القاعدة بدل افتراضها. وعيّن من يسجل القرار النهائي بعد الاجتماع؛ فالموافقة الشفهية على تصميم أو وظيفة ينبغي أن تتحول إلى ملاحظة محددة يمكن الرجوع إليها
من البريف إلى خريطة الموقع: أوقف التخمين مبكرًا
البريف الجيد لا يبدأ بسؤال العميل عن الألوان التي يحبها. يبدأ بمن سيستخدم الموقع، وما الأسئلة التي يحتاج إلى إجابة عنها قبل الاتصال، وما الإجراء الذي يريد النشاط تسهيله. اطلب قائمة الخدمات الفعلية، والفئات المستهدفة، والمواد المعتمدة، والأمثلة التي يراها العميل ناجحة مع توضيح السبب، وأي قيود على الهوية أو التحرير. افحص الموقع القائم إن وجد: ما الذي يجب الاحتفاظ به، وما الذي سينقل، وما الذي سيُحال إلى عنوان جديد؟ لا تجعل قرار حذف صفحة قديمة تابعًا لحماسة إعادة التصميم
إذا وصل البريف ناقصًا، لا تملأ الفراغ بافتراض صامت. استخدم سجل أسئلة مفتوحة: «هل توجد صفحة لكل خدمة أم صفحة واحدة؟»، «من يراجع الترجمة؟»، «ما بريد استقبال النماذج؟»، «هل يوجد نظام مبيعات يستقبل الطلبات؟». اربط كل سؤال بأثره على النطاق أو الجدول. قد تُبنى النسخة البصرية بمحتوى مؤقت لأغراض المراجعة، لكن يجب وسمه مؤقتًا وألا يتحول إلى نص منشور بسبب ضيق الوقت
في المثال الافتراضي السابق، يمكن أن ينتج البريف خريطة من صفحة رئيسية، وصفحات خدمات محددة، وعن الشركة، واتصال، وسياسة خصوصية يزود العميل نصها المعتمد. إن طلب العميل مدونة، فاسأل هل المطلوب قالب عرض ومحرر فقط، أم نقل مقالات موجودة، أم كتابة محتوى جديد. هذه أعمال مختلفة. ومن المناسب هنا أن تبقى صفحة تصميم وتطوير المواقع الإلكترونية مرجعًا لوصف الخدمة نفسها، بينما يركز هذا المقال على كيفية إدارتها بين الوكالة وشريك التنفيذ
مرحلة UX والمحتوى: اختبر الرحلة قبل زخرفة الواجهة
بعد اعتماد البريف، ارسم رحلة زائر واقعية: يدخل من صفحة خدمة على الجوال، يمسح عنوانها، يفهم لمن تصلح، يرى دليلًا أو وصفًا كافيًا، ثم يختار الاتصال. قد يبدأ التصميم بمخطط منخفض الدقة يوضح ترتيب المعلومات والتصفح، قبل الألوان والصور والحركة. مخرج هذه المرحلة ليس صورة جميلة فحسب؛ إنه قرار بشأن هيكل الصفحة ومكان الإجراء الرئيسي وما سيحدث عند فشل المسار. إذا تغيرت بنية الخدمات بعد اعتماد المخطط، فوثق سبب التغيير وأثره
للمحتوى دور تنفيذي، لا تجميلي. طول العنوان العربي قد يغير توازن بطاقة صُممت على عبارة إنجليزية قصيرة. وصف الخدمة الفعلي قد يحتاج أسئلة وإجابات بدل ثلاث بطاقات عامة. لذلك حدّد في وقت مبكر من يكتب النص، ومن يراجع المعلومات الفنية، ومن يعتمد النسخة النهائية. جهّز نموذج محتوى لكل نوع صفحة: عنوان واضح، وصف موجز، تفاصيل قرار، أسئلة شائعة عند الحاجة، وإجراء تواصل. لا تُلقِ مسؤولية «استبدال النص المؤقت» على مرحلة الإطلاق بلا صاحب
في النسخ العربية والخليجية، اختبر الاتجاه من اليمين إلى اليسار على مكونات فعلية لا على صفحة مثال واحدة. راقب ترتيب الحقول وأيقونات الأسهم ومسار القائمة وتجاور رقم الهاتف والإنجليزية داخل الفقرة. النص الإنجليزي داخل صفحة عربية قد يحتاج ضبط اتجاه مستقل، والعكس. على الجوال، تأكد أن زر الإجراء لا يحجب المحتوى، وأن القوائم يمكن فتحها وإغلاقها، وأن العناوين لا تنكسر بصورة مربكة. لا يعني «متجاوب» مجرد تقلص الأعمدة إلى عمود واحد
قرار اعتماد التصميم ينبغي أن يوضح ما اعتمد فعلًا: تخطيط الصفحات، الأسلوب البصري، المكونات، أم النصوص أيضًا. احفظ نسخة مرجعية وروابط النماذج وتاريخ الملاحظات. كثير من النزاع يبدأ حين يقول طرف «وافقنا على التصميم» ويعني الآخر «وافقنا على كل نص وصورة ووظيفة». فصل هذه الموافقات يوفر على الجميع إعادة عمل لا ضرورة لها
التطوير: ابنِ ما يمكن تحريره وصيانته، لا ما يبدو مكتملًا في العرض
عند بدء التطوير، اتفقوا على البيئة التجريبية ومن يستطيع الوصول إليها، وكيف ستدار النسخ والتعديلات. يفيد أن يرى مدير الحساب تقدمًا على صفحات حقيقية بدل انتظار رابط نهائي مفاجئ. لكن البيئة التجريبية ليست إذنًا لنشر بيانات العميل الحساسة أو فتحها للفهرسة. حدّد كيف تُحجب عن الجمهور عند الحاجة، وكيف سيُنقل المحتوى المعتمد إلى الموقع النهائي دون فقد التنسيقات أو الروابط
اختر نظام الإدارة وفق حاجة العميل إلى التحرير، لا وفق أداة الشريك المفضلة وحدها. ما الحقول التي يمكن لغير المطور تعديلها؟ هل يستطيع العميل إضافة خدمة من قالب مضبوط دون كسر الصفحة؟ من يحدّث الإضافات؟ كيف تحفظ الإعدادات إن انتقل الموقع إلى بيئة أخرى؟ إن كانت بعض المكونات مرخصة باشتراك يملكه الشريك، فأظهر أثر انتهاء الاشتراك قبل أن يعتمد العميل عليها. «لوحة سهلة» لا تعني شيئًا حتى ينجز مستخدم غير تقني تعديلًا مألوفًا بنفسه
في وظائف النماذج والتكاملات، قلل الصلاحيات إلى المطلوب، واحتفظ بمفاتيح الخدمات خارج المحتوى المكشوف. اعرف جهة استقبال الطلبات وحدود البيانات التي ستُجمع، وأين تُحفظ، ومن يقرأها، وكيف يحذفها صاحب الصلاحية عند الحاجة. إذا كانت هناك خدمة بريد أو CRM خارجي، فالفشل قد يقع بين النموذج والخدمة لا داخل الصفحة نفسها؛ لذلك يحتاج المسار إلى اختبار من الواجهة حتى نقطة الاستقبال المتفق عليها، لا الاكتفاء بظهور رسالة نجاح
SEO قابل للزحف: شرط بنيوي، لا وعد بظهور الصفحة
جزء من قبول الموقع أن تكون صفحاته المهمة قابلة للوصول عبر روابط واضحة وبنية مفهومة. توضح إرشادات Google للروابط القابلة للزحف أن الرابط المعتاد داخل عنصر <a> مع خاصية href هو الصيغة التي يمكن لمتتبع Google تحليلها بصورة موثوقة، بخلاف عناصر تعتمد على النقر البرمجي وحده. لذلك افحص قائمة الخدمات، والروابط بين الصفحات، وعناوين الأزرار النصية: هل تذهب إلى عناوين فعلية؟ وهل يشرح نص الرابط وجهته؟
تحتاج صفحات المشروع أيضًا إلى عناوين ووصف تحريري مناسبين، وهيكل عناوين منطقي، وعناوين URL مستقرة قدر الإمكان، وقرارات مقصودة بشأن الصفحات التي لا ينبغي عرضها في البحث. إن كان هناك موقع قديم، فلا تغيّر العناوين ثم تكتفي بخريطة موقع جديدة؛ جهّز مطابقة بين القديم والجديد وتحويلات مناسبة للصفحات التي انتقلت. اختبر صفحة خدمة منشورة كما يراها الزائر وكما يمكن الوصول إليها من داخل الموقع. القابلية للزحف خطوة فنية؛ الفهرسة ثم الظهور في نتائج ملائمة موضوعان لاحقان لا يمكن التعهد بهما بمجرد تسليم الموقع
تجنب تسمية هذا النطاق «خدمة SEO شهرية» ما لم تكن فعلًا جزءًا من العقد. المطلوب عند بناء الموقع أساس تقني ومحتوى قابل للقراءة والتنقل، مع قائمة واضحة بما يتطلب عملًا لاحقًا: استراتيجية محتوى، مراجعة استعلامات، تحسين صفحات، أو متابعة الفهرسة. بذلك يعرف مدير الوكالة ما يبيعه الآن وما يحتاج عرضًا منفصلًا، ولا يصبح شريك التطوير مسؤولًا عن ترتيب لم يعد به
الأداء وقابلية الوصول: حوّل المصطلحات إلى اختبارات
قِس سرعة وتجربة الصفحة على صفحات تمثل الاستخدام الحقيقي، لا الصفحة الرئيسية وحدها. تشير وثائق Google عن Core Web Vitals إلى LCP لتجربة التحميل، وINP للاستجابة للتفاعل، وCLS للاستقرار البصري. تذكر الوثيقة عتبات جيدة مرجعية، لكنها لا تقول إن تحقيقها يضمن ترتيبًا بعينه. اتفقوا على طريقة القياس، وأداة الفحص، والصفحات والعينات، والتمييز بين بيانات مستخدمين فعلية إن توفرت وقياس مختبري لحظة الاختبار. كما ينبغي تسجيل أثر الصور والخطوط والبرمجيات الخارجية التي يطلبها العميل بعد التسليم
المراجعة المفيدة تسأل: هل صورة الواجهة أكبر مما يلزم؟ هل يقفز المحتوى بعد تحميل خط أو إعلان؟ هل يتأخر تفاعل القائمة على هاتف متوسط؟ وهل يظل زر النموذج قابلًا للاستخدام أثناء التحميل؟ قد تظهر نتيجة مختبرية جيدة بينما يعاني مستخدمو منطقة أو جهاز معين، وقد تكون بيانات الاستخدام الفعلي غير متاحة لموقع جديد. لا تضع رقمًا مضمونًا مجردًا من الجهاز والصفحة وطريقة القياس، بل اتفق على فحص وتحسين ثم توثيق الباقي وأسبابه
قابلية الوصول ليست شهادة يشتريها المشروع في آخر أسبوع. يذكر مرجع W3C لمعايير WCAG 2.2 معايير عملية، منها تشغيل الوظائف بلوحة المفاتيح، وإتاحة تسميات أو تعليمات للمدخلات، ومتطلبات تباين للنصوص بحسب السياق. ترجم ذلك إلى فحوص: هل يمكن الوصول إلى القائمة والنموذج وإرسالهما دون فأرة؟ هل يظهر موضع التركيز؟ هل يعرف المستخدم ما الحقل المطلوب وما الخطأ وكيف يصححه؟ هل النص مقروء فوق خلفيته؟
افصل بين فحص آلي سريع وفحص يدوي للمسارات المهمة. الأداة قد ترصد تسمية مفقودة، لكنها لا تحكم وحدها إن كانت العبارة العربية مفهومة، أو إن كان ترتيب القراءة المنطقي يطابق ترتيب العرض بعد تغيير اتجاه الصفحة. اطلب من الشريك تقريرًا قصيرًا بما اختبره وما أصلحه وما بقي، لا عبارة «متوافق مع جميع المعايير» التي يصعب إثباتها. وإذا كان العقد يتطلب مستوى امتثال محددًا، فسمّه ونطاق الصفحات وآلية التقييم قبل البدء
اختبار نموذج الاتصال من منظور من سيدير الطلب
النموذج غالبًا أكثر نقطة ترتبط بعائد الموقع للعميل، ومع ذلك يُختبر أحيانًا بزر الإرسال فقط. ابدأ من سيناريو زائر على الجوال: يرى تسميات واضحة، يفهم الحقول المطلوبة، يختار وسيلة التواصل، يرسل بيانات معقولة، ثم يرى تأكيدًا لا يوهمه بوصول لم يحدث. اختبر الحقول الفارغة، وصيغة البريد الخاطئة، ورسالة طويلة، والعربية والإنجليزية إن وُجدتا، وإعادة المحاولة عند الانقطاع. لا تعرض تفاصيل تقنية أو بيانات شخصية في رسالة الخطأ العامة
بعد ذلك تحقق من جهة الاستقبال. هل تصل الرسالة إلى البريد أو النظام المتفق عليه؟ هل تظهر الحقول الأساسية دون اقتطاع أو اختلاط اتجاه؟ هل يصل إشعار إلى الجهة الصحيحة، وهل لدى الفريق طريقة لمعرفة الطلبات التي لم تسلّم بسبب عطل؟ ظهور رسالة نجاح في المتصفح لا يثبت وصول البريد إلى صندوق المستلم، وتسجيل حدث تحليلات لا يثبت أن موظفًا عالج الطلب. إن كان التنفيذ يستخدم بريدًا وسيطًا أو خدمة طرف ثالث، فحدّد مسؤولية متابعة أعطالها
لا تجعل اختبار النموذج سببًا لتوليد طلبات فعلية كثيرة داخل نظام مبيعات العميل. نسّق اختبارًا موسومًا بوضوح، مع جهة استقبال تعرف موعده، ثم احذف البيانات التجريبية وفق ما يسمح به النظام. وعند ربط التحليلات، تجنب إرسال الاسم أو البريد أو نص الرسالة ضمن الحدث. يكفي قياس فعل مناسب مع فصل النقر على زر التواصل، ومحاولة الإرسال، والنجاح المؤكد بحسب ما يمكن إثباته تقنيًا
QA قبل الإطلاق: من يختبر ماذا، وبأي دليل؟
اجعل الاختبار مرحلة لها وقت ومسؤولية، لا فسحة بين «انتهى التطوير» و«اضغط نشر». يختبر الشريك الوظائف، والأخطاء التقنية، والروابط، والصفحات والقوالب، والجوال، وتناسق الاتجاه العربي، ومسارات الوصول. تراجع الوكالة اتساق التنفيذ مع العرض والهوية والمحتوى المعتمد ووضوح الإجراء التجاري. يراجع العميل صحة الحقائق والأسماء والأصول والجهة التي ستستقبل الطلبات. إذا شارك أحدهم في اختبار مجال الآخر فهذا جيد، لكن لا ينبغي أن يضيع مالك الاعتماد النهائي
استخدم قائمة قبول مرتبطة بالنطاق: الصفحة موجودة، عنوانها صحيح، نصها معتمد، زرها يعمل، وصورتها مرخصة أو مقدمة بإذن، ونسختها على الجوال قابلة للقراءة. سجّل لكل ملاحظة رابط الصفحة، الجهاز أو المتصفح إن كان مهمًا، خطوات إعادة ظهور المشكلة، شدتها، وصاحب إصلاحها. فرق بين عيب يمنع الإطلاق، وتحسين يمكن جدولته، وطلب جديد خارج النطاق. كلمة «تعديل بسيط» لا تصف دائمًا أثر تغيير بنية صفحة أو تكامل
في المثال الافتراضي، قد يكتشف مدير الحساب أن نموذج النسخة الإنجليزية يرسل إلى عنوان مختلف من المتفق عليه، بينما يكتشف العميل أن اسم خدمة في الصفحة العربية غير معتمد. الأولى عيب وظيفي قد يوقف الإطلاق؛ الثانية خطأ محتوى يحتاج اعتماد الصياغة الصحيحة. وقد يطلب العميل بعد رؤية الموقع إضافة حاسبة تكلفة؛ هذه وظيفة جديدة لا تُخفى داخل قائمة العيوب. هذا التصنيف يحافظ على علاقة مهنية هادئة ويمنع اختلاط تصحيح المتفق عليه بتوسيع المشروع
الإطلاق خطوة انتقال، والتسليم إثبات قدرة على الاستمرار
قبل نقل الموقع إلى العنوان النهائي، حدّد نافذة الإطلاق ومن يستطيع اتخاذ قرار التراجع، واحتفظ بنسخة يمكن استعادتها عند الحاجة. راجع إعدادات النطاق والشهادة والروابط الداخلية وملفات الوسائط والنموذج والصفحات الأساسية في البيئة النهائية. إذا كان هناك انتقال من موقع سابق، اختبر عينة من العناوين القديمة وتحويلاتها، ولا تفترض نجاحها لأن الصفحة الرئيسية فتحت. راجع أيضًا أي إعداد مؤقت منع الزحف أثناء العمل حتى لا يبقى على النسخة العامة بغير قصد
بعد الإطلاق، افتح الموقع من اتصال وجهاز لا يعتمدان على جلسة المطور وحدها. اطلب إرسالًا تجريبيًا من النموذج والتحقق من الاستقبال، واختبر رابطًا من كل نوع صفحة، وألق نظرة على الجوال والاتجاه العربي. إن كان هناك حساب تحليلات أو أداة بحث، فتأكد من ملكية الحساب وإمكانية الوصول إليه وفق الاتفاق. وجود الموقع على العنوان الصحيح لا يثبت أن كل مساره التجاري يعمل، كما أن إرسال خريطة موقع لا يثبت فهرسة صفحاته
ملف التسليم المناسب ليس أرشيف كلمات مرور. اجعله فهرسًا آمنًا: قائمة الأصول والحسابات وملاكها، طريقة الوصول عبر قنوات معتمدة، ما سُلّم من ملفات وتصاميم ومحتوى، تراخيص المكونات، تعليمات التحديث والنسخ الاحتياطي، قائمة المشكلات المعروفة، ومسؤول الاتصال عند العطل. أضف جلسة قصيرة يرى فيها ممثل العميل كيف يعدل عنصرًا مألوفًا وكيف يطلب دعمًا إذا لم يستطع. ثم أثبت أن المالك المقصود يستطيع الدخول وأن صلاحيات التنفيذ الزائدة عولجت
يمكن تعريف «التسليم المقبول» في العقد بأنه اجتماع تحقق قصير مع قائمة محددة ومهلة لتسجيل العيوب المشمولة، لا صمت العميل بعد إرسال الرابط. وفي المقابل لا يصح إبقاء المشروع مفتوحًا بلا حد بسبب تحسينات جديدة. التسليم الجيد يحفظ للعميل حقه في التشغيل، وللوكالة قدرتها على إدارة العلاقة، وللشريك حدود مسؤوليته الفنية
SLA والصيانة والأمن بعد التسليم
هل انتهى دور الشريك عند الإطلاق أم تبدأ فترة دعم؟ أجب قبل البيع. ميّز بين إصلاح عيب في نطاق التطوير، وتحديث نظام أو إضافة، وتعديل محتوى، وتحسين جديد، واستجابة لحادث أمني. لكل نوع قناة طلب، وأولوية، ووقت استجابة مستهدف، وساعات تغطية، ومسؤول تشخيص، وحدود ما يشمله المقابل. لا تكتب «دعم على مدار الساعة» إن لم تكن هناك قدرة تعاقدية وتشغيلية فعلية لتنفيذه؛ كما أن وقت الرد الأول ليس وقت الحل النهائي
في اتفاق مستوى الخدمة، قد تصنف توقف النموذج أو الموقع كله أعلى من تعديل لون أو نص. لكن التصنيف لا يكفي وحده؛ حدد من يراقب المشكلة ومن يبلغ العميل، وكيف يصعّدها خارج ساعات العمل إن كانت التغطية مشمولة. إذا كانت الاستضافة عند العميل، فوضح ما الذي يستطيع الشريك إصلاحه دون صلاحية الخادم، وما الذي يتطلب تعاون مزود الاستضافة. وإذا كانت أداة خارجية هي سبب التعطل، فأظهر حدود مسؤولية الأطراف بدل وعد مطلق بالإصلاح
الأمن ممارسة مستمرة: صلاحيات محدودة، تحديثات مدروسة، نسخ احتياطية قابلة للاستعادة، وتوثيق تغييرات حساسة. لا يعني «تثبيت إضافة حماية» أن الموقع صار محصنًا. اتفقوا على من يراجع التحديثات قبل تطبيقها، ومن يختبر النماذج بعد تحديث مؤثر، ومن يتصرف إذا اشتبه في اختراق أو تسرب. عند انتهاء التعاقد، يجب أن توجد طريقة منظمة لنقل الإدارة أو إلغاء صلاحيات الشريك دون تعطيل موقع العميل. طبيعة البيانات التي يجمعها الموقع قد تستدعي التزامات خاصة؛ تحتاج تلك النقطة مراجعة قانونية وتنظيمية بحسب الحالة، لا افتراضًا عامًا هنا
التغيير والتعاقد: اجعل الطلب الإضافي قرارًا، لا خصومة
حين يطلب العميل شيئًا جديدًا، سجل الطلب بلغته ثم حوله إلى وصف تنفيذي. ما الوظيفة أو الصفحة الجديدة؟ ما علاقتها بما اعتمد سابقًا؟ هل تحتاج محتوى أو تصميمًا أو اشتراكًا أو صلاحية جديدة؟ ما أثرها على الجدول وقائمة الاختبار والتسليم؟ اعرض على الوكالة بدائل واضحة: إضافتها الآن بتعديل نطاق وموعد، أو إطلاق المتفق عليه ثم تنفيذها في مرحلة تالية، أو استبدال بند آخر بها إذا وافق جميع المعنيين. لا يبدأ الشريك العمل بناء على عبارة «شوفوا لو ممكن»
احتفظ بسجل قرار بسيط لكل تغيير: صاحب الطلب، سبب الحاجة، وصف ما سيتغير، تقدير الأثر، الجهة التي اعتمدت، والنسخة المرجعية الجديدة للنطاق. إذا كانت هناك موافقات داخلية لدى العميل، فلا تعد صمت جهة واحدة موافقة للجميع. العقود تختلف، لكن هذه الآلية التشغيلية تقلل سوء الفهم أيًا كانت الصياغة القانونية. النص القانوني النهائي بشأن الملكية والحقوق والتزامات الأطراف يجب أن يصاغ أو يراجع وفق العلاقة والولاية المعنية؛ لا يقدم هذا المقال حكمًا قانونيًا
نقطة مفيدة في عقد الوكالة مع الشريك هي مطابقة التزاماتها للعميل مع ما يستطيع الشريك تقديمه فعلًا. إذا وعدت الوكالة العميل بتسليم ملف التصميم القابل للتحرير، فلا يكفي أن يتعهد الشريك بصورة نهائية. وإذا تعهدت الوكالة بوقت استجابة محدد، فلتعرف من يتلقى البلاغات ومن يغطي الغياب. لا ينبغي أن يرى العميل التناقض بين العقدين يوم الإطلاق؛ اكتشفه وأصلحه قبل بدء التنفيذ
تمرين قرار سريع قبل إرسال عرض الموقع
اجمع مدير الحساب وممثل التنفيذ أمام صفحة واحدة، ثم اطلب من كل منهما الإجابة دون الرجوع إلى الآخر: كم صفحة وقالبًا في العرض؟ من يكتب النص النهائي؟ من يملك الدومين والاستضافة؟ أين تحفظ ملفات التصميم والمصدر؟ من يشتري الصورة أو يرخصها؟ ما دليل نجاح النموذج؟ من يوافق على العربية والإنجليزية؟ ما الذي سيُسلّم عند انتهاء العلاقة؟ إذا اختلفت الإجابات، فلا يزال العرض بحاجة ضبط مهما بدا السعر أو الرسم الأولي جذابًا
بعد توحيد الإجابات، اطلب من الشريك تقديرًا على أساس النطاق نفسه، ثم اجعل الوكالة تشرح للعميل ما سيحصل عليه بلغته التجارية. لا ترسل قائمة تقنية مفصولة عن هدفه، ولا تخفِ التبعيات التي تتطلب منه محتوى أو موافقة. هذا التمرين ليس بديلًا لعقد أو بريف كامل؛ هو اختبار مبكر يكشف الفجوات قبل أن تتحول إلى تأخير مكلف أو موقع يصعب تشغيله
أسئلة تتكرر عند تنفيذ تصميم مواقع وايت ليبل
هل يجب أن يكون الدومين باسم العميل دائمًا؟
القرار يعتمد على علاقة الأطراف وترتيبها التعاقدي، لكن يجب ألا يبقى غامضًا. اعرف من يملك الحساب المسجل، ومن تصله إشعارات التجديد، ومن يستطيع نقله، وما يحدث عند انتهاء التعاقد. إذا كانت الوكالة تدير الدومين نيابة عن العميل، فوثق التفويض وآلية إعادة السيطرة أو النقل بدل الاكتفاء بإعطاء العميل كلمة مرور
هل يكفي تسليم دخول مدير إلى WordPress أو نظام إدارة آخر؟
لا يكفي وحده إذا كان الاتفاق يشمل نقل الموقع أو مصدره أو أصول تصميمه. الدخول إلى لوحة التحرير يتيح مهامًا معينة، لكنه لا يثبت ملكية الاستضافة أو الملفات أو التراخيص أو النسخ الاحتياطية. حدد في النطاق صيغة التسليم المطلوبة واختبر إمكان استخدامها قبل إغلاق المشروع
من يعتمد النصوص والصور عندما يعمل الشريك خلف علامة الوكالة؟
يمكن أن تكتب الوكالة أو الشريك مسودة، لكن اعتماد الحقائق التجارية والصور التي تخص العميل ينبغي أن يكون من جهة مفوضة لديه بحسب الاتفاق. على الوكالة تنظيم الموافقة وحفظ النسخة المرجعية، وعلى الشريك تنفيذ النسخة المعتمدة. حقوق الصور والخطوط والأصول تحتاج تحققًا من المصدر والترخيص؛ وجود الملف وحده ليس موافقة عامة على استخدامه
هل يشمل «موقع محسن لمحركات البحث» ضمان الفهرسة أو الترتيب؟
لا. يمكن الاتفاق على أساس تقني قابل للفحص: روابط قابلة للزحف، صفحات قابلة للوصول، عناوين ومحتوى منظم، تحويلات عند النقل، وإعدادات مقصودة للصفحات العامة والخاصة. بعد الإطلاق تحتاج الفهرسة والظهور متابعة منفصلة، وتتأثر بعوامل خارج تسليم التطوير. سمّ مخرجات SEO الفنية بدل تقديم وعد ترتيب عام
كيف نقبل الأداء إذا تغيرت الصور أو أضيفت أدوات تتبع لاحقًا؟
حدد الصفحات وظروف القياس وتاريخ نسخة الاختبار والأصول الموجودة وقت الفحص. وثق القياس المختبري وبيانات المستخدمين الفعلية إن توفرت، وافصل أثر الإضافات اللاحقة. عند تسليم موقع جديد قد لا توجد بيانات ميدانية كافية، فلا تصف غيابها بأنه نجاح أو فشل. المقاييس تساعد على التشخيص والتحسين، وليست ضمان ترتيب
متى يتحول طلب العميل من تصحيح عيب إلى تغيير نطاق؟
إذا كان السلوك المطلوب موصوفًا في النطاق ولم ينفذ كما اتفقتم، فهو عيب يحتاج معالجة ضمن آلية القبول. أما وظيفة أو صفحة أو تكامل لم يدخل الاتفاق الأصلي، فهو طلب تغيير حتى لو بدا صغيرًا في الواجهة. ارجع إلى النسخة المعتمدة من البريف والمخرجات، ثم قدر أثر الطلب على الوقت والاختبار والتكلفة قبل البدء
هل يحتاج تسليم الموقع إلى فترة دعم بعد الإطلاق؟
ليس هناك جواب واحد يصلح لكل مشروع. المهم أن تنص الوثائق على ما يحدث بعد الإطلاق: مهلة معالجة العيوب، التحديثات، النسخ الاحتياطية، مراقبة الأعطال، وساعات الاستجابة إن كانت مشمولة. اجعل فرقًا واضحًا بين دعم التشغيل وتطوير ميزات جديدة. وإذا كان العميل سيدير الموقع بنفسه، فأعطه تعليمات وصلاحيات تناسب ذلك
اتفاق واضح ينتج موقعًا يمكن تشغيله
أفضل نقطة بداية لشركة تسويق تبيع تصميم المواقع تحت علامتها هي مشروع موصوف بدقة: هدف، صفحات، وظائف، محتوى، أصول، مالك لكل حساب، مراحل اعتماد، اختبارات قبول، وخطة تسليم ودعم. عندها يستطيع الشريك تقديم تنفيذ يمكن مراجعته، وتستطيع الوكالة حماية علاقتها بالعميل دون أن تجعل المعرفة التقنية رهينة شخص، ويحصل العميل على موقع يفهم كيف يديره وما الذي يملكه. إذا أردت مناقشة نطاق مشروع موقع أو توزيع المسؤوليات بين وكالتك وشريك التنفيذ، تواصل معنا مع ملخص الصفحات والوظائف والوضع الحالي للدومين والاستضافة، لنبدأ من أسئلة العمل الصحيحة
[…] وحده يكفي وعند نقلها إلى الموقع، يفيد الرجوع إلى دليل تصميم المواقع وايت ليبل لضبط ما يُسلّم للمطور وما يبقى قرارًا في دليل […]