إجابات واضحة قبل ما تبدأ مع Taly

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

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

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

يمكن البدء بالإعداد الأساسي ثم تفعيل الميزات حسب الباقة واحتياج النشاط. بعض المسارات التشغيلية لا تعمل إلا بعد وجود اشتراك نشط واستحقاق مناسب.

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

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

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

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

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

لا. Taly لا يستبدل واتساب، بل ينظم استخدام واتساب للأعمال داخل مساحة عمل للفريق، مع ربط الرسائل بالعملاء والطلبات والمتابعة.

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

نعم، التكامل الأساسي مبني حول WhatsApp Cloud API وسياسات Meta، لذلك تخضع بعض الرسائل والقوالب والمحادثات لقواعد واتساب الرسمية.

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

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

نعم. يمكن للفريق العمل من نفس المساحة، مع تنظيم المحادثات وتوزيعها حسب المسؤول أو الحالة حتى لا تضيع المتابعة بين الأعضاء.

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

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

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

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

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

لا. الحملات تخضع لحدود الباقة، حالة الاشتراك، جاهزية القناة، وسياسات WhatsApp/Meta.

في الرسائل التي تخرج خارج نافذة المحادثة أو حسب نوع الرسالة، قد تحتاج قوالب معتمدة من Meta قبل الإرسال.

نعم، النظام يتعامل مع سجلات إرسال وجدولة ومحاولات إعادة حسب حالة كل رسالة، بحيث يمكن متابعة نتيجة الحملة بشكل أوضح.

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

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

ليس بالضرورة. تشغيل Flow Builder v2 مرتبط بالاستحقاق والباقة، ولا يعمل للمنظمة إذا لم تكن الميزة متاحة لها.

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

نعم، تصميم النظام يدعم فكرة الانتقال من flow آلي إلى متابعة بشرية عند الحاجة، بحيث لا يبقى العميل عالقًا في مسار غير مناسب.

نعم. Flow Builder له تحقق من شكل المسار والعقد والحالات حتى لا يتم نشر flow غير صالح أو غير آمن.

نعم، يمكن استخدام الذكاء الاصطناعي للمساعدة في الردود، التلخيص، التصنيف، أو اقتراح خطوات للفريق حسب الميزات المفعلة.

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

سياسة الخصوصية توضح أن بيانات العملاء لا تُستخدم لتدريب نماذج عامة، وأن المعالجة تتم لتقديم الخدمة عند تفعيل الميزة.

لا يجب الاعتماد عليها وحدها في قرارات قانونية أو طبية أو مالية أو حساسة. دورها مساعد، والقرار النهائي للفريق.

تفعيل ميزات AI يكون حسب الإعدادات والباقات المتاحة، ويمكن تنظيم استخدامها حسب سياسة المؤسسة واحتياج الفريق.

نعم. من أهم أهداف Taly تحويل المحادثات التجارية إلى طلبات واضحة يمكن متابعتها من الإنشاء حتى الدفع والتنفيذ.

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

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

لا. إثبات الدفع لا يؤكد الدفع وحده. يتم تأكيد الدفع بعد مراجعة موثوقة أو callback من بوابة دفع حسب طريقة الدفع.

نعم، يمكن إنشاء روابط checkout/actions/receipts للعميل، مع الحفاظ على عدم كشف metadata أو tokens داخلية.

نعم. يمكن استخدامه لتنظيم الخدمات، المواعيد، العملاء، الموارد، والتذكيرات حسب نوع النشاط والباقة.

يمكن تنظيم رحلة الحجز من المحادثة إلى موعد واضح داخل النظام، حسب إعداد الخدمات والإتاحة والباقة.

نعم، نظام الحجوزات يدعم فكرة الموارد والإتاحة عند تفعيل Commerce Bookings، حتى يتم تنظيم المواعيد حسب القدرة الفعلية.

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

الحجوزات تعمل عندما تكون ميزة Commerce Bookings متاحة للباقة أو المؤسسة. بدونها تبقى مسارات المنتجات أو المتاجر العادية منفصلة.

نعم. الباقات تختلف حسب الاستخدام، عدد المستخدمين، الحدود، القنوات، الحملات، الأتمتة، التجارة، والحجوزات.

نعم. يمكن البدء بباقة مناسبة ثم الترقية عند نمو الفريق أو زيادة الرسائل أو الحاجة لميزات إضافية.

لا. سعر الباقة يخص استخدام منصة Taly، أما رسوم Meta/WhatsApp الرسمية فتكون منفصلة حسب نوع الرسالة والبلد والاستخدام.

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

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

نعم. توجد واجهات API لاستخدامات مثل جهات الاتصال، الرسائل، الحملات، وبعض عمليات التجارة حسب التوثيق والصلاحيات.

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

نعم، توجد rate limits وحدود مرتبطة بالباقة والاستخدام لحماية النظام واستقرار الخدمة.

نعم، يمكن إرسال أحداث إلى أنظمة خارجية عند تفعيل Developer Webhooks والاشتراك في الأحداث المطلوبة.

نعم، Webhooks تعتمد على توقيع ومحاولات تسليم وسياسة headers، وأحداث Commerce لا ترسل إلا عند توفر الإضافة والاشتراك في الحدث.

نعم. النظام مبني على multi-tenant boundaries بحيث لا يجوز لمؤسسة قراءة أو تعديل بيانات مؤسسة أخرى.

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

يدعم النظام آليات أمان مثل التحقق، حدود الصلاحيات، وحماية مسارات حساسة حسب نوع المستخدم والإعدادات.

يمكن التواصل مع الدعم عبر support@talyapp.net باستخدام نفس البريد المرتبط بالحساب، مع توضيح أن الطلب متعلق بحذف البيانات.

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

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

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

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

تواصل مع فريق Taly عبر صفحة التواصل أو البريد support@talyapp.net، وسيتم توجيهك حسب احتياجك: مبيعات، دعم، حساب، أو إعداد تقني.