الدعم الفني بعد تسليم الموقع أو التطبيق: ماذا يجب أن يشمل الاتفاق؟

أولاً: الضمان والصيانة والدعم والتطوير ليست شيئًا واحدًا

بعد تسليم الموقع أو التطبيق قد تسمع كلمات مثل ضمان، دعم فني، صيانة، وتطوير مستمر. إذا لم يتم تعريفها، يمكن أن يتوقع العميل تعديلات مفتوحة بينما تقصد الشركة إصلاح Bugs فقط.

الضمان يرتبط عادة بأخطاء وظائف تم تنفيذها ضمن النطاق. الصيانة تهتم بصحة النظام وتحديثاته ومراقبته. الدعم هو قناة التعامل مع المشاكل والأسئلة. أما التطوير فهو تغيير أو إضافة وظائف جديدة. يمكن دمج بعض هذه الخدمات في عقد واحد، لكن يجب أن تظل الحدود مفهومة.

1. ما الذي يدخل ضمن ضمان أخطاء التنفيذ؟

أفضل تعريف للـ Bug هو أن وظيفة متفقًا عليها لا تعمل كما تم اعتمادها، في ظروف تشغيل مدعومة. أما طلب تغيير التدفق أو إضافة خيار جديد بعد رؤية المنتج فغالبًا تطوير وليس إصلاح خطأ.

حدد بداية فترة الضمان: هل تبدأ من الإطلاق أم من قبول النسخة؟ وحدد ما يحدث إذا تأخر العميل في توفير بيانات أو حسابات لازمة للتشغيل.

2. ماذا قد تشمل صيانة الموقع أو التطبيق؟

• تحديث الاعتماديات أو الإضافات عند الحاجة وبعد الاختبار.
• مراقبة الأخطاء أو توقف الخدمة حسب البنية المتفق عليها.
• النسخ الاحتياطية واختبار الاسترجاع وفق الخطة.
• مراجعة سعة الاستضافة وقواعد البيانات مع نمو الاستخدام.
• تحديثات أنظمة التشغيل أو متاجر التطبيقات عندما تؤثر على المنتج.
• إصلاحات أمنية وتغييرات عاجلة مرتبطة بمزود خارجي.

3. زمن الاستجابة: استخدم درجات شدة بدل رقم واحد

ليس كل مشروع يحتاج SLA معقدًا. موقع شركة صغير قد يكفيه قناة واضحة وساعات عمل، بينما متجر أو نظام عمليات قد يحتاج تصعيدًا أسرع للحالات الحرجة.

4. من يتابع الخدمات الخارجية؟

قد يعمل منتجك على خدمات لا تملكها شركة البرمجة: بوابة دفع، SMS، بريد، خرائط، استضافة، متجر تطبيقات، أو API طرف ثالث. إذا غيّر المزود سياسة أو مفتاحًا أو إصدارًا، قد يحتاج المنتج تحديثًا.

اتفق من يراقب هذه الخدمات ومن يدفع رسومها ومن يتلقى تنبيهات الفواتير أو الأعطال. كثير من المشاكل “البرمجية” بعد الإطلاق تكون في الحقيقة صلاحية أو فاتورة أو تغييرًا من خدمة خارجية.

5. ماذا يجب أن ترى في تقرير صيانة بسيط؟

• المشاكل التي تم فتحها وإغلاقها.
• التحديثات أو الإصدارات التي تم نشرها.
• أي حوادث توقف أو أخطاء مهمة وما سببها.
• حالة النسخ الاحتياطية أو المراقبة إن كانت ضمن الخدمة.
• اقتراحات تطوير منفصلة عن مهام الصيانة.

كيف تختار مستوى الدعم المناسب؟

اسأل ما تكلفة توقف المنتج على عملك. إذا كان الموقع قناة معلومات ويمكن لفريقك الانتظار، فخطة بسيطة قد تكفي. إذا كان التطبيق أو النظام جزءًا من المبيعات أو التشغيل اليومي، فأنت تحتاج مراقبة واستجابة أكثر تنظيمًا.

لا تشترِ دعمًا 24/7 لمجرد أنه يبدو احترافيًا إذا لم تكن تحتاجه، ولا تعتمد على “اتصل بنا وقت المشكلة” لمنتج حرج. اربط مستوى الدعم بخطر العمل.

كيف تنظم بلاغات الدعم حتى لا تضيع بين الرسائل؟

حتى لو كان التواصل عبر واتساب سريعًا، يجب أن توجد طريقة يمكن الرجوع إليها لتتبع البلاغات المهمة. سجل المشكلة، الرابط أو الشاشة، وقت ظهورها، الجهاز أو المتصفح إن كان له علاقة، وصورة أو فيديو عند الإمكان. كل معلومة تقلل الوقت الذي يقضيه الفريق في إعادة إنتاج المشكلة.

صنف البلاغ حسب أثره لا حسب صوت المرسل. تعطل الدفع لكل المستخدمين يختلف عن خطأ بصري في صفحة داخلية، ومشكلة تمنع فريق التشغيل من الدخول تختلف عن طلب تحسين. التصنيف يساعد الشركة والعميل على استخدام الوقت في المكان الصحيح.

بعد الحل، اكتب باختصار ما تم تغييره وهل يحتاج مراقبة أو إجراء وقائي. هذا السجل يتحول مع الوقت إلى معرفة تشغيلية مفيدة، ويكشف الأنماط: إذا تكرر نفس العطل بسبب خدمة خارجية أو عملية يدوية، قد يكون الحل الحقيقي تحسين البنية بدل إصلاح الأثر كل مرة.

• وصف واضح لما كان متوقعًا وما حدث فعليًا.
• رابط أو شاشة وخطوات إعادة المشكلة.
• درجة التأثير على المستخدم أو المبيعات أو التشغيل.
• مرفقات تساعد على التشخيص بدون بيانات حساسة.
• مالك للبلاغ وحالة وتاريخ آخر تحديث.

كيف تقيس جودة دعم ما بعد البيع بدون وعود فضفاضة؟

لا يكفي أن تكتب الشركة «دعم 24/7» إذا لم يكن واضحًا ماذا يعني الدعم ومتى يبدأ القياس. في المشروعات التي تحتاج SLA، عرّف مستويات الأولوية وقناة البلاغ وساعات التغطية وهدف وقت الاستجابة، ثم افصل الاستجابة عن وقت الحل لأن بعض المشاكل تعتمد على مزود خارجي أو تحتاج تحقيقًا أعمق.

راجع شهريًا نوع البلاغات وتكرارها، وليس عددها فقط. انخفاض البلاغات قد يكون جيدًا، لكنه قد يعني أيضًا أن المستخدمين توقفوا عن الإبلاغ. الأفضل أن تنظر إلى المشكلات الحرجة، الأسباب المتكررة، سرعة استعادة الخدمة، وهل توجد تحسينات تمنع التكرار.

كما يجب أن تعرف ما لا يشمله الدعم: إضافة خصائص، إعادة تصميم، تغييرات كبيرة في المحتوى، أو رسوم خدمات خارجية. عندما تكون الحدود مكتوبة يمكن للفريق إعطاء تقدير منفصل للتطوير الجديد بدل تحويل عقد الصيانة إلى نطاق مفتوح يصعب على الجميع إدارته.

حوّل الصيانة إلى جدول وقائي بدل انتظار الأعطال

الدعم الجيد لا يبدأ فقط عندما يشتكي مستخدم. بعض الأعمال يمكن جدولتها: مراجعة التحديثات المهمة، صلاحية الشهادات والدومينات، سجلات الأخطاء، نجاح النسخ الاحتياطي، أداء الصفحات الحرجة، ورسوم الخدمات التي قد تتوقف إذا فشل الدفع. ليس كل مشروع يحتاج نفس القائمة؛ اختر ما يهدد التشغيل فعلًا.

للتطبيقات، تابع تحديثات أنظمة iOS وAndroid ومتطلبات المتاجر والمكتبات التي يعتمد عليها المنتج. وللمواقع التي تعتمد على البحث، راقب الأخطاء التقنية المؤثرة في الفهرسة والروابط والـ sitemap بعد تغييرات المحتوى أو البنية. وللأنظمة الداخلية، قد تكون سلامة التكاملات والمهام المجدولة والصلاحيات أهم من السيو.

ضع مراجعة دورية قصيرة للنتائج: ما الذي تعطّل؟ ما الذي تكرر؟ ما الذي يجب ترقيته؟ وما الذي يمكن تأجيله؟ بهذه الطريقة يصبح عقد الصيانة أداة لتقليل المخاطر، لا اشتراكًا ثابتًا لا يعرف العميل ماذا يحصل مقابله.

قبل توقيع عقد الدعم: خمس نقاط لا تتركها عامة

• ما الذي يعتبر Bug وما الذي يعتبر تطويرًا؟
• ما قناة وساعات الدعم وزمن الاستجابة؟
• من مسؤول عن النسخ الاحتياطية والخدمات الخارجية؟
• كيف تتم الموافقة على التغييرات والنشر؟
• كيف تنتهي الخدمة وكيف تُنقل الصلاحيات إن تغيّر المزود؟

أسئلة شائعة