منتج داخليتوصيل بالاشتراك
توصيلات اشتراك تجدول نفسها وتوزّع مساراتها وتصدر فواتيرها
نشاط توصيل متكرر يقع عبؤه التشغيلي لا في التوصيل نفسه بل في الحساب المحيط به — من يستلم ماذا اليوم، ومن أوقف اشتراكه، ومن عليه مستحقات، وما الذي يتغير حين يتخطى عميل أسبوعًا.
من نفّذ هذا العملبُني ويُشغَّل داخليًا من فريقنا. معروض هنا ببيانات توضيحية.
النتيجة
2
بوابتان — للعميل وللتشغيل — من قاعدة شفرة واحدة
التقنيات والتخصصات
- Next.js
- React
- Express
- MySQL
- مصادقة JWT
- مهام مجدولة

الوضع القائم
يبدو التوصيل المتكرر بسيطًا حتى تكتب قواعده. عميل يأخذ لترين يوميًا، وآخر ثلاثة لترات يومًا بعد يوم، وثالث يوقف اشتراكه أسبوعين ويتوقع أن تعكس الفاتورة ذلك. وعلى أحدهم أن يقرر كل صباح ما الذي يخرج من المستودع وعلى أي مسار، ثم يطابق ما سُلِّم فعلًا مع ما يُحتسب. وهذا العمل يدويًا يتوسع بصعوبة ويزداد كلفة في اللحظة نفسها التي ينمو فيها النشاط.
ما الذي فعلناه
جعلنا الاشتراك نفسه مصدر الحقيقة — الكمية والتكرار وأيام الأسبوع المحددة التي يعمل فيها — فقائمة التوصيل اليومية مشتقة لا مكتوبة.
نولّد توصيلات كل يوم عبر مهمة مجدولة تعمل قبل بدء اليوم، فيفتح فريق التشغيل صباحه والجولة جاهزة.
جعلنا سجل التوصيل هو سجل الفوترة، فالتسليم الفائت يخفض الفاتورة دون أن يتذكر أحد تعديلها.
بنينا بوابة العميل وبوابة التشغيل من قاعدة شفرة واحدة، فلا يعني تغيير طريقة عمل الخطة إجابتين مختلفتين في مكانين مختلفين.
أبقينا كل رصيد مشتقًا من الحركات لا مخزّنًا كرقم، فأي فاتورة محل خلاف يمكن تتبعها رجوعًا إلى التوصيلات التي وراءها.
النتيجة
- جولات توصيل يومية تُولَّد تلقائيًا من الخطط النشطة، دون بناء قوائم يدويًا.
- توصيلات فائتة ومكتملة تغذي الفوترة مباشرة، فما يُحتسب يطابق ما سُلِّم.
- تجربتا العميل والتشغيل تُشحنان من قاعدة شفرة واحدة ومجموعة قواعد واحدة.
ما يتطلبه الدخل المتكرر فعلًا
تفشل أعمال الاشتراكات على الحساب أكثر بكثير مما تفشل على الطلب. والجزء الصعب أن كل استثناء — إيقاف، أو تخطٍّ، أو تغيير كمية في منتصف الشهر — يجب أن يسري عبر الجدولة والفوترة دون أن يتذكر إنسانٌ إجراءه.
نبني هذه الأنظمة بحيث يكون الاستثناء حالة أصيلة لا تصحيحًا يدويًا، وهو الفارق بين منتج يتوسع وآخر يحتاج بهدوء إلى موظف إداري إضافي.
تابع القراءة
أعمال أخرى
≈1.3×كفاءة تشغيلية بعد الإطلاق
ساغاوا إكسبرس. كانت طلبات الاستلام لدى شركة شحن وطنية تصل عبر الهاتف وتُتابع في جداول بيانات. صمّم فريقنا منصة الحجز الإلكترونية وتطبيق السائق اللذين حلّا محلهما.
48,000+موقف سيارات تُدار على المنصة
توكاب. منتج حجز يغطي عشرات الآلاف من مواقف السيارات على مستوى البلاد، وكانت مشكلة التصميم فيه هي الكثافة — إيجاد موقف واحد صالح بسرعة، على الهاتف، وفي عجلة من الأمر.
≈1مليون طلب يوميًا تعالجه خدمات Go
منتج منصة كخدمة، دبي. واجهة خلفية أساسية وخدمات مصغرة وفوترة وأدوات داخلية أتاحت لفريق هندسي كامل تشغيل منظومة الإنتاج محليًا — إلى جانب خدمات بلغة Go في موضع آخر تعالج نحو مليون طلب يوميًا.
5قنوات بيع في طابور طلبات واحد
منتج داخلي. متجر بقالة يبيع عبر خمس قنوات في آنٍ واحد، وكانت التكلفة الحقيقية ليست في البيع بل في التسوية الليلية بين درج النقد وجدول بيانات وهاتف ومتجر إلكتروني لا تتفق أرقامها أبدًا.
6خطوط خدمة، لكلٍّ منها صفحته
شركة إدارة مرافق. مشتروها فرق توريد تقارن بين المورّدين على الورق، فكان على الموقع أن يقدّم حجة المورّد الواحد بنفسه — ثم يجعل تقديم الطلب بلا عناء.
3ممارسات تحت لوحة إدارة مخصصة واحدة
وكالة تجارة إلكترونية. ثلاث ممارسات متمايزة وكتالوج خدمات أكبر من أن يحتمله موقع ثابت، وكان المطلوب أن يعيد العميل هيكلة عرضه دون مطوّر.
أخبرنا بما تريد بناءه.
مكالمة مدتها 30 دقيقة مع الأشخاص الذين سينفذون العمل بأنفسهم — لا فريق مبيعات. وسنخبرك بصراحة إن كنا الفريق المناسب لمشروعك أم لا.
- في المكالمة
- أهدافك، وما هو قائم اليوم، والخطوات الأولى. دون مدير حسابات بيننا.
- بعد المكالمة
- نطاق عمل مكتوب وسعر خلال أيام — أو إجابة صريحة بأننا لسنا الفريق المناسب.
- دون أي التزام
- لا شيء يُلزمك قبل توقيع نطاق العمل، وكل ما نرسله إليك يبقى ملكًا لك.
نرد على كل استفسار خلال يوم عمل واحد. تفضّل البريد الإلكتروني؟ info@sparqweb.com