هنگامی که از طریق نمایندگان Business Messages با کاربران تعامل می کنید، بهترین شیوه های زیر را در نظر داشته باشید.
اطلاعات حساس را ارائه یا درخواست نکنید
اجتناب از محتوای حساس در طول چت، اطلاعات شما و مشتریانتان را ایمن نگه می‌دارد. اطلاعات حساس شامل، اما محدود نمی شود
- شماره های کارت اعتباری
- تامین اجتماعی، پاسپورت یا سایر شماره های شناسایی دولتی
- اعتبار ورود، مانند رمز عبور
به سرعت به کاربران پاسخ دهید
زمان پاسخ آهسته یا غیرمنطقی به پیام های کاربر تجربه بدی را برای مشتریان شما ایجاد می کند. اطمینان حاصل کنید که زیرساخت پاسخ خود را طوری طراحی کرده اید که به طور مداوم پاسخ های به موقع به پیام های کاربر ارائه دهد.
حتی بدتر از پاسخ آهسته، عدم پاسخگویی است. اطمینان حاصل کنید که کاربران همیشه بدون توجه به بارگذاری پیام شما، به پیام های خود پاسخ دریافت می کنند. به عنوان مثال، اگر کارکنان زنده در دسترس نیستند، یک پیام خودکار برای تأیید کاربر ارسال کنید و تخمینی از زمان انتظار پاسخ کامل کاربر را درج کنید.
گوگل زمان پاسخگویی (TTR) بین پیام ها را اندازه گیری می کند. اگر نماینده برند در پاسخگویی به مشتریان کند باشد، گوگل دکمه‌های پیام‌رسانی برند را حذف می‌کند.
وقتی اتوماسیون نمی تواند درخواست ها را برآورده کند، به انسان ها بسپارید
کاربران وقتی که اتوماسیون به درستی به آنها پاسخ نمی دهد، ناامید می شوند. به همین دلیل است که همه عواملی که از نقاط ورودی مدیریت شده توسط Google راه اندازی می شوند (به استثنای نقطه ورودی Google Ads) باید نمایندگان انسانی داشته باشند که بتوانند مکالمات را در حالی که اتوماسیون نمی تواند انجام دهد. قبل از راه‌اندازی، باید نوع تعامل نماینده خود را طوری تنظیم کنید که نمایندگان انسانی را نیز شامل شود.
هنگامی که اتوماسیون نمی تواند درخواست کاربر را دو بار متوالی برآورده کند، بهتر است پیامی با پیشنهاد درخواست نماینده زنده ارسال کنید.
وقتی کاربر روی این پیشنهاد ضربه می‌زند، نماینده شما رویدادی را که نماینده مستقیم درخواست کرده است دریافت می‌کند. نماینده شما باید با واگذار کردن مکالمه به یک نماینده انسانی پاسخ دهد تا کاربر کمک مورد نیاز خود را دریافت کند.
نیازی نیست که انسان ها 24 ساعته در دسترس باشند. در دسترس بودن نماینده خود را تنظیم کنید تا کاربران بدانند چه زمانی می توانند منتظر پاسخ انسانی باشند.
احراز هویت کاربران با OAuth
برای تأیید هویت کاربران و ارائه اطلاعات شخصی به آنها، کاربران را با سیستم های پشتیبان از طریق OAuth احراز هویت کنید. احراز هویت با OAuth باعث می‌شود که عوامل به سرعت به داده‌های کاربر دسترسی داشته باشند و از گنجاندن اطلاعات حساس (مانند نام کاربری یا رمز عبور) در مکالمه توسط کاربران یا نمایندگان جلوگیری می‌کند. به تأیید اعتبار با OAuth مراجعه کنید.
CSAT را در پیام‌های تجاری اندازه‌گیری کنید
پیام‌های تجاری امتیازات رضایت مشتری (CSAT) را با نظرسنجی‌ها مستقیماً در تجربیات پیام‌رسانی اندازه‌گیری می‌کند. برای جلوگیری از دریافت نظرسنجی های متعدد توسط کاربران، از عملکرد نظرسنجی پیام های تجاری استفاده کنید. تکنیک های اندازه گیری CSAT خود را اجرا نکنید.
در موضوع بمانید
پیام های ناخواسته یا بی ربط به مکالمه فعلی ارسال نکنید. مثلا،
- پیام هایی در مورد یک محصول یا خدمات غیر مرتبط با درخواست اصلی
- پیام های تکراری بدون پاسخ کاربر
- پیام های بیش از حد طولانی یا استفاده بیش از حد از ایموجی ها و URL ها
وقتی شناسه مکان در دسترس است، از آن استفاده کنید
برای نقاط ورودی مبتنی بر مکان، پیام ها ممکن است حاوی یک placeId در محموله زمینه باشند. می‌توانید از آن برای ارائه اطلاعاتی استفاده کنید که ممکن است کاربر درباره آن بپرسد، مانند موجودی در یک مکان خاص. شناسه مکان به طور placeId مکانی را در پایگاه داده Google Places و در پلتفرم Google Maps شناسایی می‌کند.
حتی اگر فقط با نقاط ورودی مبتنی بر مکان راه‌اندازی می‌کنید، مطمئن شوید که یک استراتژی برای موقعیت‌هایی که مکان placeId وجود ندارد، اجرا کنید. اگرچه معمول نیست، اما شرایطی وجود دارد که یک placeId ، در میان سایر داده های متنی، به وب هوک شما منتقل نمی شود.
اجرای تلاش های مجدد با عقب نشینی نمایی
هنگام فراخوانی هر API، ممکن است یک تماس به دلیل مشکلات زیرساخت، اضافه بار سرویس، محدودیت های QPS و سایر خطاها با شکست مواجه شود. برای بازیابی دلپذیر از تماس های ناموفق API، تلاش های مجدد را با عقب نشینی نمایی اجرا کنید.
با استفاده از تلاش های مجدد با عقب نشینی نمایی، زیرساخت شما به طور خودکار
- یک تماس API ناموفق را شناسایی می کند
- مدت زمان انتظار اولیه و حداکثر تعداد تلاش های مجدد را تنظیم می کند
- برای مدت انتظار مکث می کند
- تماس API را دوباره امتحان می کند
پاسخ تماس API را ارزیابی می کند:
- در صورت موفقیت، با مرحله بعدی در گردش کار ادامه دهید
- در صورت شکست، مدت انتظار افزایش می یابد و به مرحله 3 باز می گردد
- اگر پس از حداکثر تعداد دفعات تکرار، شکستی رخ دهد، وارد حالت شکست می شود
مدت زمان انتظار ایده‌آل و حداکثر تعداد ایده‌آل تلاش‌های مجدد بسته به موارد استفاده متفاوت است. این اعداد را بر اساس نیازهای تاخیر زیرساخت و گردش کار خود تعیین کنید.
پیام های دریافتی تکراری را بررسی کنید
وقتی پیام‌های دریافتی کاربران را بررسی می‌کنید و به آنها پاسخ می‌دهید، messageId را بررسی کنید و بررسی کنید که قبلاً پیام را دریافت نکرده‌اید و به آن پاسخ نداده‌اید.
در سیستم های توزیع شده، دو راه برای ارسال پیام وجود دارد: حداکثر یک بار و حداقل یک بار. در سیستم‌های «حداکثر یک بار»، سیستم یک‌بار پیام ارسال می‌کند، اما اگر خطاهای شبکه یا ارتباطی در مسیر وجود داشته باشد، ممکن است پیام دریافت نشود. با سیستم‌های «حداقل یک بار»، سیستم ممکن است چندین بار پیامی ارسال کند، اما پیام را می‌توان حتی در صورت وجود خطاهای شبکه یا ارتباط دریافت کرد.
Business Messages از یک سیستم "حداقل یک بار" استفاده می کند. در حالی که این می‌تواند منجر به تکرار پیام‌های دریافتی شود، حذف کردن پیام‌ها با ردیابی رشته‌های messageId است. اگر قبلاً پیامی دریافت کرده‌اید، می‌توانید پیام‌های دیگری را که با همان messageId دریافت می‌کنید، نادیده بگیرید.