يطلب مطبخ مطعم من عملاء قناة هوريكا (HoReCa) في الرياض الأصناف نفسها تقريبًا من موزّعه كل أسبوع — ألبان، ومواد غذائية معبأة، وبروتينات معبأة، بالكميات نفسها مع فارق بسيط من دورة تسليم إلى أخرى. لا شيء معقّد في هذا الطلب. المكلف هو أن المشتري أو منسق الطلبات، في قناة طلب تعمل بالهاتف وواتساب، يعيد بناءه من الذاكرة كل أسبوع، والقائمة التي تُبنى من الذاكرة قائمة يسقط منها صنف بين حين وآخر.
كل إعادة طلب تبدأ من الصفر في القناة اليدوية
رسالة واتساب الصوتية أو المكالمة الهاتفية لا تتذكر طلب الأسبوع الماضي. فإما أن يحتفظ المشتري بملاحظة خاصة به — مذكرة على الهاتف، أو ورقة ملصقة داخل خزانة — وإما أن يعتمد على المنسق ليتذكر ما يطلبه هذا المطبخ بعينه كل ثلاثاء. لا شيء من الاثنين نظام. وكلاهما يضعف لحظة غياب الشخص المعتاد: الموظف الذي يتولى الطلب لدى المشتري في إجازة، أو المنسق المسؤول عن الحساب غائب وزميل يغطي حساباته دون معرفة سابقة بها.
التكلفة هنا ليست أن الطلب يخرج خاطئًا بشكل لافت. بل إن إعادة بناء طلب معروف وصحيح من الذاكرة تستهلك دقائق حقيقية كل أسبوع، وكل إعادة بناء فرصة لإسقاط صنف، أو الخطأ في كمية، أو الاكتفاء بما يسهل تذكره بدلًا مما يحتاجه المطبخ فعلًا ذلك الأسبوع. والجهد الذي يكلّفه الطلب كل أسبوع جزء من علاقة المشتري بالموزّع، حتى إن لم يظهر في أي تقرير.
المسودة وإعادة الطلب تعالجان لحظتين مختلفتين
تتعامل بوابة المشتري من إمداد مع هاتين الحالتين على أنهما إجراءان مترابطان لكن منفصلان، لا ميزة واحدة باسمين. المسودة سلة بدأها المشتري ولم يُكملها — استُدعي في منتصف الوردية، أو أراد التحقق من مستويات المخزون قبل الالتزام — فتُحفظ ليعود إليها لاحقًا دون أن يبدأ من جديد. أما إعادة الطلب فمختلفة: تأخذ طلبًا مكتملًا من سجل الطلبات لدى المشتري وتعيد بناءه سلة جديدة، للمشتري الذي يريد تكرار نمط ثابت لا استئناف طلب انقطع.
كلاهما يرفع العبء نفسه — إعادة كتابة قائمة معروفة — في النقطتين اللتين يظهر فيهما فعلًا خلال أسبوع المشتري: الطلب الذي انقطع، والأسبوع المعتاد الذي يشبه سابقه.
لماذا لا تنقل أيٌّ منهما السعر
المسودة المحفوظة أو إعادة الطلب تخزّن الصنف والكمية فقط. ولا تخزّن سعرًا أبدًا، لأن صافي السعر ناتج طبقات التسعير الخمس، يُحتسب من جديد في كل مرة — قائمة السعر الأساسية، والتجاوز التعاقدي، وشريحة حجم المبيعات، وتجاوز العرض الترويجي، والتجاوز اليدوي للعميل — وأي طبقة منها قد تكون تغيّرت بين وقت إرسال الطلب ووقت فتح المشتري للمسودة أو تكراره للطلب. السعر المحفوظ في مسودة رقم قديم يتظاهر بأنه حالي.
لنفترض أن الطلب المعتاد لمطبخ الرياض بقي مسودة خلال عطلة نهاية الأسبوع، وأن تجاوزًا ترويجيًا على أحد أصناف الألبان انتهى صباح الاثنين. يفتح المشتري المسودة بعد ظهر الاثنين، فتوضع علامة بلون مختلف على البند مع ذكر السبب — انتهاء العرض الترويجي — قبل إتمام الطلب، تمامًا كما يحدث لو تغيّر السعر في سلة جديدة أثناء بنائها. لا شيء مخفي ولا شيء تخميني؛ يُحتسب السعر من جديد وفق القواعد السارية لحظة نظر المشتري إليه، لا لحظة بنائه القائمة أول مرة.
المسودة تتذكر ما يريد المشتري طلبه. ولا تدّعي أبدًا أنها تتذكر كم سيكلّفه.
السلة المُعاد بناؤها تمر عبر السلة، لا من حولها
إعادة استخدام أصناف طلب سابق وكمياته اختصار في الكتابة، لا اختصار في التحقق. السلة المُعاد طلبها أو المستأنفة تُفحص مقابل قواعد الحد الأدنى للطلب (MOQ) والتعبئة ومضاعفات الطلب نفسها التي تُفحص بها أي سلة أخرى، ومقابل الكمية المتاحة للطلب (ATP) المحدَّثة خلال 60 ثانية، ومقابل التعرض الائتماني للحساب المحدَّث خلال 5 دقائق — النسخة المتزامنة باستمرار نفسها من نظام الـERP التي يُفحص بها كل طلب عند إرساله. وإن نفد مخزون صنف طلبه المطبخ الشهر الماضي، أو تغيّر حجم كرتونته منذ آخر تسليم، يرى المشتري ذلك عند السلة، قبل إرسال الطلب، لا بندًا ناقصًا يُكتشف عند رصيف التحميل.
ويستطيع المشتري أيضًا تعديل الطلب أو إلغاءه ما دام لم يُفرَج عنه للمستودع بعد، شأنه شأن أي طلب — فالسلة المُعاد بناؤها ليست التزامًا مقفلًا لحظة إنشائها، بل نقطة بداية يؤكدها المشتري أو يعدّلها. وهذا ما يجعل إعادة الطلب بنقرة واحدة آمنة، لا شيئًا على المشتري مراجعته بندًا بندًا: التحقق ما زال يحدث، لكن تلقائيًا عند إرسال الطلب، بدلًا من أن يعيد المشتري التحقق من المخزون والأسعار من الذاكرة كما يتطلب الطلب اليدوي.
100% من الطلبات يتم التحقق منها قبل الإرسال — التسعير والكمية المتاحة للطلب والائتمان وقواعد التعبئة تُفحص عند إرسال الطلب — سواء بُنيت السلة من جديد أو أُعيد بناؤها من مسودة أو من سجل الطلبات.
احتفاظ بالمشترين يعيش في المنصة، لا في ذاكرة منسق واحد
في قناة يديرها منسقو الطلبات، ترتبط سهولة إعادة الطلب لدى المشتري بذاكرة شخص بعينه عن ذلك الحساب — مدى معرفة المنسق بقائمة هذا المطبخ المعتادة، ومدة إدارته للعلاقة، وما إذا كان على مكتبه هذا الأسبوع. وهذا مكان هش للاحتفاظ بميزة تحافظ على المشتري: تختفي يوم ينتقل المنسق إلى مجموعة حسابات أخرى، ولم تكن يومًا شيئًا يستطيع الموزّع رؤيته أو إدارته مباشرة.
نقل هذه السهولة نفسها إلى بنية طلب منظمة لا يغيّر ما يريده المشتري — قائمة الأسبوع نفسها، بجهد أقل — بل يغيّر المكان الذي تُحفظ فيه. المسودة المحفوظة وسجل الطلبات يرتبطان بالحساب، لا بذاكرة موظف واحد، ومتاحان بالطريقة نفسها أيًّا كان من يغطي علاقة هذا المشتري هذا الأسبوع. وبالنسبة إلى موزّع يرى وتيرة الطلب تتراجع لأسباب لا يستطيع أحد تسميتها بدقة، فإن السؤال الأول الصادق ليس ما إذا كان المشترون ما زالوا يريدون الطلب، بل كم يكلّفهم الطلب من جهد اليوم، وكم من هذه التكلفة متبقٍّ من إعادة بناء طلب كان النظام يعرفه أصلًا، كل أسبوع.