المقدمة
يتحدث وكيل الذكاء الاصطناعي لديك مع كل زائر على موقعك. بعضهم جاهز للشراء، وبعضهم يطرح سؤالًا لا يستطيع الوكيل الإجابة عنه، وبعضهم يطلب ميزة لا تملكها بعد، وبعضهم يريد عرضًا توضيحيًا. افتراضيًا، يختفي كل ذلك عند إغلاق المحادثة.
يوضح لك هذا الدليل كيفية ربط وكيل الذكاء الاصطناعي بـ Google Sheets بحيث تصبح كل لحظة من هذه اللحظات صفًا في جدول يستخدمه فريقك بالفعل. لا Zapier، ولا webhooks، ولا مهندس. تحتاج إلى شيئين:
- وكيل Quickchat AI (سجّل هنا واستخدمه مجانًا)
- حساب Google
الآلية هي AI Actions: طلبات HTTP مخصصة يمكن لوكيلك إجراؤها أثناء المحادثة. لدى Quickchat AI اتصال Google Sheets بنقرة واحدة ينشئ لك جدولًا وإجراء تسجيل ابتدائيًا، ومن هناك تشكله وتضيف عدد التقارير الذي تريده. بنهاية الدليل سيكون لديك أربعة تقارير عاملة، وستكون قد اختبرت كل واحد بنفسك.
هذا شرح طويل ودقيق. المرجع الأساسي لـ AI Actions موجود في الوثائق على docs.quickchat.ai/ai-agent/actions. للاطلاع على أمثلة تطبيقية أخرى لإجراء مخصص، راجع ربط وكيل الذكاء الاصطناعي بـ HubSpot لتسجيل جهات الاتصال والصفقات والتذاكر، أو إرسال إشعارات Slack باستخدام AI Actions، أو بناء بوت Telegram بالذكاء الاصطناعي لإدارة مجموعتك.
ما الذي ستبنيه
أربعة تقارير، يكتب كل منها في تبويب خاص به داخل Google Sheet واحد:
| التقرير | التبويب | متى يكتب الوكيل صفًا |
|---|---|---|
| العملاء المحتملون | Leads | عندما يُظهر زائر نية شراء ويشارك بريدًا إلكترونيًا |
| الأسئلة غير المجاب عنها | Unanswered | عندما لا يستطيع الوكيل الإجابة عن سؤال واقعي |
| الملاحظات | Feedback | عندما يطلب زائر ميزة أو يبلغ عن خلل أو يقدم ثناءً |
| طلبات العروض التوضيحية | Demos | عندما يطلب زائر عرضًا توضيحيًا أو مكالمة |
لقطات الشاشة أدناه مأخوذة من وكيل اختباري بُني لشركة خيالية اسمها Tideline، وهي منصة تحليلات اشتراكات لشركات SaaS. الشركة مخترعة حتى يبقى المثال محايدًا، لكن كل محادثة وكل صف معروض هنا أنتجه وكيل حقيقي يعمل عبر مسار الرد الحقيقي. استخدم تفاصيل شركتك عند المتابعة.
كيف يعمل تكامل Google Sheets
تعتمد الميزة كلها على فكرة واحدة: AI Action هو طلب HTTP موصوف، وصف Google Sheet هو طلب من هذا النوع.
يتكون AI Action من أربعة أجزاء. الوصف هو ما يقرأه النموذج ليقرر هل يستدعيه أم لا؛ والمعاملات هي ما يملؤه من المحادثة.
تجعل بعض الحقائق الإضافية بقية المقال أسهل في المتابعة.
- كتابة صف هي استدعاء API واحد. لدى Google Sheets نقطة نهاية
appendتضيف صفًا إلى تبويب. كل تقرير هو طلبPOSTإلى تلك النقطة مع قيم الصف في الجسم. - الأعمدة غير ثابتة. هي أي شيء يرسله الإجراء. تحدد الأعمدة بتعديل جسم الإجراء وصف العناوين في الجدول، لذلك يستطيع التكامل نفسه تسجيل العملاء المحتملين أو تقارير الأخطاء أو أي شيء آخر.
- وصول بأقل امتيازات. يطلب اتصال Google نطاق
drive.fileفقط، وهو يمنح الوصول حصريًا إلى الملفات التي ينشئها التطبيق. لا يمكنه رؤية بقية Drive لديك. - الوكيل لا يرى بيانات اعتمادك أبدًا. يحمل الطلب ترويسة
Authorizationقيمتها عنصر نائب،{{google_sheets_access_token}}. يملأ Quickchat AI هذا العنصر النائب برمز حقيقي يتجدد تلقائيًا بعد أن ينهي النموذج دوره. لا يدخل الرمز إلى النص التوجيهي أبدًا. - يتوفر متغيران مدمجان لأي إجراء دون تعريفهما كمعاملات:
{{conversation_url}}، وهو رابط عميق إلى المحادثة في Inbox، و{{conversation_channel}}، وهي القناة التي استخدمها الزائر (أداة الويب وSlack وWhatsApp وما إلى ذلك).
الخطوة 1: أنشئ وكيل الذكاء الاصطناعي وأعطه المعرفة
ينبع سلوك وكيل Quickchat من موضعين: Identity (النص التوجيهي الرئيسي) والمعرفة التي تعطيها له ليجيب منها. Actions & MCPs هو المكان الذي توسع فيه ما يستطيع فعله، مثل الكتابة إلى Google Sheet. يعمل هذا الدليل في Identity (هذه الخطوة والخطوة 4) وActions & MCPs (الخطوات 2 و3 و6)، ويختبر كل شيء في AI Preview (الخطوة 5).
بعد أن تسجل، افتح Identity في الشريط الجانبي الأيسر. AI Main Prompt هو المكان الذي تصف فيه ماهية وكيلك وكيف ينبغي أن يتصرف. أعطه وصفًا قصيرًا ودقيقًا لمنتجك، وضع الحقائق التي يجب أن يستطيع ذكرها (الخطط والأسعار والتكاملات المتاحة) في معرفته حتى يستطيع الإجابة عن الأسئلة مباشرة.
اسم الوكيل والنص التوجيهي الرئيسي له: وصف قصير ودقيق لمنتجك وكيف ينبغي أن يتصرف الوكيل. تضيف كتلة التقارير إلى نهاية هذا النص التوجيهي في الخطوة 4.
لا تقلق بشأن كتابة كل ذلك النص بنفسك. كل نص توجيهي ووصف إجراء وجسم طلب في هذا الدليل مقدم ككتلة جاهزة للنسخ واللصق، لذلك ستلصقها بدلًا من كتابتها. ستعود إلى هذه الشاشة في الخطوة 4 لإضافة تعليمات التقارير.
الخطوة 2: اربط Google Sheets
افتح Actions & MCPs في الشريط الجانبي، وانقر Add Action، واختر Google Sheets.
Actions & MCPs، ثم Add Action، ثم Google Sheets.
يفتح مربع حوار الاتصال، وقبل أن تمنح أي وصول، يوضح ما الذي ستعده النقرة الواحدة: Google Sheet جديد في Drive لديك، وإجراء تسجيل جاهز للاستخدام، مضبوط مسبقًا للعملاء المحتملين. يفعّل الإعداد الحالي إجراء البدء، لذلك أوقفه أثناء مراجعته أو إعادة استخدامه.
انقر Connect. تسألك Google أي حساب تريد استخدامه ثم أي إذن تريد منحه. النطاق الوحيد المطلوب هو drive.file، وهو يسمح للتكامل بلمس الملفات التي ينشئها فقط، وليس بقية Drive لديك.
شاشة Google نفسها: اختر الحساب الذي يجب أن يوجد الجدول في Drive الخاص به. تمنح الشاشة التالية إذن drive.file، الذي يسمح للتكامل بلمس الملفات التي ينشئها فقط.
عند الموافقة، تعود إلى صفحة Actions & MCPs. يكون Quickchat AI قد:
- أنشأ جدولًا في Google Drive لديك، مع تبويب واحد (
Leads) وصف عناوين. - أضاف AI Action واحدًا نشطًا باسم
log_lead_to_google_sheet، موصولًا بالفعل بذلك الجدول.
إجراء البدء هذا هو AI Action عادي وقابل للتعديل بالكامل. يضبطه التكامل مسبقًا لجمع العملاء المحتملين. احتفظ باسم log_lead_to_google_sheet حتى تستطيع شاشة الاتصال التعرف على إجراء البدء؛ غيّر معامله وجسمه ووصفه حسب الحاجة. في هذا الدليل ستوقفه، وتراجعه، وتعيد تفعيله كتقرير أول قبل بناء ثلاثة تقارير أخرى في الخطوة 6.
الخطوة 3: راجع إجراء العميل المحتمل وفعّله
يظهر إجراء log_lead_to_google_sheet المنشأ تلقائيًا تحت Custom Actions ويكون نشطًا عند إنشائه. أوقفه، ثم افتحه لمراجعة التكوين قبل تفعيله مرة أخرى. هذا هو القالب الذي يتبعه كل تقرير آخر، لذلك يستحق فهمه بالكامل.
إجراءات التقارير الأربعة. الأول فقط، log_lead_to_google_sheet، يُنشأ لك؛ أما الثلاثة الأخرى فتضيفها في الخطوة 6.
يحمل أعلى الإجراء اسمه والمعاملات التي يجمعها الوكيل:
اسم الإجراء والمعاملات التي يملؤها الوكيل من المحادثة.
مرر إلى قسم API Endpoint. لأن Quickchat AI أنشأ الجدول وهذا الإجراء معًا، يكون عنوان URL مملوءًا بالفعل بمعرف جدولك، والطريقة هي POST، والترويسات معدة:
يحتوي عنوان نقطة النهاية الكامل بالفعل على معرف جدولك. يبقى Query Params فارغًا: ينتقل إعداد valueInputOption=RAW داخل عنوان URL. تحمل ترويسة Authorization عنصر الرمز النائب.
إن {SPREADSHEET_ID} الذي تراه مكتوبًا في وثائق API ليس عنصرًا نائبًا حيًا. عند الاتصال، أنشأ Quickchat AI جدولك وكتب معرفه الحقيقي مباشرة في عنوان URL لهذا الإجراء، لذلك يعرض الحقل العنوان الكامل بالفعل:
https://sheets.googleapis.com/v4/spreadsheets/<your sheet ID>/values/Leads:append?valueInputOption=RAW
احتفظ بـ valueInputOption=RAW: فهو يدرج القيم حرفيًا، بحيث لا تُفسر الرسالة التي تبدأ بـ = أو + كصيغة جدول. ستنسخ عنوان URL نفسه بالضبط إلى التقارير الثلاثة الأخرى في الخطوة 6، مع تغيير اسم التبويب فقط، لذلك لن تحتاج أبدًا إلى البحث عن المعرف يدويًا.
الترويسات نفسها لكل تقرير (يمكنك قراءتها من لقطة الشاشة أعلاه):
| المفتاح | القيمة |
|---|---|
Authorization | Bearer {{google_sheets_access_token}} |
Content-Type | application/json |
الآن الجزء الذي يجعل الأعمدة مرنة. انتقل إلى تبويب Body، داخل قسم API Endpoint نفسه. جسم الطلب هو صف واحد، وكل خلية هي معامل واحد. ترتيب الخلايا في الجسم هو ترتيب الأعمدة في الجدول:
{ "values": [[ "{{email}}", "{{what_they_asked}}", "{{conversation_url}}", "{{conversation_channel}}" ]] }
يوجد جسم الطلب في تبويب Body. كل {{parameter}} هو خلية واحدة، وتأتي الخلايا بالترتيب نفسه مثل أعمدة الجدول.
لذلك فالأعمدة ليست مضمّنة بشكل ثابت في التكامل. يحددها هذا الجسم مع صف العناوين في التبويب. غيّر الجسم والعناوين، فتغيّر ما يسجله التقرير. فيما يلي كيف تُطابق محادثة عميل محتمل حقيقية هذا الصف:
ما قاله الزائر يُطابق المعاملات، والمعاملات تُطابق الأعمدة، بالترتيب. يُملأ المتغيران المدمجان تلقائيًا.
المعاملات هي الحقول التي يملؤها الوكيل من المحادثة. وصف كل معامل هو ما يخبر الوكيل بما يجب وضعه هناك:
| المعامل | مطلوب | الوصف |
|---|---|---|
email | نعم | البريد الإلكتروني المهني للعميل المحتمل. مطلوب: اطلبه من الزائر قبل التسجيل إذا لم يكن قد شاركه. |
what_they_asked | نعم | ملخص قصير، بكلمات الزائر نفسه، لسؤال التسعير أو الخطط الذي طرحه. |
أخيرًا، وصف الإجراء. هذا هو الحقل الأهم منفردًا، لأنه ما يقرأه النموذج ليقرر هل يستدعي الإجراء أصلًا. النسخة أدناه مضبوطة بحيث ينتظر الوكيل حتى يكون لديه بريد إلكتروني فعلًا قبل كتابة صف (المزيد عن السبب في قسم الضبط):
سجل عميلًا محتملاً مؤهلًا حتى يستطيع الفريق المتابعة. محفز هذا الإجراء هو أن يقدم الزائر عنوان بريده الإلكتروني مع إظهار اهتمام بالشراء (سأل عن التسعير أو الخطط أو التكلفة أو الجدول الزمني أو الميزانية). استدع هذا الإجراء فقط في دورة يكون فيها الزائر قد أعطاك للتو عنوان بريد إلكتروني حقيقيًا؛ ضع ذلك البريد نفسه في معامل email. إذا أظهر الزائر اهتمامًا بالشراء لكنه لم يقدم بريدًا إلكترونيًا بعد، فلا تستدع هذا الإجراء: أجب عنه واطلب بريده الإلكتروني أولًا. لا تستدع هذا الإجراء أبدًا في دورة لم يتم فيها تقديم بريد إلكتروني، ولا تستخدم بريدًا فارغًا أو مختلقًا أبدًا.
رسالة التفكير (Noting your interest for our team...) هي حالة قصيرة يراها الزائر أثناء تشغيل الإجراء. عندما يبدو التكوين صحيحًا، شغّل الإجراء.
الخطوة 4: أضف تعليمات التقارير إلى النص التوجيهي
تحدد أوصاف الإجراءات متى يعمل كل تقرير. يؤدي النص التوجيهي وظيفة مختلفة ومكملة: يخبر الوكيل أن التقارير جزء من عمله، ويمنع التقارير الأربعة من التداخل مع بعضها.
ارجع إلى Identity والصق هذه الكتلة في نهاية AI Main Prompt. تغطي التقارير الأربعة كلها، لذلك تلصقها مرة واحدة فقط:
## رفع التقارير إلى الفريق
لديك عدة إجراءات تسجل معلومات مفيدة في Google Sheet الخاص بالفريق. تعمل بصمت في الخلفية. هي جزء من عملك وليست اختيارية. عندما تنطبق إحدى الحالات أدناه، استدع الإجراء المطابق في الدورة نفسها التي ترسل فيها ردك. يمكنك أن تجيب الزائر وتستدعي إجراءً في الدورة نفسها. لا تذكر جدول البيانات أو التسجيل أو هذه الإجراءات للزائر أبدًا. عند الشك، سجّل الأمر.
- نية الشراء. يسأل الزائر عن التسعير أو الخطط أو الجدول الزمني أو الميزانية. أجب عن سؤاله، ثم اجمع العميل المحتمل. إذا لم يكن قد شارك بريدًا إلكترونيًا بعد، فاطلب فقط أفضل بريد إلكتروني ليتابع الفريق معه ولا تسجل أي شيء في تلك الدورة. استدع إجراء العميل المحتمل فقط في الدورة التي يكون لديك فيها بريده الإلكتروني فعليًا (أو التي يرفض فيها مشاركته). سجّل كل عميل محتمل مرة واحدة.
- فجوة معرفة. لا تستطيع الإجابة بالكامل عن سؤال واقعي (مثل الأمان أو الشهادات أو السياسات أو المسائل القانونية أو قدرة محددة)، أو يطلب الزائر إنسانًا، أو يبدو الزائر غير راضٍ. سجّل ذلك كسؤال غير مجاب عنه. تتعامل إجراءات العملاء المحتملين مع أسئلة التسعير، وتتعامل إجراءات الملاحظات مع طلبات الميزات، لذلك لا تسجل هذه الحالات أيضًا كأسئلة غير مجاب عنها.
- ملاحظات. يطلب الزائر ميزة أو تكاملًا لا تقدمه، أو يبلغ عن خلل، أو يقدم ثناءً قويًا. سجّل ذلك كملاحظات على المنتج.
- طلب عرض توضيحي. يطلب الزائر صراحة عرضًا توضيحيًا أو مكالمة أو التحدث إلى المبيعات. اجمع بريده الإلكتروني، واسمه وشركته إذا قدمهما، ثم سجل طلب العرض التوضيحي.
الصق الكتلة في نهاية النص التوجيهي الرئيسي تمامًا، بعد هوية الوكيل. تغطي التقارير الأربعة كلها، لذلك تضيفها مرة واحدة.
الخطوة 5: اختبر تقرير العملاء المحتملين
تأكد الآن من أنه يعمل قبل أن يراه أي زائر حقيقي. AI Preview هي الطريقة الحية والتفاعلية للدردشة مع وكيلك تمامًا كما يفعل الزائر. (لاحقًا يمكنك أيضًا استخدام Simulation لإعادة تشغيل العديد من رسائل الاختبار دفعة واحدة وتقييم الردود؛ راجع كيفية ضبط التقارير.) لأنهما قناتان اختباريتان، سيقرأ عمود Channel القيمة preview أو simulation بدلًا من قناة حقيقية.
افتح AI Preview في الشريط الجانبي وأجرِ محادثة كما يفعل زائر حقيقي: اسأل عن التسعير، ثم شارك بريدًا إلكترونيًا.
يجيب الوكيل عن سؤال خطة Growth من معرفته. عندما يحصل على بريد الزائر الإلكتروني، يسجل العميل المحتمل في الخلفية.
شاهد بالضبط ما فعله الوكيل
لا تحتاج إلى التخمين هل نُفذ الإجراء أم لا. افتح تلك المحادثة في Inbox ووسّع استدعاء الإجراء الظاهر تحت رد الوكيل. يعرض أي إجراء نُفذ، والقيم الدقيقة التي أرسلها، وأنه نجح (200):
داخل المحادثة، يُسجل استدعاء إجراء الوكيل بالكامل: اسم الإجراء والمعاملات التي أرسلها والنتيجة.
والصف الذي يكتبه يصل إلى تبويب Leads:
العميل المحتمل، مكتوب مباشرة في الجدول. يحصل كل تقرير على تبويبه الخاص في الأسفل.
يفتح رابط المحادثة المحادثة الكاملة في Inbox لديك، بحيث يحصل من يتابع على السياق. يوضح عمود Channel مصدر الزائر.
يحتفظ كل إجراء أيضًا بـ سجل استدعاءات خاص به في صفحة Actions: إجمالي الاستدعاءات، ومعدل النجاح، ومتوسط زمن الاستجابة، ومعاملات كل استدعاء فردي واستجابته. هنا تتأكد، مع مرور الوقت، من أن الوكيل يستدعي الإجراء الصحيح بالقيم الصحيحة:
سجل الاستدعاءات لكل إجراء: عدد مرات تشغيله، وعدد مرات نجاحه، وما أرسله كل استدعاء واستقبله.
هذه هي الحلقة الكاملة: محادثة، قرار من الوكيل، استدعاء إجراء، وصف قابل للتنفيذ. تتبع التقارير الثلاثة المتبقية النمط نفسه.
الخطوة 6: أضف التقارير الثلاثة الأخرى
يحتاج كل تقرير إلى شيئين: تبويب في جدولك، وAI Action جديد يضيف إليه صفوفًا.
أضف التبويبات الثلاثة
افتح جدولك (رابط Open sheet في مربع حوار Google Sheets) وأضف ثلاثة تبويبات (Unanswered، Feedback، Demos)، كل منها مع صف العناوين المعطى في تقريره أدناه.
ابنِ كل إجراء
افتح Actions & MCPs، وأضف إجراء HTTP Request مخصصًا، واملأه. الطريقة (POST) والترويسات مطابقة لإجراء العملاء المحتملين. بالنسبة إلى عنوان URL، انسخ عنوان URL الكامل مباشرة من إجراء العملاء المحتملين وغيّر اسم التبويب فقط (من Leads إلى Unanswered أو Feedback أو Demos). لأن عنوان URL هذا يحمل بالفعل معرف جدولك، لا يوجد شيء آخر لتوصيله:
https://sheets.googleapis.com/v4/spreadsheets/<your sheet ID>/values/Unanswered:append?valueInputOption=RAW
لا يتغير من تقرير إلى آخر إلا اسم التبويب، والمعاملات، والجسم، والوصف.
التقرير 2: الأسئلة غير المجاب عنها
هذا هو التقرير الأكثر فائدة. يخبرك الوكيل بالضبط أين تقصر معرفته وأي العملاء المحتملين تركتهم بلا إجابة، وهذا يمثل خارطة طريق المحتوى لديك.
لا يعمل هذا التقرير إلا إذا كان الوكيل يفتقر فعلًا إلى الإجابة، لذلك يجب أن تكون الفجوة حقيقية. عند إعداد وكيل الاختبار، اترك عمدًا الحقائق التي تريد منه الإبلاغ عنها. يعرف وكيل Tideline خططه وتكاملاته لكنه لا يعرف شيئًا عن شهادات الأمان، لذلك يكون سؤال SOC 2 فجوة حقيقية وليس حقيقة كان يستطيع ذكرها. إذا حمّلت كل حقيقة في معرفته، فلن يجد هذا التقرير شيئًا ليلتقطه.
تبويب Unanswered، صف العناوين:
| السؤال | لماذا لم نستطع الإجابة | البريد الإلكتروني | رابط المحادثة | القناة |
|---|
المعاملات:
| المعامل | مطلوب | الوصف |
|---|---|---|
question | نعم | سؤال الزائر، بكلماته نفسها. |
reason | نعم | اذكر باختصار لماذا لم تستطع الإجابة بالكامل: غير موجود في معرفتك، يحتاج إلى إنسان، أو كان الزائر غير راضٍ. |
email | لا | بريد الزائر الإلكتروني إذا شاركه؛ وإلا اتركه فارغًا. |
الجسم:
{ "values": [[ "{{question}}", "{{reason}}", "{{email}}", "{{conversation_url}}", "{{conversation_channel}}" ]] }
الوصف (رسالة التفكير: Flagging this for our team...):
استدع هذا الإجراء عندما لا تستطيع الإجابة بالكامل عن سؤال واقعي من معرفتك، أو يطلب الزائر التحدث إلى إنسان، أو يبدو الزائر غير راضٍ. إذا ذكر ردك أنك لا تملك المعلومات المطلوبة أو لا تستطيع العثور عليها أو لا تستطيع تأكيدها أو لست متأكدًا منها، فيجب عليك استدعاء هذا الإجراء في الدورة نفسها. سجّل الفجوة حتى لو قدمت إجابة جزئية. لا تستدعه للأسئلة التي أجبت عنها بالكامل، أو للتسعير (يتعامل معه إجراء العملاء المحتملين)، أو لطلبات الميزات (يتعامل معها إجراء الملاحظات).
اختُبر بسؤال أمان لا يملك الوكيل إجابة عنه:
يقول الوكيل بوضوح إنه لا يستطيع التأكيد، ويضع علامة على السؤال للفريق.
الصف الذي يكتبه في تبويب Unanswered:
الفجوة، مسجلة مع السبب ورابط للعودة إلى المحادثة. خلية Email فارغة لأن هذا الزائر لم يشارك بريدًا.
التقرير 3: الملاحظات
كل “هل تدعمون X؟” و”أتمنى أن يستطيع فعل Y” تصبح قائمة أولويات للمنتج، مع كلمات العميل نفسها مرفقة.
تبويب Feedback، صف العناوين:
| النوع | الملخص | السبب / حالة الاستخدام | البريد الإلكتروني | رابط المحادثة |
|---|
المعاملات:
| المعامل | مطلوب | الوصف |
|---|---|---|
type | نعم | أحد الخيارات: طلب ميزة، خلل، ثناء. |
summary | نعم | ملخص قصير للملاحظة بكلمات الزائر نفسها. |
context | لا | لماذا يريدها أو كيف سيستخدمها، إذا ذُكر ذلك. |
email | لا | بريد الزائر الإلكتروني إذا شاركه؛ وإلا اتركه فارغًا. |
الجسم:
{ "values": [[ "{{type}}", "{{summary}}", "{{context}}", "{{email}}", "{{conversation_url}}" ]] }
الوصف (رسالة التفكير: Passing this to our product team...):
استدع هذا الإجراء عندما يطلب زائر ميزة أو قدرة أو تكاملًا (سواء كنت تقدمه حاليًا أم لا)، أو يبلغ عن خلل أو مشكلة، أو يقدم ثناءً قويًا على المنتج. اضبط type على أحد الخيارات: طلب ميزة، خلل، ثناء. لا تستدعه للأسئلة المعلوماتية المحايدة.
اختُبر بطلب تكامل لا تقدمه الشركة:
يذكر الوكيل التكاملات الموجودة، ويرفض بوضوح، ويسجل الطلب كملاحظة.
الصف الذي يكتبه في تبويب Feedback:
كل صف مصنف (طلب ميزة أو خلل أو ثناء)، وملخص بكلمات الزائر، ومربوط بالمحادثة.
التقرير 4: طلبات العروض التوضيحية
عندما يريد شخص التحدث صراحة، التقط صفًا منظمًا وجاهزًا للمبيعات.
تبويب Demos، صف العناوين:
| الاسم | البريد الإلكتروني | الشركة | حالة الاستخدام | رابط المحادثة |
|---|
المعاملات:
| المعامل | مطلوب | الوصف |
|---|---|---|
name | لا | اسم الزائر إذا شاركه؛ وإلا اتركه فارغًا. |
email | نعم | أفضل بريد إلكتروني يمكن للفريق الوصول إليه عليه. |
company | لا | اسم شركته إذا شاركه. |
use_case | لا | ما يريد تحقيقه أو مناقشته، إذا ذُكر. |
الجسم:
{ "values": [[ "{{name}}", "{{email}}", "{{company}}", "{{use_case}}", "{{conversation_url}}" ]] }
الوصف (رسالة التفكير: Setting up your demo request...):
استدع هذا الإجراء فقط عندما يطلب الزائر صراحة حجز عرض توضيحي أو جدولة مكالمة أو التحدث إلى مندوب مبيعات. اجمع بريده الإلكتروني أولًا، واسمه وشركته إذا قدمهما. لا تستدعه لمجرد أن شخصًا شارك بريدًا إلكترونيًا أو سأل عن التسعير؛ استخدم إجراء العملاء المحتملين للاهتمام العام بالشراء.
اختُبر بطلب عرض توضيحي صريح:
يؤكد الوكيل العرض التوضيحي ويسجل الاسم والشركة ومحور الاهتمام.
الصف الذي يكتبه في تبويب Demos:
صف منظم وجاهز للمبيعات: من هو، وأين يعمل، وما الذي يريد رؤيته.
تكتب التقارير الأربعة كلها إلى جدول واحد، بتبويب لكل تقرير، وتمتلئ أثناء حدوث المحادثات.
كيفية ضبط التقارير
لم تعمل التقارير أعلاه جيدًا من المحاولة الأولى، وعملية إصلاحها هي الجزء الأهم الذي يجب نسخه، لأنها الطريقة التي ستجعل بها تقاريرك صحيحة. الحلقة واحدة كل مرة:
- مثّل دور الزائر. افتح AI Preview وأجرِ المحادثة الدقيقة التي سيجريها زائر حقيقي.
- اقرأ النتيجة، وليس الرد فقط. افتح تبويب الجدول وسجل استدعاءات الإجراء (كلاهما موضح في الخطوة 5) وانظر إلى الصف الذي كُتب والمعاملات التي أرسلها الوكيل فعلًا.
- حدد الفجوة. قارن ما سُجل بما كان ينبغي تسجيله.
- غيّر شيئًا واحدًا. عدّل وصف الإجراء (فهو يتحكم في وقت تشغيل الإجراء)، أو كتلة النص التوجيهي، لكن واحدًا فقط في كل مرة حتى تعرف ما الذي غيّر النتيجة.
- أعد تشغيل المحادثة نفسها وتأكد أن الصف أصبح صحيحًا الآن.
كان تغييران من تلك الحلقة هما الأهم، وكلاهما جاء مباشرة من صف سيئ:
التغييران المهمان، وكل منهما وُجد بتشغيل محادثة وقراءة الصف الذي أنتجته.
الإصلاح 1: بدأ إجراء العميل المحتمل مبكرًا جدًا. ربط الوصف الأول المحفز بالسؤال: “استدع هذا عندما يسأل الزائر عن التسعير أو الخطط أو التكلفة.” عند تشغيل محادثة تسعير، أجاب الوكيل وسجل العميل المحتمل في الدورة نفسها، قبل أن يقدم الزائر بريدًا إلكترونيًا. وصل الصف على شكل [ (empty), "Growth plan cost", link, simulation ]: عميل محتمل بلا طريقة للمتابعة. كان الإصلاح هو نقل المحفز من السؤال إلى تفصيل الاتصال. يقول الوصف الآن ألا يستدعي الإجراء إلا في الدورة التي يكون فيها الزائر قد قدم بريدًا إلكترونيًا بالفعل، ومعامل email محدد كـ مطلوب. عند إعادة تشغيل المحادثة نفسها، أجاب الوكيل عن سؤال التسعير، ولم يسجل شيئًا في تلك الدورة، وكتب الصف فقط بعد أن شارك الزائر عنوانًا.
الإصلاح 2: بقيت فجوة المعرفة صامتة. كان تقرير الأسئلة غير المجاب عنها هو الأصعب في التشغيل. الوصف الأول (“استدع هذا إذا لم تستطع الإجابة عن سؤال”) لم يفعل تقريبًا شيئًا: عند السؤال هل المنتج حاصل على شهادة SOC 2، قال الوكيل بشكل صحيح إنه لا يستطيع التأكيد ووجّه الزائر إلى الفريق، لكنه لم يسجل شيئًا إطلاقًا. بالنسبة إلى النموذج، يبدو قول “لا أعرف” وكأنه إجابة كاملة، لذلك لا تبقى إشارة تدفعه إلى تسجيل الفجوة أيضًا. كان الإصلاح هو صياغة حاسمة: يقول الوصف الآن إنه إذا ذكر الرد أن الوكيل لا يستطيع التأكيد أو ليس متأكدًا، فيجب عليه MUST استدعاء الإجراء في الدورة نفسها. بهذا أنتج سؤال SOC 2 نفسه كلًا من الإجابة الصادقة و صفًا في تبويب Unanswered. يبقى هذا التقرير الأكثر اعتمادًا على الحكم بين الأربعة، لأنه يعتمد على ملاحظة الوكيل لفجوته الخاصة بدلًا من إشارة صريحة من الزائر؛ ويعمل بأعلى موثوقية عندما يطلب الزائر أيضًا المتابعة معه.
ما الذي تفعله كتلة النص التوجيهي، وما الذي لا تفعله. تحدد أوصاف الإجراءات متى يعمل كل تقرير. تؤدي كتلة النص التوجيهي من الخطوة 4 ثلاث وظائف منفصلة: تخبر الوكيل أن التقارير ليست اختيارية، وتفصل الحالات المتداخلة (سؤال التسعير عميل محتمل، وليس سؤالًا غير مجاب عنه)، وتضع سياسة طلب البريد الإلكتروني قبل تسجيل عميل محتمل. ملاحظة صريحة من الاختبار: هل يطلب الوكيل البريد الإلكتروني بمبادرة منه عندما يُظهر زائر اهتمامًا دون تقديمه يختلف من تشغيل إلى آخر، لذلك لا تعتمد عليه. الضمان بألا تحصل أبدًا على عميل محتمل ببريد فارغ هو معامل email المطلوب مع صياغة المحفز، وليس النص التوجيهي.
الاختبار على نطاق واسع باستخدام Simulation
بعد أن يعمل التقرير، تتيح لك Simulation (تحت Testing في الشريط الجانبي) التحقق من أنه لا يتراجع. تعطيها مجموعة بيانات من رسائل الاختبار، فتُعيد تشغيلها كلها عبر وكيلك، ويقيّم مقيّم (LLM يمنح كل رد درجة مقابل معيار تكتبه، على مقياس من 1 إلى 5) الإجابات نيابة عنك. إنها الأداة المناسبة لاكتشاف الانخفاضات في جودة ما يقوله الوكيل عبر حالات كثيرة دفعة واحدة.
تشغيل Simulation على سيناريوهات التقارير الأربعة. كل صف هو رسالة اختبار ورد الوكيل ودرجة المقيّم ومنطقه. هنا نجحت الأربعة كلها بدرجة 5 من 5.
حد مهم واحد: لا يرى المقيّم إلا نص الرد، وليس جدول البيانات. لا يستطيع تأكيد أن الصف الصحيح وصل إلى التبويب الصحيح. لذلك استخدم الجدول وسجل استدعاءات الإجراء من الخطوة 5، وهو بالضبط ما تعتمد عليه حلقة الضبط أعلاه.
ملاحظة تشغيلية واحدة. تستخدم كل محادثة اختبار رسائل الذكاء الاصطناعي الشهرية لوكيلك. إذا أعاد الوكيل فجأة إشعار “غير متاح” في منتصف الاختبار، فقد وصلت إلى الحد الأقصى، وليس هذا خللًا.
الانتقال إلى التشغيل الفعلي
بعد تشغيل الإجراءات الأربعة ووضع كتلة النص التوجيهي، انشر وكيلك على قنواته الحقيقية. لا يوجد شيء آخر لتكوينه: تعمل الإجراءات نفسها لأداة الويب وSlack وWhatsApp والبقية، ويسجل عمود Channel مصدر كل صف. يراقب فريقك الجدول وهو يمتلئ في الوقت الحقيقي، ويرتبط كل صف مباشرة بالمحادثة التي أنتجته.
الأسئلة الشائعة
هل أحتاج إلى أي كود لربط وكيل ذكاء اصطناعي بـ Google Sheets؟
لا. يتم اتصال Google Sheets بنقرة واحدة، وكل وصف إجراء ونص توجيهي وجسم طلب تحتاج إليه متوفر في هذا الدليل ككتلة جاهزة للنسخ واللصق. لن تكتب أي كود أو تستضيفه.
هل أحتاج إلى Zapier أو webhook لربط وكيل الذكاء الاصطناعي بـ Google Sheets؟
لا. يتصل Quickchat AI بـ Google Sheets مباشرة عبر AI Action، وهو طلب HTTP أصلي يجريه الوكيل أثناء المحادثة. لا يوجد Zapier، ولا خدمة webhook، ولا مهندس في الوسط. تنشئ نقرة واحدة الجدول وأول إجراء تسجيل لك.
هل بيانات Google Drive الخاصة بي آمنة؟
نعم. يطلب التكامل نطاق OAuth باسم drive.file فقط، وهو يمنح الوصول حصريًا إلى الملفات التي ينشئها التطبيق نفسه، مثل الجدول الذي ينشئه لك. لا يمكنه قراءة أي شيء آخر في Drive أو تغييره، ولا يتم كشف رمز الوصول لنموذج الذكاء الاصطناعي أبدًا.
هل يمكنني تسجيل أشياء غير العملاء المحتملين؟
نعم. التكامل هو مسجل عام الغرض. إجراء البدء مضبوط مسبقًا للعملاء المحتملين لأن هذه هي الحالة الشائعة، لكن الأعمدة ليست إلا جسم الإجراء مع صف العناوين في الجدول، لذلك يمكنك تعديلها لتسجيل الأسئلة غير المجاب عنها أو طلبات الميزات أو حجوزات العروض التوضيحية أو أي شيء آخر، كما يوضح هذا الدليل.
على أي قنوات يعمل التسجيل إلى Google Sheets؟
على جميعها. تعمل الإجراءات نفسها أينما كان وكيلك منشورًا (أداة الويب وSlack وWhatsApp وغير ذلك)، ويسجل عمود Channel مصدر كل صف.
هل توجد تكلفة، وهل يستخدم الاختبار رسائل الذكاء الاصطناعي الخاصة بي؟
يمكنك البدء مجانًا، ولا يضيف اتصال Google Sheets نفسه أي تكلفة. كل محادثة، بما في ذلك المحادثات التي تشغلها في AI Preview وSimulation أثناء الاختبار، تُحتسب ضمن رسائل الذكاء الاصطناعي الشهرية في خطتك، لذلك يستهلك الاختبار المكثف من الحصة نفسها مثل المحادثات الحية.
ماذا لو حذفت إجراء التسجيل الابتدائي؟
يمكنك استعادته. افتح Add Action، واختر Google Sheets مرة أخرى، واستخدم Reconnect: يعيد التكامل تشغيل إعداد النقرة الواحدة، مما يعيد إنشاء إجراء log_lead_to_google_sheet ويعيد استخدام جدولك الحالي (لا ينشئ جدولًا ثانيًا أبدًا). عندما تكون متصلًا بالفعل، يعرض مربع حوار الاتصال خيار إعادة الاتصال هذا مباشرة.
إذا اختفى إجراء البدء، يوضح مربع الحوار ذلك ويعرض مسارًا بنقرة واحدة لإعادة إنشائه. يبقى جدولك متصلًا.
للاطلاع على مثال تطبيقي لمجتمع منتج، اتبع درس ملاحظات Discord إلى Google Sheets. يسجل الإرسالات الصريحة لمراجعة الفريق، ويميز القيود الموثقة عن الإجابات المفقودة، ويختبر محتوى السجل إضافة إلى الرد.
الملخص
AI Action هو طلب HTTP موصوف، وصف Google Sheet هو طلب من هذا النوع. اربط Google مرة واحدة، وشكّل إجراء البدء ليصبح تقرير العملاء المحتملين، والصق كتلة التقارير، ثم أضف تبويبًا وإجراءً لكل تقرير إضافي تريده. الأعمدة ملكك: إنها جسم الإجراء، وليست قالبًا ثابتًا. الإعدادات والنص التوجيهي في هذا المقال هي نفسها التي استُخدمت لإنتاج الصفوف المعروضة هنا، لذلك يمكنك نسخها، واستبدال تفاصيل منتجك، وتشغيل الاختبارات نفسها للتأكد من أن وكيلك يعمل قبل وضعه أمام زوار حقيقيين.
احتفظ بهذا الدليل في مفضلاتك. المرجع المحدّث باستمرار لـ AI Actions موجود في الوثائق على docs.quickchat.ai/ai-agent/actions، ويحتوي مرجع API لـ AI Actions على قائمة الحقول الكاملة.