قائمة متطلبات نظام تذاكر الدعم الفني قبل الشراء

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

لماذا تبدأ بالمتطلبات لا بالعروض

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

الوثيقة تعالج الثلاثة دفعة واحدة: تثبّت تعريف المشكلة عندك أنت، وتجبر كل العروض على الإجابة عن الأسئلة نفسها، وتنقل المقارنة من «أيهما أجمل» إلى «أيهما يحقق البند رقم 14». وهي لاحقًا العمود الفقري لـكراسة المتطلبات التي سترسلها للمورّدين، ولملحق الاستلام الذي تُثبت به أن ما سُلِّم هو ما اتُّفق عليه.

فئات المتطلبات السبع

قسّم الوثيقة إلى سبع فئات ثابتة. هذا التقسيم ليس شكليًا: كل فئة تُقابل جهة مختلفة عليها أن تراجع بنودها وتوقّع عليها — التشغيل، تقنية المعلومات، الأمن السيبراني، والمشتريات.

لاحظ نمط الصياغة في العمود الأخير: كل بند جملة خبرية يمكن للمورّد أن يجيب عنها بـ«نعم» أو «لا» أو «بتخصيص»، ويمكنك أنت أن تختبرها أمامه في العرض التجريبي. هذا هو الفرق بين متطلب ورغبة.

كيف تكتب متطلبًا قابلًا للاختبار

المتطلب الرديء يوافق عليه الجميع ولا يعني شيئًا. المتطلب الجيد يمكن أن يفشل. هذا هو المحك الوحيد: إن لم تستطع تخيّل سيناريو يجعل المورّد يقول «لا، نظامنا لا يفعل ذلك»، فما كتبته ليس متطلبًا بل شعار.

افصل الإلزامي عن المرغوب قبل أن يفعلها المورّد نيابةً عنك

قائمة من ستين بندًا كلها «مهمة» تساوي صفرًا عمليًا: أول ما تجد نظامًا يحقق 55 منها ستقنع نفسك بأن الخمسة الباقية ثانوية — حتى لو كان أحدها هو السبب الأصلي للشراء. صنّف كل بند إلى ثلاث درجات فقط، واكتب التصنيف قبل أن ترى أي عرض.

ثم اكتب بجانب كل بند إلزامي سببه التشغيلي في سطر واحد: «إلزامي لأن أغلب بلاغاتنا تصل من الميدان عبر الجوال». هذا السطر هو ما يحميك لاحقًا حين يضغط أحدهم لإسقاط البند من أجل خصم.

البنود الخاصة بالسياق السعودي

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

البند الأول والثاني يستحقان قسمًا مستقلًا في وثيقتك؛ تفصيلهما في دليل استضافة البيانات داخل السعودية. أما البند السادس فهو ما يمنع «الحبس لدى المورّد»: نظام لا تستطيع الخروج منه ببياناتك هو نظام يتفاوض معك من موقع قوة عند كل تجديد. اجعله بندًا إلزاميًا مكتوبًا، لا وعدًا شفهيًا بحسن النية.

أخطاء متكررة في كتابة المتطلبات

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

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

الأسئلة الشائعة