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