مخطط CRM خفيف للفرق الصغيرة يبقى بسيطًا

المشكلة التي يجب أن يحلها هذا المخطط

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

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

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

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

• Contacts (وبشكل اختياري Organizations) كالأشخاص الذين تتحدث إليهم
• Deals كالفرص التي تتبعها خلال خط الأنابيب
• Activities كسجل موحّد للمهام والاجتماعات والمكالمات والملاحظات
• Permissions كقواعد عملية لمن يمكنه رؤية وتحرير ماذا

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

إذا كنت تبني CRM داخليًا في أداة no-code مثل AppMaster (appmaster.io)، يحافظ هذا النهج على قاعدة البيانات صغيرة مع منحك أرقامًا مستقرة للوحة التحكم والمراجعات الأسبوعية.

مبادئ البقاء خفيفًا دون تقييد نفسك

يعمل مخطط CRM الخفيف عندما يجيب بوضوح على سؤال واحد: أين يعيش هذا الواقع؟ إذا يمكن تخزين نفس "الحقيقة" في مكانين، فستُخزن، وستنحرف تقاريرك.

اختر مجموعة صغيرة من كائنات مصدر الحقيقة واجعل كل شيء آخر يشير إليها. بالنسبة لمعظم الفرق الصغيرة، هذا يعني Contacts، Organizations (اختياري)، Deals، و Activities. عندما تحتاج مزيدًا من التفاصيل، أضف جدولًا جديدًا بدلًا من حشر المعاني في حقل نصّي واحد يتحول إلى درج مهملات.

قواعد قليلة تحافظ على البساطة والمرونة:

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

خطط للبيانات الفوضوية منذ اليوم الأول بإضافة حقول مملة لكنها قوية: created_at، updated_at، وexternal_id بسيط (أو import_source + import_key) على الجداول الأساسية. هذا يمنحك طريقة آمنة لإعادة الاستيراد دون إنشاء تكرارات.

مثال ملموس: تستورد جدولًا تظهر فيه "Acme Inc." كـ "ACME" في نصف الصفوف. إذا كان Organization.name قابلًا للتعديل وOrganization.id ثابتًا، يمكنك دمج السجلات لاحقًا دون كسر الصفقات والأنشطة الموجودة.

Contacts و Organizations: أبسط بنية تعمل

يبدأ مخطط CRM الخفيف بقرار واحد: هل تتعقّب الأشخاص فقط، أم الأشخاص بالإضافة إلى الشركات؟ إذا كان فريقك يبيع للأعمال، فعادةً ما تريد كلا من Contact (شخص) و Organization (شركة). إذا كنت تبيع للمستهلكين، يمكنك تخطي Organizations تمامًا والاحتفاظ بكل سجل كـ contact.

لإعداد B2B، اجعل العلاقة بسيطة: كل contact ينتمي إلى منظمة رئيسية واحدة (قابلة لأن تكون فارغة)، والمنظمة يمكن أن تحتوي على عدة جهات اتصال. هذا يغطي معظم سير العمل للفرق الصغيرة دون دفعك إلى هياكل حسابية معقّدة.

اجعل الحقول المطلوبة حدّية

أسرع طريق للفوضى هو جعل عدد كبير من الحقول إجباريًا. قاعدة جيدة:

• Contact: id، الاسم (أو first_name + last_name)، created_at
• Organization: id، name، created_at

كل شيء آخر (المسمى الوظيفي، الموقع، العنوان، الصناعة، المصدر) يمكن أن يكون اختياريًا. يمكنك إضافة قواعد لاحقًا، لكن من الصعب تنظيف قاعدة بيانات مليئة بالقيم النائبة مثل "N/A".

البريد الإلكتروني والهاتف: التفرد بدون إزعاج

من المغري جعل البريد الإلكتروني فريدًا. هذا يعمل جيدًا لـ B2C، أو CRM يعمل كنظام تسجيل دخول. في فرق B2B الصغيرة، صناديق البريد المشتركة (sales@، info@) وأرقام الهواتف المعاد استخدامها شائعة. قواعد التفرد الصارمة يمكن أن تمنع سجلات صحيحة.

حل عملي:

• فرض التفرد فقط عندما تكون القيمة موجودة (وفقط إذا كانت تناسب حالة الاستخدام لديك).
• السماح بالتكرارات، لكن إظهار تحذير ناعم في الواجهة عند العثور على تطابق.

إذا احتجت عدة عناوين بريد أو أرقام، تجنّب إضافة أعمدة مثل email_2 أو phone_3. استخدم جدولًا منفصلًا بدلًا من ذلك (مثلاً ContactMethod مع type، value، is_primary). تبقى التقارير نظيفة والنموذج يتوسع طبيعيًا.

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

Deals وخط الأنابيب: بنية قابلة للقراءة

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

ابدأ بالحقول التي يمكنك شرحها لأي شخص في الفريق:

• اسم الصفقة: تسمية قصيرة مفهومة في القوائم
• المرحلة: مرجع إلى مرحلة في خط أنابيب (لا تكتبها يدويًا)
• القيمة: المبلغ المتوقع (واختر عملة واحدة للنظام كله)
• المالك: الشخص المسؤول عن تحريكها إلى الأمام
• تاريخ الإغلاق: أفضل تقدير حالي لمتى ستغلق

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

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

• stage_id
• pipeline_id
• stage_name
• stage_order
• is_closed (أو أعلام منفصلة للفوز والخسارة)

إذا كان فريقك صغيرًا، تجنّب تقسيم السجلات إلى "lead" و "deal" إلا إذا كنت فعلاً تدير العملاء المحتملين بشكل مختلف. قاعدة بسيطة: عندما يكون لديك فرصة حقيقية تستحق التتبع، فهي صفقة. قبل ذلك، احتفظ بها كـ contact بحالة مثل "new" أو "nurture". هذا يبقي خط الأنابيب قابلًا للقراءة ويمنع الصفقات نصف المُنشأة من تلويث أرقامك.

مثال: فريق مبيعات مكوّن من شخصين يتتبع "Acme Renewal" كصفقة مملوكة لSam، المرحلة "Proposal Sent"، القيمة 12,000، وتاريخ الإغلاق الشهر القادم. جهة الاتصال الأساسية هي المشتري، ويُضاف مشارك ثانٍ كموافق مالي. تظل التقارير متسقة لأن أسماء المراحل وترتيبها ثابت.

الأنشطة: نموذج واحد للمهام والاجتماعات والملاحظات

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

جدول Activity واحد

استخدم صفًا واحدًا لكل حدث حدث (أو يجب أن يحدث). امنحه حقل type بسيطًا مع مجموعة ثابتة صغيرة، مثل: call، email، meeting، note، task. اجعل القائمة قصيرة حتى يختار الناس نفس الكلمات في كل مرة.

للربط بدون لبس، استخدم قواعد واضحة:

• إذا كان الأمر يخص شخصًا (مكالمة متابعة، بريد تقديمي)، اربطه بـ contact.
• إذا كان يخص تحريك الإيرادات (مكالمة تسعير، اجتماع تفاوض)، اربطه بـ deal.
• إذا شمل كلاهما فعلاً، اربط بهما معًا، لكن اعتبر الصفقة أساسية لتقارير خط الأنابيب.

عمليًا، يمكن أن يحتوي Activity على contact_id (قابل أن يكون فارغًا) و deal_id (قابل أن يكون فارغًا)، بالإضافة إلى owner_id اختياري (من المسؤول).

طوابع زمنية مناسبة للتقارير

احتفظ بكل من due_at و completed_at. كلٌ منهما يجيب عن أسئلة مختلفة. due_at يخبرك بما كان يجب أن يحدث (التخطيط وحجم العمل). completed_at يخبرك بما حدث فعلاً (التنفيذ وزمن الدورة).

يمكنك استنتاج الحالة دون حقل منفصل: إذا كان completed_at معبأً، فهو منجز. إذا لم يكن كذلك، فهو مفتوح. هذا يتجنّب قيم حالة إضافية التي تهيم.

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

الملكية والرؤية: اجعلها عملية

الملكية هي من هو مسؤول عن الخطوة التالية. في مخطط CRM الخفيف، هذا عادةً يعني حقلًا مثل owner_user_id على الصفقة (وغالبًا على جهات الاتصال أيضًا).

معنيان لـ "المالك" غالبًا ما يختلطان: تعيين مستخدم (شخص محدد) و تعيين فريق (مجموعة). إذا حاولت جعل كل شيء مملوكًا للفِرَق منذ اليوم الأول، تفقد الوضوح حول من يجب أن يتصرف اليوم.

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

عندما تحتاج رؤية أكثر صرامة، اجعلها كمفتاح واحد، ليس مصفوفة معقدة. على سبيل المثال، أضف حقل visibility في الصفقات والأنشطة بقيم مثل public و private، حيث يعني private "فقط المالك (والمسؤولون) يمكنهم رؤيته."

تحتاج للفرق أو المناطق فقط عندما يكون أحد هذه صحيحًا:

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

الملكية تؤثر على التقارير. إذا أردت أرقامًا نظيفة "حسب المندوب"، أبلغ بتقريرك حسب owner_user_id الحالي على الصفقة. إذا أردت أيضًا تجميعات "حسب الفريق"، أضف owner_team_id (أو استخلصه من ملف المالك)، لكن كن صريحًا بشأن أيهما مصدر الحقيقة.

مثال: اثنان من المبيعات يشتركان في صندوق وارد. تبدأ صفقة جديدة غير معيّنة بـ owner_user_id = null و owner_team_id = Sales. عندما يتولى Alex المهمة، عيّن owner_user_id = Alex (واحتفظ بالفريق كـ Sales). يبقى خط الأنابيب قابلًا للقراءة وتعمل إجماليات الفريق.

تصميم الأذونات: ما يكفي من التحكم دون التعقيد

ابدأ بـ RBAC بسيطة

تعمل الأذونات بشكل أفضل عندما تفصل بين ثلاث أفكار: الأدوار (من)، الموارد (ما)، والإجراءات (ما الذي يمكنهم فعله). هذا هو التحكم بالوصول القائم على الأدوار (RBAC)، ويبقى مفهومًا مع نمو فريقك.

اجعل الموارد قريبة من كائناتك الأساسية: Contacts، Organizations، Deals، Activities، وربما Pipelines (إذا كانت المراحل قابلة للتعديل). عرّف مجموعة صغيرة ومتسقة من الإجراءات عبرها: view، create، edit، delete، export.

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

أذونات على مستوى الكائنات أسهل مكان للبدء: "هل يمكن لهذه الدور تعديل الصفقات أصلًا؟" بالنسبة لمعظم الفرق الصغيرة، هذا يكفي لأشهر. قواعد على مستوى السجل (لكل صفقة أو جهة اتصال) هي حيث يظهر التعقيد، فأضفها فقط عند الحاجة الحقيقية.

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

قواعد على مستوى السجل عندما تحتاجها فعلًا

أضف قواعد سجل عندما تكون هناك حالات مثل:

• مندوبو المبيعات يجب ألا يروا صفقات بعضهم البعض
• فريق الدعم يمكنه عرض الصفقات لكن لا يمكنه تعديلها
• المديرون يمكنهم عرض الكل وإعادة تعيين المالكين

اجعل حاجات التدقيق خفيفة لكنها حقيقية. أضف created_at، created_by, updated_at، و updated_by لكل جدول رئيسي. إذا احتجت تاريخًا أعمق لاحقًا، أضف جدول audit_log بسيطًا مع: نوع الكائن، معرف السجل، الإجراء، من، متى، و JSON قصير للحقول المتغيرة.

خطوة بخطوة: ابنِ المخطط في عطلة نهاية الأسبوع

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

اليوم 1: ثبّت نموذج البيانات

ابدأ بمخطط ERD سريع على ورقة أو سبورة. اجعل عدد الجداول صغيرًا، لكن كن واضحًا بشأن الروابط: contact ينتمي إلى organization (اختياري)، deal ينتمي إلى pipeline وله مالك، activity يمكن أن يرتبط بـ contact و/أو deal.

ثم أنفّذ الأساسيات بالترتيب:

• عرّف الكائنات والعلاقات: contacts، organizations، deals، activities، users/roles، بالإضافة إلى جداول بحث صغيرة عند الحاجة.
• عرّف الحقول المطلوبة والافتراضيات: اجعل created_at، owner_id، والأسماء الأساسية مطلوبة؛ عيّن افتراضات للمرحلة والعملة إن استعملت مبالغ.
• عرّف enums أو جداول بحث: مراحل الصفقات وأنواع الأنشطة بحيث تبقى التقارير متسقة.
• أضف مؤشرات لفلاتر شائعة: owner_id، المرحلة، due_at، created_at، والمفاتيح الخارجية التي تصفيها يوميًا.
• اختبر مع 20 سجلًا حقيقيًا: استخدم أسماء وأوقات وملاحظات فوضوية لترى ما ينكسر.

اليوم 2: أثبت أن التقارير نظيفة

قبل بناء النماذج، اكتب 6-8 أسئلة يسألها فريقك كل أسبوع. مثلاً: "الصفقات في Negotiation حسب المالك"، "الأنشطة المتأخرة"، "جهات الاتصال الجديدة هذا الشهر"، "الإيرادات المربحة بالشهر". إذا احتاج سؤال إلى انضمامات مربكة أو استثناءات، اصلح المخطط الآن.

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

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

أخطاء شائعة تجعل التقارير فوضوية

التقارير الفوضوية عادةً تبدأ بـ "حلول سريعة" تبدو أسرع اليوم لكنها تكلفك كل أسبوع بعد ذلك. يعمل مخطط CRM الخفيف أفضل عندما تكون لبياناتك أشكال واضحة وقواعد قليلة يتبعها الفريق فعلاً.

فخ شائع هو إجبار كل شيء في جدول "customer" واحد. يبدو بسيطًا حتى تحتاج للإجابة عن أسئلة أساسية مثل "كم عدد الصفقات المرتبطة بشركة واحدة؟" أو "أي شخص غيّر وظيفته؟" افصل الأشخاص (contacts) عن الشركات (organizations) واربطهما.

قاتل تقارير آخر هو السماح لمراحل الصفقات كنص حر. إذا كتب شخص "Negotiation" وآخر "negotiating"، رسم مخطط خط الأنابيب خاطئ بالفعل. استخدم قائمة مراحل ثابتة (أو جدول مراحل) بحيث تشير كل صفقة إلى نفس المجموعة.

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

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

قائمة "وفر لمستقبلك" سريعة:

• فصل contacts و organizations ثم ربطهما
• استخدم معرفات المراحل، لا أسماء المراحل المكتوبة
• قيمة واحدة لكل حقل؛ استخدم جدولًا فرعيًا للقيم المتعددة
• احتفظ بـ due_at و completed_at كحقول منفصلة
• ابدأ بأدوار بسيطة؛ أضف قواعد على مستوى السجل فقط بعد رؤية سير العمل الحقيقي

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

قائمة تحقق سريعة قبل الالتزام بالمخطط

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

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

5 فحوصات تكتشف معظم المشاكل

• أساسيات التقارير: هل يمكنك تجميع الصفقات حسب المرحلة والمالك وشهر الإغلاق دون التخمين أي حقل تاريخ تستخدم؟
• إدارة العمل: هل يمكنك سحب "الأنشطة المتأخرة حسب المالك" في تقرير واحد، حيث المتأخرة تعتمد على تاريخ استحقاق واحد وحالة منجزة واضحة؟
• الربط بين الاتصال والمنظمة: هل يمكن أن يوجد contact بدون organization، وهل يمكن ربطهما لاحقًا دون كسر التاريخ (بريد، ملاحظات، مشاركة في صفقات)؟
• الاتساق: هل المراحل وأنواع الأنشطة تأتي من قائمة ثابتة، حتى لا تحصل على "Follow up"، "Follow-up"، و"Followup" كقيم مختلفة؟
• الأمان: هل يمكنك تقييد من يمكنه حذف السجلات أو تصدير القوائم، دون منع التحديثات العادية مثل نقل صفقة إلى المرحلة التالية؟

إذا استطعت الإجابة بـ "نعم" على الخمس، فأنت في مكان جيد. إن لم يكن، أصلحها الآن بينما المخطط ما يزال صغيرًا.

نصيحة عملية: عرّف المراحل وأنواع الأنشطة مرة واحدة (كجدول أو enum) وأعد استخدامها في كل مكان حتى تستخدم كل شاشة وعملية نفس القيم.

مثال واقعي لفريق صغير وخطوات لاحقة

وكالة من 5 أشخاص تُعد اختبارًا جيدًا. الفريق مشغول، تأتي العملاء من كل مكان، ولا أحد يريد رعاية البيانات. تخيّل: مسؤول واحد، 2 مبيعات، قائد عمليات واحد، وزميل واحد للقراءة فقط (المؤسس الذي يراجع الأرقام فقط).

تصل طلبية واردة جديدة (نموذج ويب أو بريد): "نحتاج تحديث موقع، ميزانية 15k، مدة 6 أسابيع." القاعدة بسيطة: أنشئ منظمة واحدة (إن كانت شركة) وجهة اتصال واحدة (الشخص). ثم أنشئ صفقة مرتبطة بالمنظمة، مع جعل الشخص جهة الاتصال الأساسية لتلك الصفقة.

للحفاظ على السرعة، يستخدمون قائمة مدخلات صغيرة:

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

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

الأدوار تبقى عملية: Admin يمكنه تعديل كل شيء وإدارة الإعدادات، Sales يمكنهم إنشاء وتحديث جهات الاتصال والصفقات وأنشطتهم، Ops يمكنه تحديث حقول التسليم والأنشطة المتعلقة به، و Read-only يمكنه عرض الخط وأنظمة التقارير دون تغيير البيانات.

إذا أردت تحويل هذا إلى أداة داخلية تعمل بسرعة، AppMaster (appmaster.io) خيار مباشر: يمكنك نمذجة المخطط في Data Designer (PostgreSQL)، إضافة قواعد سير العمل في محرر Business Process، بناء صندوق وارد صغير وصفحة صفقة، ثم النشر إلى AppMaster Cloud أو سحابتك الخاصة عندما تكون جاهزًا للمشاركة مع الفريق.