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

نظرة عامة

بنينا لهم نظامًا، ثم أتمتنا مهامه اليدوية.

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

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

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

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

التحديات

ثماني مشكلات، ستّ منها مهام كان الموظفون يؤدونها يدويًا.

شركة شحن تعتمد على جداول البيانات

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

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

إنشاء كل عنوان أمريكي يدويًا

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

طرود تصل باسم غير صحيح

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

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

العميل لا يعرف كم سيدفع

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

إدخال كل طلب شحن مرتين

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

فاتورة واحدة تستغرق يوم عمل

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

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

لم يكن أحد قد وثّق قواعد هذه الحسابات. وكان علينا أن نفهمها أولًا حتى نتمكن من أتمتتها.

موعد نهائي لم تحدده الشركة

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

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

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

حين تكون سجلات الشريك خاطئة

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

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

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

2024 – 2025 · واجهة API الجديدة للشريك

العام الذي استبدل فيه الشريك واجهة API

في 2024، أبلغنا شريك المستودع الأمريكي بأنه سيستبدل واجهة API الخاصة به، وسيوقف الواجهة القديمة في نهاية العام.

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

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

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

بنينا بنية البيانات الجديدة إلى جانب القديمة.

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

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

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

ثم نقلنا التطبيق، شاشةً بعد شاشة.

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

ثلاث نتائج ما زالت تفيد المنصة اليوم

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

ما بنيناه

ثماني سنوات من البناء، بأتمتة مهمة يدوية تلو الأخرى.

الفصل الأول · 2018 · سجل واحد لكل عنصر

نقل أعمال الشركة من جداول البيانات

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

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

الفصل الثاني · دون تدخل الموظفين

عناوين أمريكية دون تدخل الموظفين

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

الفصل الثالث · 2021 – 2023 · ثلاث مراحل لاستقبال الطرود

ربط الطرود بأصحابها تلقائيًا

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

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

الفصل الرابع · تبادل البيانات في الاتجاهين

أسعار فورية للعملاء، وطلبات شحن تُرسل إلى الشريك تلقائيًا

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

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

الفصل الخامس · 2023 · انتقال دون تغيير ظاهر

تطبيق Laravel يعتمد على قاعدة البيانات نفسها

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

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

الفصل السادس · 2024 – 2025 · واجهة API جديدة وبنية بيانات جديدة

الشريك يستبدل واجهة API

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

الفصل السابع · من 2025 حتى اليوم · صيانة مستمرة للتطبيقين · مستمر

أخطاء الشريك والامتثال والمدفوعات

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

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

طوال هذه المراحل

ما بقي كما هو

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

الفاتورة

إعداد الفاتورة، من يوم عمل إلى أقل من دقيقة.

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

ما الذي يفعله زر الفاتورة؟

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

تفاصيل تقنية · شريك المستودع الأمريكي

كيف يعمل التكامل في الاتجاهين مع شريك المستودع الأمريكي

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

كان القرار الأساسي هو الاحتفاظ بنسختنا الخاصة من بيانات الشريك.

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

الرسائل الواردة

ثمانية أنواع من الرسائل، في أي وقت وبأي ترتيب.

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

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

المطابقة

رقم الجناح يحدد صاحب كل طرد.

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

طلبات الشحن الصادرة

يمر إرسال طلب الشحن بعدة خطوات.

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

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

حين اختلفت سجلات الشريك عن سجلاتنا، أضفنا ثلاث آليات للتحقق

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

كيف نعمل

تسع قواعد، طبّقنا كلًا منها على هذه المنصة.

أتمتة مهمة يدوية تلو الأخرى

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

إعادة البناء مع استمرار النظام في العمل

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

لا تخمين في بيانات العملاء

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

توثيق القواعد قبل أتمتتها

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

الاحتفاظ بسجلاتنا وبنسخة مستقلة من بيانات الشريك

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

الاستعداد لتغييرات الشركاء

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

قياس نتائج الأتمتة

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

معالجة السبب

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

ما زلنا نتولى التشغيل

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

التقنيات المستخدمة

تسع طبقات، ووظيفة كل منها.

التطبيق

يعتمد التطبيق الأحدث على Laravel، وهو إطار واسع الاستخدام، مما يتيح لمطوّرين آخرين تولّي العمل عليه.

• PHP 8
• Laravel 10

واجهة المستخدم

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

• Blade
• Vue 3
• Inertia
• Tailwind
• Vite

البيانات

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

• MySQL
• Redis

المهام في الخلفية

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

• Laravel Horizon
• 15 مهمة في طابور المهام
• 29 إجراءً مجدولًا

المستودع وشركات النقل

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

• واجهة API لشريك المستودع في الاتجاهين
• واجهتا API للتتبّع لدى شركتَي شحن سريع

المدفوعات

لا توجد جهة واحدة لمعالجة مدفوعات البطاقات تخدم جميع عملاء هذا السوق.

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

المراسلة والتسويق

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

• واجهة API لمراسلات الأعمال
• روبوت لتطبيق محادثة
• رسائل البريد الإلكتروني التلقائية
• إشعارات فورية في المتصفح
• منصتان لمحادثات الفريق
• منصة للتسويق بالبريد الإلكتروني

المستندات والتخزين

تحفظ هذه الأدوات الفواتير، وصور الطرود، ورسائل الشريك المؤرشفة، وملفات جداول البيانات المصدّرة.

• فواتير PDF
• خدمتان لتخزين الكائنات السحابي
• استيراد ملفات CSV وتصديرها

هندسة البرمجيات

تؤرشف المنصة كل طلب واستجابة بيننا وبين الشريك، ونختبر كل إصدار في بيئة ما قبل الإنتاج أولًا.

• Git
• بيئة ما قبل الإنتاج
• تسجيل منظّم لطلبات API واستجاباتها
• Laravel Pint
• Clockwork
• حماية النماذج العامة من الروبوتات

الاختبارات الآلية

تتحقق الاختبارات الآلية من كل تغيير قبل وصوله إلى بيئة الإنتاج.

التكاملات ووظيفة كل منها

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

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

كيف تعمل المنصة

سبع خطوات، من نموذج التسجيل إلى استلام الشحنة.

الخطوة 1

سجّل واحصل على عنوان أمريكي

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

الخطوة 2

تسوّق، ودع المنصة تحدد صاحب كل طرد

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

الخطوة 3

استكمل المستندات، أو واصل الشحن دون انتظار

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

الخطوة 4

شاهد السعر يتغيّر فورًا

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

الخطوة 5

إرسال الطلب إلى الشريك

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

الخطوة 6

التحقق والتخزين وإصدار الفاتورة

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

الخطوة 7

استلم شحنتك وتابع تحديثاتها الدقيقة

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

إجراءات تعمل دون متابعة بشرية

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

ثلاثة أنشطة تجارية على منصة واحدة.

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

النتائج

ما تستطيع الشركة إنجازه الآن ولم يكن متاحًا لها في 2018.

العمل دون جداول بيانات

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

توفير عنوان أمريكي لكل عميل دون إدخال يدوي

يملأ العميل نموذجًا، ويتلقى عنوانًا أمريكيًا ورقم جناح بالبريد الإلكتروني خلال ثوانٍ.

ربط الطرود بأصحابها تلقائيًا

لم يعد الموظفون يستوردون جداول البيانات أو يقرؤون الملصقات لتخمين صاحب الصندوق، حتى حين يختلف الاسم عليه عن اسم الحساب.

عرض السعر للعميل قبل تأكيد الطلب

يُحدَّث السعر فورًا لكل سرعة شحن، ويشمل الرسوم الجمركية، مع عرض التكلفة وتاريخ الوصول جنبًا إلى جنب.

إرسال طلبات الشحن إلى المستودع دون إعادة إدخالها

تنشئ المنصة كل طلب مرة واحدة وترسله عبر واجهة API، وتتابع حالات الفشل وتسجّل المشكلات التي يبلّغ عنها الشريك.

إصدار الفاتورة في أقل من دقيقة بدلًا من يوم عمل

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

مواصلة العمل حين استبدل أكبر شركائها واجهة API

قدّم الشريك واجهة API جديدة بنموذج بيانات مختلف وموعد نهائي. فأعدنا بناء نموذج البيانات ليتوافق معها، ولم تفقد الشركة أي يوم عمل.

اكتشاف أخطاء الشريك قبل العملاء

تقارن المنصة الطرود الواصلة بالمطلوبة، وتتحقق من أحدث حالة للطرد لدى الشريك قبل السماح بشحنه، وتستبعد الطلبات العالقة.

تحصيل رسوم لم تكن تُحتسب

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

تشغيل ثلاثة أنشطة تجارية على منصة واحدة

للشحن الجوي، والشحن البحري، والعلامة التجارية الثانية لإعادة توجيه الطرود عملاء وبيانات مستقلة لكل منها.

العمل الهندسي بالأرقام

• 8 سنوات من التطوير والتشغيل المتواصلين
• 0 دقائق توقف الخدمة أثناء إعادة بناء نموذج البيانات
• نحو 5 أشهر عملت فيها بنيتا البيانات القديمة والجديدة جنبًا إلى جنب
• 69 جزءًا من الكود أعدنا بناءه لبنية البيانات الجديدة
• 3 مراحل لاستقبال الطرود: جداول بيانات، ثم إشعارات فورية، ثم إسناد تلقائي
• 8 أنواع من رسائل الشريك الواردة تعالجها المنصة
• 23 بندًا من الرسوم والتكاليف والخصومات يجمعها زر الفاتورة
• أقل من دقيقة لإعداد فاتورة واحدة بدلًا من يوم عمل · بحسب العميل
• 81 نوعًا من السجلات يحفظها النظام
• 165 تغييرًا في قاعدة البيانات طبّقناه دون انقطاع الخدمة
• 29 / 15 إجراءً مجدولًا / مهمة في طابور المهام
• 13 خدمة خارجية مرتبطة بالمنصة
• 39 قالبًا لرسائل البريد الإلكتروني التلقائية
• 1,722 تغييرًا مسجّلًا في الكود عبر التطبيقين
• نحو 127,000 سطر من كود التطبيق

الوضع الحالي كما هو

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

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

المهام التي حلّت الأتمتة محلها

ثماني مهام كان الموظفون يؤدونها يدويًا، وكيف تُنجز الآن.

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

أعمال ذات صلة

جميع الأعمال

الخطوة التالية

هل ما زال جزء من أعمالك يعتمد على جداول البيانات؟

اعمل مع فريق يؤتمت مهامك اليدوية واحدة تلو الأخرى، ويحافظ على استمرار أعمالك حين يغيّر شريك واجهة API الخاصة به، ويواصل تشغيل ما يبنيه.

احجز مكالمة استكشافية