لماذا أنشأنا RapidClaw
لم نبني RapidClaw لأن العالم كان بحاجة إلى عرض توضيحي آخر للذكاء الاصطناعي.
بصراحة، هناك بالفعل الكثير من تلك العروض. السوق مليء بالوكلاء الذين يبدون سحريين في فيديو مدته دقيقتان ويثيرون الشكوك بمجرد أن تسأل أسئلة أساسية مثل: أين يعمل هذا؟ من يتحكم فيه؟ ما البيانات التي يمكنه الوصول إليها؟ من يوافق على السلوك الخارجي؟ ماذا يحدث عندما يكون هناك خطأ؟
أنشأت RapidClaw لأن الشركات ترغب بوضوح في الاستفادة من الذكاء الاصطناعي داخل CRM، لكن لا ينبغي لها أن تتخلى عن السيطرة للحصول عليه. والآن، يتصرف جزء كبير من السوق كما لو أن هذا التبادل لا مفر منه.
المشكلة التي أردنا حلها
أصبحت صناعة الذكاء الاصطناعي جيدة للغاية في تجاوز الجزء الصعب.
من السهل عرض نموذج يلخص بريدًا إلكترونيًا، أو يكتب متابعة، أو يتظاهر بإدارة خط أنابيب. من الأصعب بكثير بناء شيء يعمل في العالم الحقيقي لبيانات العملاء، وعملية المبيعات، والموافقات، وسجلات الخدمة، وحدود الهوية، وبنية Microsoft التحتية.
في CRM، تكون المشكلة أكثر وضوحًا. هذا ليس صندوق رمل. هنا تتذكر الشركة من هم العملاء، وما تم الوعد به، وما هو في خطر، وما يجب أن يحدث بعد ذلك، وما لا ينبغي أن يحدث دون إشراف.
وجهة نظري بسيطة: الذكاء الاصطناعي لـ CRM يحتاج إلى نموذج تشغيل، وليس مجرد مطالبة.
لماذا اخترنا تشغيل Azure مملوك للعميل
كان أحد القرارات الأولى التي اتخذناها هو أن RapidClaw لا ينبغي أن يعمل كصندوق غامض في سحابة شخص آخر.
اخترنا نشر التشغيل في اشتراك Azure الخاص بالعميل لأن المنظمات الجادة تهتم بالعزلة والسيادة والثقة. لا يريدون بائعًا يقول، “فقط أرسل لنا جميع تفاعلات عملائك وثق بأننا سنكون حذرين.”
هذا ليس كيف يفكر المشترون الحقيقيون، وليس كيف نفكر نحن أيضًا. إذا كان الذكاء الاصطناعي سيُدمج في عمليات العملاء، فإن نموذج النشر مهم. كثيرًا.
- عزل تشغيل العميل
- Azure OpenAI في مستأجر العميل والمنطقة
- حدود الهوية والأمان لـ Microsoft
- قصة نشر تتناسب مع توقعات المؤسسات
لماذا يجب أن يصبح النشر أسهل
كان مبدأ التوجيه الآخر بسيطًا: إذا ظل نشر الذكاء الاصطناعي تقنيًا للغاية، فلن تصل معظم الشركات الحقيقية إلى هناك أبدًا.
هناك فرق كبير بين إطار عمل يمكن نشره بواسطة الخبراء ومنتج يمكن نشره بواسطة مشغلين عاديين داخل بيئة تطبيقات الأعمال. اهتممنا بهذا الفرق منذ البداية.
لهذا السبب يستخدم RapidClaw تجربة إعداد تعتمد على المعالج ومتصفح أول بدلاً من افتراض أن العميل يريد العيش في CLI، أو توصيل البنية التحتية يدويًا، أو تجميع تشغيله الخاص من تعليمات متفرقة.
أردنا أن يشعر النشر وكأنه إنشاء منتج أعمال جاد وليس الانضمام إلى تجربة. جعل نشر الذكاء الاصطناعي المحكوم أسهل ليس ميزة راحة. إنه أحد مبادئ المنتج.
لماذا Dataverse هو حدود التحكم
لم نرغب أيضًا في أن يجلس الذكاء الاصطناعي بجانب CRM كملحق غير مسؤول.
Dataverse هو بالفعل منصة الأعمال لـ RapidStart CRM، لذلك هذا هو المكان الذي أردنا أن يعيش فيه نموذج التحكم أيضًا. التكوين، السياسة، سجلات النشر، الموافقات، الحالة التشغيلية، والسياق التجاري كلها تنتمي إلى نظام يحكمه العميل بالفعل.
بعبارة أخرى، أردت أن يكون الذكاء الاصطناعي مدمجًا داخل المنصة، وليس مثبتًا عليها كملحق.
لماذا Microsoft
اخترنا Microsoft لأن هذا هو المكان الذي تعيش فيه تطبيقات الأعمال الجادة بالفعل لجزء كبير من السوق الذي نهتم به.
الهوية من خلال Entra. التعاون من خلال Teams. حالة البيانات والتطبيقات من خلال Dataverse. البنية التحتية من خلال Azure. هذه البنية موجودة بالفعل داخل آلاف المنظمات. إنها تحمل بالفعل الثقة والسياسة والجاذبية التشغيلية.
لم نرغب في بناء منتج ذكاء اصطناعي يطلب من العملاء الخروج من العقار الذي يحكمونه بالفعل للحصول على القيمة. أردنا بناء شيء يشعر بأنه أصلي للبيئة التي يعتمدون عليها بالفعل.
Microsoft ليست دائمًا الطريق الأخف، وهذا هو بالضبط النقطة. لهذا النوع من المنتجات، الهيكل الإضافي ليس عبئًا. إنه ما يجعل الذكاء الاصطناعي المحكوم ممكنًا في المقام الأول.
لماذا RapidStart CRM
قمنا أيضًا ببناء RapidClaw لـ RapidStart CRM بشكل متعمد.
RapidStart CRM يجلس بالفعل في وسط نشاط المبيعات، وتاريخ العملاء، وتفاعلات الخدمة، وسياق العلاقات. إنه المكان الذي تحتفظ فيه الشركة بالفعل بالحقيقة التشغيلية التي يحتاجها الذكاء الاصطناعي ليكون مفيدًا حقًا.
الأهم من ذلك، أن RapidStart CRM بسيط بطبيعته. هذا مهم. إذا كنت تريد أن يعمل الوكلاء بطريقة محكومة، فلا يمكن أن يكون نظام الأعمال الأساسي متاهة من التعقيد غير الضروري. يوفر لنا RapidStart CRM سطحًا أنظف للتفكير فيه، ونموذج مستخدم أوضح، ونقطة انطلاق أفضل لأتمتة مفيدة.
باختصار، RapidClaw منطقي لأن RapidStart CRM يحتوي بالفعل على البيانات والبنية والبساطة التي يحتاجها الذكاء الاصطناعي ليصبح عمليًا.
لماذا Teams مهم
شيء آخر رفضناه مبكرًا هو فكرة أن المستخدمين يجب أن يعيشوا في بوابة إدارة أخرى أو ملعب ذكاء اصطناعي للحصول على القيمة.
بالنسبة للعديد من الشركات، Teams هو المكان الذي يحدث فيه العمل بالفعل. هذا هو المكان الذي يطرح فيه الناس الأسئلة، وينسقون، ويتابعون، ويتوقعون ظهور المساعدة. لذلك يستخدم RapidClaw تجربة مساعد أصلية لـ Teams مع سطح منسق واحد للمستخدمين النهائيين وتنسيق متخصص خلف الكواليس.
هذا مهم لأن سهولة الاستخدام مهمة. إذا كان الذكاء الاصطناعي قويًا ولكنه محرج، فإن التبني يموت. الكثير من المنتجات المثيرة للإعجاب تقنيًا تخسر هناك.
لماذا تأتي الحوكمة قبل الاستقلالية
قد يكون هذا هو الخيار التصميمي الأهم في المنتج بأكمله.
RapidClaw آمن افتراضيًا. النشر لا يعني الاستقلالية الفورية. يتم توفير البيئات الجديدة في وضع غير مباشر، ثم يتم تفعيلها عن قصد من خلال مركز قيادة RapidClaw.
قمنا بذلك لأن الشركات لا تريد مفاجآت. يريدون معرفة ما هو مباشر، أي الوكلاء نشطون، ما يتطلب الموافقة، ما يمكنه إرسال الاتصالات، وما يمكنهم إيقافه فورًا إذا احتاجوا إلى ذلك.
يصبح الذكاء الاصطناعي أسهل بكثير في التبني عندما يكون نموذج التشغيل صريحًا ومملًا بالطرق الصحيحة. الملل غير مقدر حقه. الملل هو ما يسمح للشركات الجادة بالثقة في النظام.
لماذا بنينا على OpenClaw
كان علينا أيضًا أن نقرر ما إذا كنا سنبني التشغيل بالكامل من الصفر أو نبني على شيء يفهم بالفعل تنسيق الوكلاء.
اخترنا OpenClaw لأن RapidClaw لم يكن من المفترض أن يكون مجرد غلاف رقيق حول نموذج. كنا بحاجة إلى تشغيل حقيقي لتنسيق الوكلاء المتعددين، واستخدام الأدوات، والوساطة، والتنفيذ داخل بيئة مملوكة للعميل.
أعطانا OpenClaw تلك النقطة البداية. سمح لنا بتركيز طاقتنا على المشكلة الأصعب، وفي رأينا، الأكثر أهمية: كيفية جعل الذكاء الاصطناعي الوكيل يتصرف كمنتج حقيقي داخل CRM بدلاً من تجربة ذكية خارجه.
RapidClaw هو ما يحدث عندما يتم تشكيل هذا التشغيل إلى شيء يمكن التحكم فيه: نشر Azure مملوك للعميل، تحكم مركزي في Dataverse، وصول أصلي لـ Teams، تدفقات عمل الموافقة، وسطح تشغيل حقيقي من خلال مركز قيادة RapidClaw.
حيث يلتقي هذا مع اتجاه Microsoft
النظر إلى ما تفعله Microsoft الآن حول Lobster وOpenClaw يجعل الانقسام أكثر وضوحًا.
تأتي Microsoft من جانب الإنتاجية الشخصية: الرسائل، والتقويمات، والتذكيرات، وصناديق البريد، والاجتماعات، والمساعدة الاستباقية للفرد. هذا منطقي. يبدأ مع المستخدم.
RapidClaw يأتي من جانب Dataverse: سجلات العملاء، والفرص، والموافقات، والحالة التشغيلية، والحقيقة المشتركة للأعمال. هذا يبدأ مع نظام السجل.
هذه ليست اتجاهات متعارضة. إنها النصفان لنفس المستقبل. طبقة الإنتاجية تعرف ما أحاول القيام به. طبقة Dataverse تعرف ما يمكن للأعمال السماح به، وما يقوله سجل العميل، وما يجب تذكره.
هذا هو المكان الذي نعتقد أن هذه العوالم تلتقي فيه: توفر Microsoft نسيج الوكيل الموجه للمستخدم، وRapidClaw يوفر السياق التجاري المحكوم ونموذج العمل الخاص بـ CRM. لا أرى تلك الاتجاهات على أنها متضاربة. أراها في النهاية بحاجة إلى بعضها البعض.
فوائد الأعمال
لا يهم أي من هذا إذا لم يخلق قيمة للأعمال.
النقطة ليست أن الوكيل يمكنه القيام بشيء مثير للاهتمام مرة واحدة. النقطة هي أنه يمكنه القيام بعمل مفيد بشكل متكرر بطريقة يمكن للأعمال أن تعيش معها بالفعل.
هذا معيار أعلى بكثير مما تعترف به معظم منتجات الذكاء الاصطناعي. إنه أيضًا المعيار الذي نهتم به.
- متابعة أسرع للقيادة ودعم المبيعات
- نظافة أفضل لخط الأنابيب ورؤية أوضح للخطوات التالية
- فرز خدمة مبكر ومساعدة مسودة أكثر تنظيمًا
- عمل إداري أقل يدويًا حول الملخصات، والتنبيهات، والتنسيق
- ثقة أكبر لأن الموافقات والسياسات والتشخيصات مدمجة
- مسار لتبني الذكاء الاصطناعي يتناسب مع كيفية عمل الشركات التي تركز على Microsoft بالفعل
ما الذي يجعل RapidClaw مختلفًا
RapidClaw لا يحاول أن يكون القصة الأكثر صخبًا للذكاء الاصطناعي في السوق. أفضل بكثير أن يكون واحدًا من الأكثر مصداقية.
ما يجعله مختلفًا هو المزيج: تشغيل مملوك للعميل، حوكمة مركزية في Dataverse، تفاعل أصلي لـ Teams، مركز قيادة للعمليات، ونموذج وكيل متخصص مصمم خصيصًا لـ RapidStart CRM.
هذا المزيج هو المنتج.
أنشأت RapidClaw لأن الذكاء الاصطناعي في CRM يجب أن يكون مفيدًا، وقابلًا للحكم، وقابلًا للنشر في العالم الحقيقي، وليس فقط مثيرًا للإعجاب في عرض توضيحي.