دورة حياة طلب العميل: ارسم خريطتها قبل تصميم الشاشات

لماذا تفشل الشاشات من دون خريطة للطلب

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

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

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

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

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

• ما المعلومات التي تبدأ الطلب؟
• من يملك الإجراء التالي؟
• ما الحالات التي يمكن أن تأتي بعد كل قرار؟
• متى يبدأ الموعد النهائي أو يتوقف أو ينتهي؟
• من يحتاج إلى إشعار عند تغيّر الطلب؟

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

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

ابدأ بطلب واحد ونتيجة واضحة

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

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

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

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

غالبًا ما يكشف التعريف القصير القواعد الناقصة قبل بدء التصميم:

• نوع الطلب: استرداد مبلغ لطلب مدفوع
• البداية: يرسل العميل نموذجًا أو يتواصل مع الدعم
• النهاية: يتلقى العميل قرارًا بالموافقة أو الرفض، ويسجل الفريق القرار
• الاستثناء: يطلب فريق الدعم تفاصيل الطلب الناقصة قبل اتخاذ القرار

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

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

حدّد الحالات التي يمكن أن يدخلها الطلب

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

قد يتضمن طلب الدعم أو الخدمة المعتاد الحالات التالية:

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

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

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

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

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

ارسم الانتقالات وحدد من يفعّلها

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

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

قد تتضمن الخريطة البسيطة الانتقالات التالية:

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

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

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

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

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

عيّن مالكين لكل عملية تسليم

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

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

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

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

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

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

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

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

حدّد مواعيد نهائية تتوافق مع العمل

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

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

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

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

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

قد تعمل سياسة بسيطة على النحو التالي:

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

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

خطط للإشعارات من دون إحداث ضوضاء

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

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

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

اجعل الرسائل بسيطة ومحددة. اذكر الطلب وحالته الحالية واشرح ما سيحدث بعد ذلك. مثلًا:

• العميل: «تلقينا طلب المعدات رقم 1842. سنراجعه بحلول يوم الثلاثاء.»
• المراجع: «يحتاج الطلب رقم 1842 إلى موافقتك قبل يوم الثلاثاء الساعة 3 مساءً.»
• العميل: «تمت الموافقة على طلبك رقم 1842. سيحدد فريقنا موعد التسليم ويحدّثك بحلول يوم الجمعة.»

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

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

تتبّع طلب عميل بسيطًا

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

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

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

بعد رد العميل، يعود الطلب إلى «قيد المراجعة» ويعود إلى الموظف نفسه إن أمكن. فالاستمرارية مهمة، لأن الموظف الجديد لا ينبغي أن يكرر الأسئلة نفسها.

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

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

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

تمنع هذه الخريطة فجوة شائعة: ظهور الطلب مكتملًا على شاشة، بينما لا يزال ينتظر إجراءً في قائمة انتظار فريق آخر.

أخطاء شائعة تربك سير العمل

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

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

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

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

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

قبل تصميم الشاشات، اختبر كل جزء من دورة الحياة بأربعة أسئلة:

• ماذا تعني هذه الحالة تحديدًا؟
• من يملك الطلب أثناء وجوده هنا؟
• ما الحدث الذي ينقله إلى الحالة التالية؟
• ماذا يحدث إذا انقضى الموعد النهائي؟

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

أجرِ فحصًا سريعًا قبل تصميم الشاشات

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

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

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

استخدم قائمة المراجعة التالية:

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

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

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

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

حوّل الخريطة إلى تطبيق

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

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

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

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

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

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

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