بوت واتساب

عن الخدمة ونطاق العمل

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

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

تفاصيل بوت واتساب

تجهيز طلب الخدمة

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

• وصف المستخدمين والوظائف المطلوبة وأمثلة لرحلة الاستخدام
• التقنيات والأنظمة الحالية وبيئة الاختبار المتاحة
• متطلبات الصلاحيات والبيانات والتكاملات ونطاق التسليم

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

تحديد النطاق قبل كتابة الشيفرة

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

الاختبار وبيئة التجربة

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

التسليم والصيانة والملكية

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

دليل عملي لتخطيط بوت واتساب وتسليمه

ابدأ بالمهمة التي يريد المستخدم إنجازها

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

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

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

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

اختيار ما يستحق الأتمتة

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

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

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

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

كتابة مسار محادثة مفهوم

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

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

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

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

الرسائل والقوائم والتعامل مع الالتباس

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

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

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

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

ربط المحادثة ببيانات العمل

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

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

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

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

تسليم الحديث إلى موظف مع سياق كافٍ

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

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

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

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

حماية البيانات وضبط الصلاحيات

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

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

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

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

الاختبار قبل الإطلاق

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

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

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

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

المتابعة والتكلفة وقابلية الصيانة

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

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

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

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

ما يجهزه العميل وما يتضمنه التسليم

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

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

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

مراجعة الجودة واستلام العمل

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

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

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

أسئلة شائعة عن بوت واتساب

كيف تحدد مدة الخدمة وتكلفتها؟

يعتمد التقدير على حجم الطلب وجودة المدخلات وتعقيد التنفيذ وعدد النسخ أو مراحل المراجعة. أرسل وصف احتياجك وعينة مناسبة لنحدد النطاق قبل البدء. لا تعني تسمية الخدمة وحدها أن جميع الطلبات متساوية في الجهد.

هل يمكن تنفيذ جزء من المشروع أولًا؟

يمكن الاتفاق على مرحلة أولى محددة عندما يساعد ذلك على توضيح الاتجاه أو اختبار ملاءمة المخرج. يجب أن تكون لهذه المرحلة نتيجة يمكن تقييمها، وأن توضح علاقتها بما قد يليها من مراحل.

ما الذي يشمله التسليم؟

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

خدمات مرتبطة