الخدمات · 02

أنظمة الأعمال

نظام واحد للعملاء والطلبات وكل ما بينهما من عمل

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

اربطوا ما تستخدمونه أصلًا. ولا تبنوا إلا ما لا يُباع جاهزًا.

معظم الشركات التي نلتقيها تملك أصلًا كل الأدوات التي تحتاجها: نظامًا للفوترة، ومتجرًا على Shopify أو Amazon، وWhatsApp للطلبات، وجدول بيانات للمخزون، وTally للحسابات. المشكلة أن أيًّا منها لا يتحدث مع الآخر. أحدهم يكتب الطلب نفسه ثلاث مرات، وجدول المخزون يصبح خاطئًا قبل الظهر، والمالك يعرف ما حدث أمس من مكالمة هاتفية.

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

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

لمن تناسب

  • استفسارات تصل إلى أربعة أماكن وتُتابَع من الذاكرة
  • طلبات تأتي من أماكن أكثر مما يستطيع الفريق إعادة إدخاله
  • برمجيات تجاوزها العمل، أو لم تناسبه يومًا

ما تحصلون عليه

  • برمجيات تعمل، يتدرّب عليها فريقكم ونحن معه في المكان
  • سجل واحد لكل عميل ولكل طلب، من أول استفسار حتى الإغلاق
  • سجل قرارات مكتوب واختبارات يستطيع المهندس التالي أن يكمل منها
  • مذكرة أسبوعية بلغة بسيطة: ما بُني، وما تقرّر، ولماذا
كيف يسير العمل

أربع بوابات. توافقون على كل واحدة قبل أن تبدأ التالية.

البوابات الأربع نفسها في كل مشروع، كما تبدو في هذا العمل.

التشخيص

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

الإثبات

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

البناء

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

التسليم

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

دراسة حالة

كل العملاء المحتملين في مسار مبيعات واحد، من استفسار المنصة حتى الحجز.

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

تحويل الطلب إلى مبيعات · العقارات · بونه
45‎%‎ثم96‎%‎

العملاء المحتملون الذين سُجّل أول رد عليهم خلال يوم

من كل العملاء المحتملين القادمين من منصة عقارية أو وسيط أو زيارة مباشرة

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

ما يسأله أصحاب الأعمال قبل أن يتصلوا.

هل يمكن ربط Tally وShopify وWhatsApp دون إعادة إدخال؟

نعم، وهذا معظم العمل. تحتفظ كل أداة بدورها: Shopify يستقبل الطلب، وTally يمسك الحسابات، وWhatsApp هو حيث يتحدث العميل. ما يتغير أن الطلب المسجَّل في إحداها يظهر في الأخرى دون أن يكتبه أحد من جديد، ويتحرك رقم المخزون معه. وحيث لا يكون للأداة منفذ مناسب (مورّد لا يرسل إلا فواتير PDF، أو منصة بيع لا تصدّر إلا جدولًا)، تتولى خطوة قراءة صغيرة الإدخال بدلًا من الإنسان. وأول ما نتفق عليه قائمة بما يجب ألّا يُعاد إدخاله أبدًا، وعدد ما لا يزال يُعاد إدخاله منها، مقيسًا قبل البناء وبعده.

هل نتخلّص من نظام ERP الذي دفعنا ثمنه؟

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

يأتينا العملاء المحتملون من المنصات والوسطاء والزيارات المباشرة. هل يمكن لنظام واحد أن يجمعهم كلهم؟

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

ماذا تعرض فعلًا شاشة المالك الواحدة؟

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

هل سيضطر موظفونا إلى تعلّم برمجيات جديدة؟

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

ماذا يحدث حين تتغير أداة مربوطة أو تتعطل؟

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

لمستشاركم التقني

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

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

التقنيات TypeScript · Python · PostgreSQL · REST وwebhooks · Tally · Zoho · Shopify

اقرأوا أيضًا

هل تستبدلون برمجياتكم أم تربطونها؟

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

البداية

اكتبوا فقرة. يردّ عليكم أحد المؤسسين خلال يوم عمل واحد.

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

أو عبر البريد الإلكتروني أو الهاتف أو WhatsApp: hello@netogrit.com · +91 94330 54299 · WhatsApp (يُفتح في علامة تبويب جديدة)