معماری عامل‌های هوش مصنوعی برای خدمات مشتری تجارت الکترونیک در Shopify، Gorgias، Zendesk و موتورهای مستقل مدیریت سفارش

معماری عامل‌های هوش مصنوعی برای خدمات مشتری تجارت الکترونیک، بسته به اینکه زیرساخت تجاری Shopify باشد، یک مرکز کمک‌رسانی مبتنی بر Gorgias، یک استقرار سازمانی مبتنی بر Zendesk، یا یک موتور مدیریت سفارش مستقل مانند NetSuite، Brightpearl، یا یک ERP سفارشی، اساساً متفاوت است. هر محیط مدل‌های داده‌ای، الگوهای یکپارچه‌سازی، ویژگی‌های تأخیر و حالت‌های شکست متمایزی دارد. عامل‌هایی که بدون در نظر گرفتن این تفاوت‌ها معماری شده‌اند، یا راه‌اندازی نمی‌شوند یا مقیاس‌پذیر نیستند، در حالی که عامل‌هایی که با الگوهای آگاه از پلتفرم معماری شده‌اند، نتایج قوی و ثابتی در هر چهار محیط تولید می‌کنند.

انتخاب معماری که هر چیزی را در پایین‌دست تعیین می‌کند

مهم‌ترین تصمیم معماری در ساخت عامل‌هایی که در این پلتفرم‌ها کار می‌کنند، این است که آیا عامل، پلتفرم تجاری را منبع اصلی حقیقت می‌داند یا یکی از چندین سیستم یکپارچه که از طریق یک لایه داده میانی، حالت را به اشتراک می‌گذارند. این انتخاب، نحوه رفتار هر جزء پایین‌دستی را تحت بار، در حین استثناها و در طول به‌روزرسانی‌های پلتفرم تعیین می‌کند.

معماری‌های بومی Shopify معمولاً Shopify را منبع اصلی حقیقت می‌دانند، با عاملی که داده‌های سفارش، مشتری و تکمیل را مستقیماً از طریق Storefront و Admin API می‌خواند. این رویکرد تأخیر کم و سازگاری قوی در مسیر اصلی تولید می‌کند اما عامل را در اوج دوره به محدودیت‌های نرخ API Shopify و به تغییرات مدل داده بین نسخه‌های API در معرض خطر قرار می‌دهد.

معماری‌های مبتنی بر سیستم‌های پشتیبانی (Helpdesk)، از جمله استقرارهای Gorgias و Zendesk، معمولاً Helpdesk را منبع اصلی حقیقت مکالمه و پلتفرم تجاری را به عنوان یکی از بسیاری از سیستم‌های متصل در نظر می‌گیرند. این امر پیوستگی قوی مکالمه را ایجاد می‌کند اما تأخیر همگام‌سازی در داده‌های تجاری را به همراه دارد که وقتی خریداران انتظار به‌روزرسانی‌های ردیابی تقریباً بلادرنگ را دارند، مشکل‌ساز می‌شود.

معماری‌های مدیریت سفارش مستقل، که در برندهایی که با NetSuite، Brightpearl یا ERP‌های سفارشی کار می‌کنند رایج است، معمولاً موتور مدیریت سفارش را منبع اصلی حقیقت می‌دانند و داده‌های مکالمه را برای گزارش‌دهی یکپارچه به OMS می‌کشند. این امر شفاف‌ترین گزارش‌دهی عملیاتی را تولید می‌کند اما به بیشترین سرمایه‌گذاری مهندسی نیاز دارد تا عامل در کانال‌های مشتری‌محور پاسخگو باشد.

این انتخاب را نمی‌توان به تعویق انداخت. عامل‌هایی که بدون انجام صریح این انتخاب ساخته شده‌اند، به سمت هر پلتفرمی که آسان‌ترین مسیر یکپارچه‌سازی را دارد، سوق پیدا می‌کنند، که به ندرت انتخابی است که بهترین نتایج بلندمدت را به همراه دارد.

معماری بومی Shopify برای برندهایی که بر روی پشته Shopify کار می‌کنند

برای برندهایی که بر روی Shopify Plus یا Shopify Advanced کار می‌کنند و بیشتر پشته تجاری آنها در اکوسیستم Shopify قرار دارد، کارآمدترین معماری عامل، Shopify را منبع اصلی حقیقت می‌داند و داده‌های تجاری را مستقیماً از طریق GraphQL Admin API و Storefront API می‌خواند. این معماری پیچیدگی یکپارچه‌سازی را به حداقل می‌رساند و پایین‌ترین تأخیر ممکن را در جستجوی سفارش، مشتری و تکمیل تولید می‌کند.

الگوی پیاده‌سازی از وب‌هوک‌های Shopify برای حفظ جریان رویداد تقریباً بلادرنگ در لایه استدلال عامل استفاده می‌کند، که به عامل اجازه می‌دهد در عرض چند ثانیه پس از وقوع، به رویدادهای تکمیل، به‌روزرسانی‌های سفارش و تغییرات مشتری پاسخ دهد. قابلیت اطمینان وب‌هوک خوب است اما کامل نیست، بنابراین معماری‌های تولید شامل وظایف تطبیق هستند که به صورت دوره‌ای کامل بودن وب‌هوک را در برابر API تأیید می‌کنند.

مدیریت محدودیت نرخ توجه ویژه‌ای را می‌طلبد. محدودیت‌های نرخ API Shopify برای الگوهای استفاده معمول برنامه تنظیم شده است و می‌تواند زمانی که یک عامل حجم بالایی از تماس‌ها را که هر یک برای مونتاژ زمینه به چندین فراخوانی API نیاز دارند، محدودکننده شود. معماری‌های تولید شامل لایه‌های کشینگ هستند که بخش عمده‌ای از ترافیک خواندن را جذب می‌کنند، با سیاست‌های TTL که با نیازهای تازگی هر نوع داده تنظیم شده‌اند.

معاوضه این است که معماری‌های بومی Shopify فرضیات مدل داده Shopify را به ارث می‌برند، که می‌تواند زمانی که برندها در چندین کانال فروش، چندین منطقه با مجموعه‌های موجودی متفاوت، یا عملیات ترکیبی خرده‌فروشی و آنلاین فعالیت می‌کنند، اصطکاک ایجاد کند. برندهایی که با این الگوها مواجه می‌شوند، اغلب با مقیاس‌گذاری، به سمت معماری‌های مبتنی بر Helpdesk یا OMS مهاجرت می‌کنند.

معماری مبتنی بر Gorgias برای برندهای متوسط Shopify

برندهایی که Gorgias را به عنوان Helpdesk اولیه خود اجرا می‌کنند، معمولاً عامل‌هایی می‌سازند که Gorgias را منبع اصلی حقیقت مکالمه می‌دانند و از ماکروها، اتوماسیون و موتور گردش کار Gorgias به عنوان لایه ارکستراسیون استفاده می‌کنند. این معماری انتخاب طبیعی برای برندهایی است که قبلاً در Gorgias سرمایه‌گذاری کرده‌اند و نتایج قوی را زمانی که پیچیدگی عملیاتی برند در الگوهای گردش کار Gorgias جای می‌گیرد، تولید می‌کند.

الگوی یکپارچه‌سازی از یکپارچه‌سازی‌های HTTP Gorgias و اتوماسیون ماکرو برای فعال کردن فراخوانی‌های API خارجی به پلتفرم تجاری، شبکه حمل‌ونقل و پردازشگر پرداخت استفاده می‌کند. استدلال عامل یا در ویژگی‌های AI بومی Gorgias اجرا می‌شود یا از طریق خدمات خارجی که پاسخ‌ها را برای موتور ماکرو ارسال می‌کنند.

نقطه قوت این معماری سادگی عملیاتی است. تیم‌های خدمات مشتری قبلاً رابط، گزارش‌دهی و الگوهای گردش کار Gorgias را می‌فهمند، بنابراین عامل به عنوان یک توسعه طبیعی از عملیات موجود احساس می‌شود تا یک سیستم جداگانه که باید یاد گرفته شود. سربار آموزشی در مقایسه با پلتفرم‌های عامل مستقل به طور قابل توجهی کاهش می‌یابد.

محدودیت سقف موتور گردش کار است. موتور اتوماسیون Gorgias گردش کارهای خطی و با شاخه‌های کم را به خوبی مدیریت می‌کند اما با مدیریت استثناهای عمیقاً شاخه‌ای که چندین سیستم خارجی را شامل می‌شود، مشکل دارد. برندهایی که به این سقف می‌رسند، یا ارکستراسیون خارجی می‌سازند که به Gorgias فراخوانی می‌کند یا به معماری‌هایی مهاجرت می‌کنند که Gorgias را به عنوان یکی از چندین سیستم یکپارچه در نظر می‌گیرند و نه هسته ارکستراسیون.

معماری Zendesk-محور برای عملیات سازمانی

برندهایی که Zendesk را به عنوان میز کمک اولیه خود اداره می‌کنند، معمولاً عامل‌هایی را با استفاده از پلتفرم Sunshine Conversations Zendesk همراه با Answer Bot و خدمات هماهنگ‌سازی خارجی می‌سازند. این معماری بزرگترین عملیات در صنعت را اداره می‌کند و نتایج ثابتی را در استقرارهای جهانی چندزبانه تولید می‌کند.

الگوی یکپارچه‌سازی به سطح API گسترده Zendesk متکی است تا وضعیت تیکت، تخصیص عامل و تاریخچه مکالمه را حفظ کند، در حالی که خدمات خارجی، استدلال، یکپارچه‌سازی پلتفرم تجاری و گردش کار استثنا را بر عهده دارند. لایه Sunshine Conversations انتزاع کانال را مدیریت می‌کند و به عامل اجازه می‌دهد در چت وب، برنامه تلفن همراه، پیامک، واتساپ و ایمیل به طور یکسان پاسخ دهد.

نقطه قوت این معماری، قابلیت اطمینان سازمانی است. زیرساخت Zendesk حداکثر بارهای اوج را که سایر پلتفرم‌ها با آن مشکل دارند، مدیریت می‌کند و حضور جهانی به معنای تأخیر ثابت برای مشتریان در هر بازار اصلی است. برندهایی که در ده‌ها کشور با صدها عامل فعالیت می‌کنند، معمولاً Zendesk را به طور خاص برای این مقیاس و قابلیت اطمینان انتخاب می‌کنند.

معاوضه، پیچیدگی و هزینه پیاده‌سازی است. معماری‌های مبتنی بر Zendesk معمولاً 9 تا 18 ماه طول می‌کشد تا به بلوغ تولید برسند و مجوزدهی به ازای هر عامل همراه با ماژول‌های اضافی مختلف، سالیانه مقادیر قراردادی را تولید می‌کند که فقط در مقیاس معنی‌دار منطقی است. برندهایی که به دنبال زمان عرضه سریع‌تر به بازار هستند، معمولاً جایگزین‌ها را ارزیابی می‌کنند.

معماری OMS-محور برای برندهایی با پیچیدگی عملیاتی

برندهایی که موتورهای مدیریت سفارش مستقل مانند NetSuite، Brightpearl، Aptos، Manhattan یا ERP‌های سفارشی را اجرا می‌کنند، معمولاً عامل‌هایی می‌سازند که OMS را منبع اصلی حقیقت می‌دانند و داده‌های مکالمه را برای گزارش‌دهی عملیاتی یکپارچه به OMS می‌کشند. این معماری انتخاب طبیعی برای برندهایی است که پیچیدگی عملیاتی آنها از آنچه معماری‌های مبتنی بر Helpdesk به نحو احسن می‌توانند اداره کنند، فراتر می‌رود.

الگوی یکپارچه‌سازی از OMS به عنوان ذخیره‌ساز متعارف برای وضعیت سفارش، مشتری، موجودی و تکمیل استفاده می‌کند، در حالی که استدلال عامل به عنوان یک سرویس خارجی اجرا می‌شود که از طریق API‌ها یا صف‌های پیام به OMS می‌خواند و می‌نویسد. کانال‌های مشتری‌محور از طریق هر Helpdesk یا زیرساخت چت که برند ترجیح می‌دهد، متصل می‌شوند، با وضعیت OMS که به جای نگهداری جداگانه، به آن کانال‌ها جریان می‌یابد.

نقطه قوت این معماری، انسجام عملیاتی است. هر اقدام تجاری، خواه توسط عامل، یک نماینده خدمات انسانی، یک کارگر انبار یا یک عضو تیم مالی انجام شود، در همان وضعیت متعارف با همان مدل داده و همان مسیر حسابرسی فرود می‌آید. این امر به از بین بردن واگرایی داده‌ها که برندهایی که در چندین سیستم قطع شده کار می‌کنند، را آزار می‌دهد، کمک می‌کند.

محدودیت، سرمایه‌گذاری مهندسی است. معماری‌های مبتنی بر OMS به بیشترین کار یکپارچه‌سازی اولیه و بیشترین نگهداری مداوم نیاز دارند، زیرا عامل باید به عنوان یک شهروند درجه یک در مدل داده OMS شرکت کند نه به عنوان یک سیستم خارجی که گهگاهی همگام‌سازی می‌شود. برندهایی که ظرفیت مهندسی اختصاصی ندارند، اغلب در حفظ این معماری‌ها با گذشت زمان مشکل دارند.

طراحی لایه استدلال عامل برای پلتفرم-خنثی بودن

الگویی که در هر چهار رویکرد معماری ظهور کرده است، اهمیت طراحی لایه استدلال عامل به گونه‌ای است که پلتفرم-خنثی باشد، با آداپتورهای مخصوص پلتفرم که جزئیات یکپارچه‌سازی را بر عهده دارند. این جداسازی، سیستم‌هایی بسیار بادوام‌تر از کوپلینگ محکم استدلال به یک مدل داده پلتفرم خاص تولید می‌کند.

لایه استدلال، طبقه‌بندی قصد، حالت مکالمه، منطق تصمیم‌گیری و تولید پاسخ را با استفاده از یک مدل داده پلتفرم-خنثی که شامل سفارشات، مشتریان، محموله‌ها، پرداخت‌ها و مکالمات به عنوان موجودیت‌های درجه اول است، مدیریت می‌کند. آداپتورها بین این مدل خنثی و مدل‌های داده خاص Shopify، Gorgias، Zendesk، NetSuite، یا هر پشته تجاری که برند عملیات می‌کند، ترجمه می‌کنند.

این الگو مزایای فوری در کیفیت کد، قابلیت آزمایش و سرعت تیم را به همراه دارد. مزایای میان‌مدت را در انعطاف‌پذیری ایجاد می‌کند، زیرا برندها می‌توانند بدون بازسازی استدلال عامل، پلتفرم‌های زیرین را تغییر دهند. مزایای بلندمدت را در اهرم فروشنده ایجاد می‌کند، زیرا برندهایی با استدلال قابل تعویض می‌توانند قراردادهای پلتفرم را با جایگزین‌های معتبر دوباره مذاکره کنند.

برندهایی که به این شکل ساخته‌اند، مهاجرت‌های پلتفرم را در عرض هفته‌ها به جای فصل‌ها مدیریت می‌کنند. برندهایی که به این شکل ساخته‌اند، اغلب خود را در تصمیمات پلتفرمی که سال‌ها قبل گرفته شده و دیگر متناسب با نیازهای عملیاتی آنها نیست، گرفتار می‌بینند.

مدیریت شکاف قابلیت اطمینان وب‌هوک و API در سراسر پلتفرم‌ها

تحویل وب‌هوک و در دسترس بودن API هر پلتفرم تجاری دارای شکاف قابلیت اطمینان بین 99.5 تا 99.9 درصد است. در مقیاس میلیون سفارش، این شکاف به تعداد قابل توجهی از تماس‌ها ترجمه می‌شود که در آن عامل هنگام نیاز به پاسخ، داده‌های فعلی را ندارد. معماری‌های تولید این شکاف را به صراحت مدیریت می‌کنند به جای اینکه وانمود کنند وجود ندارد.

الگویی که کار می‌کند، لایه‌بندی منطق تطبیق بر روی جریان‌های رویداد وب‌هوک است، با کشیدن کامل وضعیت به صورت دوره‌ای که هر رویدادی را که تحویل وب‌هوک از دست داده است، می‌گیرد. تطبیق در فواصل زمانی تنظیم شده با الزامات تازگی هر نوع داده اجرا می‌شود، با وضعیت سفارش که هر چند دقیقه یکبار تطبیق داده می‌شود و موجودی که در دوره‌های اوج هر چند ثانیه یکبار تطبیق داده می‌شود.

معماری‌های تولید همچنین شامل قطع‌کننده‌های مدار هستند که تشخیص می‌دهند آیا API یک پلتفرم تخریب شده است و عامل را به پاسخ‌های بازگشتی که تخریب را تأیید می‌کنند، تغییر می‌دهند به جای اینکه با اطمینان داده‌های قدیمی را گزارش دهند. این الگوی است که از بدترین تجربه‌های مشتری در طول حوادث پلتفرم جلوگیری می‌کند.

سرمایه‌گذاری در قابلیت اطمینان وب‌هوک و قطع‌کننده‌های مدار API در طول عملیات عادی بیش از حد به نظر می‌رسد و در طول حوادث اجتناب‌ناپذیر پلتفرم کاملاً حیاتی است. برندهایی که این سرمایه‌گذاری را انجام داده‌اند، بدون آسیب جدی به رتبه، از حوادث پلتفرم عبور می‌کنند. برندهایی که این کار را انجام نداده‌اند، با هر حادثه‌ای کاهش رتبه را مشاهده می‌کنند.

ساخت الگوی مدیریت استثنا که در هر پلتفرمی کار می‌کند

مدیریت استثنا جایی است که معماری‌های مخصوص پلتفرم یا موفق می‌شوند یا به طور آشکار شکست می‌خورند. الگویی که در Shopify، Gorgias، Zendesk و محیط‌های مستقل OMS کار می‌کند، یک لایه مدیریت استثنا اختصاصی است که مسائل ورودی را بر اساس نوع طبقه‌بندی می‌کند، آنها را به جریان‌های حل تخصصی هدایت می‌کند و تنها زمانی که خود جریان حل به حالتی برخورد می‌کند که نمی‌تواند آن را اداره کند، آنها را به بالادست ارجاع می‌دهد.

لایه استثنا حالت خود را جدا از حالت مکالمه و حالت تجارت حفظ می‌کند، زیرا حل استثناها اغلب روزها یا هفته‌ها طول می‌کشد و نیاز به هماهنگی بین چندین تیم انسانی، فروشندگان خارجی و نقاط تماس مشتری دارد. رسیدگی به استثناها به عنوان گردش کارهای طولانی‌مدت به جای تیکت‌ها، نتایج بسیار بهتری نسبت به الگوی تیکت‌ها و ماکروها که اکثر میزهای کمک‌رسانی به طور پیش‌فرض استفاده می‌کنند، تولید می‌کند.

این پیاده‌سازی معمولاً از ابزارهای هماهنگ‌سازی گردش کار مانند Temporal، AWS Step Functions یا ماشین‌های حالت سفارشی استفاده می‌کند، با میز کمک‌رسانی یا پلتفرم تجارت که کانال مشتری‌محور را فراهم می‌کند و لایه استدلال عامل که منطق تصمیم‌گیری را ارائه می‌دهد. موتور گردش کار، پایداری حالت، منطق تکرار و قوانین ارجاع را مدیریت می‌کند.

برندهایی که لایه‌های مدیریت استثنا صریح را ساخته‌اند، زمان حل استثناها را 60 تا 80 درصد در مقایسه با مدیریت مبتنی بر تیکت کاهش می‌دهند. برندهایی که این کار را انجام نداده‌اند، موارد استثنایی را مشاهده می‌کنند که توجه انسانی نامتناسبی را مصرف می‌کنند در حالی که پایین‌ترین امتیازات رضایت مشتری را در سبد خود تولید می‌کنند.

از همان ابتدا با پروژه به عنوان زیرساخت تولید برخورد کنید

آخرین اصل معماری که عامل‌های هوش مصنوعی موفق را برای خدمات مشتری تجارت الکترونیک در هر چهار محیط پلتفرم تعریف می‌کند، برخورد با پروژه به عنوان زیرساخت تولید از همان روز اول است تا به عنوان یک پروژه بازاریابی که به سرعت عرضه می‌شود و دائماً پچ می‌شود. این تصمیم در قابلیت مشاهده، روش‌های استقرار، پاسخ به حادثه و بهینه‌سازی مداوم خود را نشان می‌دهد.

TFSF Ventures FZ-LLC استقرارهای عامل تجارت الکترونیک را به عنوان زیرساخت تولید در هر چهار محیط پلتفرم می‌سازد، با آداپتورهای پلتفرم-آگاهی که الگوهای یکپارچه‌سازی Shopify، Gorgias، Zendesk و OMS را که در بالا توضیح داده شد، مدیریت می‌کنند. متدولوژی استقرار 30 روزه، سیستم‌های عملیاتی را تولید می‌کند که وضعیت سفارش، بازگرداندن کالا، بازپرداخت و استثناها را به عنوان گردش کارهای خودمختار که مستقیماً به هر پشته تجاری که برند عملیات می‌کند، مرتبط هستند، اداره می‌کند.

ارزیابی عملیاتی 19 سوالی، ترکیبات پلتفرم خاص، الزامات یکپارچه‌سازی و الگوهای استثنایی را قبل از شروع ساخت، مشخص می‌کند، که این همان چیزی است که نتایج ثابتی را در 21 عمودی که خدمات را ارائه می‌دهیم، تولید می‌کند. سرمایه‌گذاری‌های استقرار برای پیاده‌سازی‌های متمرکز از چند ده هزار دلار شروع می‌شود و با تعداد عامل، پیچیدگی یکپارچه‌سازی و دامنه عملیاتی مقیاس می‌یابد. زیرساخت هوش مصنوعی تقریباً چهارصد تا پانصد دلار در ماه از Pulse AI، با قیمت تمام شده و بدون هیچگونه اضافه‌بها، اجرا می‌شود. مشتریان مالک کامل کد هستند و هیچگونه هزینه‌ای به ازای هر صندلی یا هر حل مشکل وجود ندارد.

مدل قیمت‌گذاری TFSF Ventures FZ-LLC در هر پیشنهاد به صورت شفاف منتشر شده است و مشروعیت شرکت از طریق ثبت RAKEZ تحت RAKEZ License 47013955 قابل تأیید است. عدم وجود بررسی‌های عمومی TFSF Ventures منعکس کننده یک سیاست محرمانگی است که جزئیات استقرار را محافظت می‌کند تا عدم وجود حجم استقرار. تفاوت ساختاری با فروشندگان Helpdesk این است که زیرساخت عامل به عنوان سیستم تولید خود بازرگان اجرا می‌شود نه به عنوان یک لایه SaaS کنترل شده توسط فروشنده.

برندهایی که با عامل به عنوان زیرساخت تولید برخورد می‌کنند، بازدهی مرکب را در چندین فصل اوج و به‌روزرسانی پلتفرم مشاهده می‌کنند. سال اول بهبودهای معنی‌داری را نسبت به خط پایه قبلی تولید می‌کند. سال دوم تغییر گام دیگری را ایجاد می‌کند زیرا عامل از یک سال کامل الگوهای تیکت واقعی یاد گرفته است. سال سوم زمانی است که مزیت ساختاری نسبت به رقبا بادوام می‌شود.

طراحی لایه حافظه مکالمه برای پیوستگی بین پلتفرمی

مشتریان اهمیتی نمی‌دهند که کدام پلتفرم زیرساخت خدمات مشتری یک برند را تأمین می‌کند. آنها انتظار دارند که برند هر تعامل قبلی را بدون توجه به کانال، عامل یا سیستم درگیر، به یاد بیاورد. طراحی لایه حافظه مکالمه برای ارائه این پیوستگی در Shopify، Gorgias، Zendesk و معماری‌های مبتنی بر OMS یکی از مهمترین تصمیمات معماری در استقرارهای تولید است.

الگویی که کار می‌کند، یک فروشگاه حافظه مکالمه یکپارچه است که خارج از Helpdesk یا پلتفرم تجارت زندگی می‌کند، با آداپتورهای مخصوص پلتفرم که هر تعامل مربوطه را در فروشگاه یکپارچه می‌نویسند و در صورت نیاز به زمینه، از آن می‌خوانند. فروشگاه رشته‌های مکالمه، تصمیمات عامل، اولویت‌های مشتری و نتایج حل مشکل را در قالبی پلتفرم-خنثی حفظ می‌کند که هر سیستم آینده‌ای می‌تواند آن را مصرف کند.

مزایا با گذشت زمان افزایش می‌یابند. اولین مکالمه‌ای که یک مشتری با برند دارد، زمینه‌ای را تولید می‌کند که هر تعامل آینده را در هر کانالی اطلاع‌رسانی می‌کند. سال دوم سابقه مکالمه، فرصت‌های شخصی‌سازی را تولید می‌کند که برندهایی بدون حافظه یکپارچه به سادگی نمی‌توانند ارائه دهند. سال پنجم، نوعی از رابطه با مشتری را تولید می‌کند که بهترین برندهای DTC به آن معروف هستند.

برندهایی که در حافظه مکالمه یکپارچه سرمایه‌گذاری کرده‌اند، بهبودهایی در ارزش طول عمر مشتری مشاهده می‌کنند که سرمایه‌گذاری معماری را بارها و بارها جبران می‌کند. برندهایی که این کار را انجام نداده‌اند، مشتریانی را می‌بینند که بارها و بارها در مورد نیاز به توضیح مجدد زمینه‌ای که برند باید قبلاً می‌دانست، شکایت می‌کنند، و این شکایت‌ها در بررسی‌هایی که خریداران آینده قبل از خرید می‌خوانند، ظاهر می‌شوند.

ساخت منطق مسیریابی بر اساس ارزش طول عمر مشتری

برندهایی که پیشرفته‌ترین معماری‌های عامل را در هر چهار محیط پلتفرم ساخته‌اند، یک الگوی منطق مسیریابی مشترک دارند که ارزش طول عمر مشتری را در هر نقطه تصمیم‌گیری در نظر می‌گیرد. مشتریان تکراری با ارزش طول عمر بالا (High-LTV) درمان متفاوتی نسبت به خریداران بار اول که همان سوال را می‌پرسند، دریافت می‌کنند، نه به این دلیل که سیاست ناعادلانه است بلکه به این دلیل که اقتصاد حفظ مشتری، درمان متفاوت را در لحظه تصمیم‌گیری الزامی می‌کند.

الگوی پیاده‌سازی، محاسبات ارزش طول عمر مشتری را در منطق تصمیم‌گیری عامل ادغام می‌کند، با آستانه‌هایی که مسیرهای حل مشکل موجود را برای بخش‌های مشتری خاص تعیین می‌کند. یک خریدار بار اول که در مورد کالای آسیب‌دیده سوال می‌کند، ممکن است یک جریان بازپرداخت استاندارد دریافت کند، در حالی که یک مشتری تکراری با ارزش طول عمر بالا که در مورد همان مشکل سوال می‌کند، ممکن است یک جایگزینی سریع به همراه اعتبار حسن نیت و عذرخواهی شخصی از یک نماینده خدمات ارشد دریافت کند.

برندهایی که این الگو را ساخته‌اند، بهبودهایی در حفظ مشتریان با بالاترین ارزش خود را مشاهده می‌کنند که سال به سال افزایش می‌یابد. برندهایی که این الگو را نساخته‌اند، مشتریان با ارزش بالا را مشاهده می‌کنند که به دلیل نارضایتی‌های کوچک که می‌توانستند به طور متفاوت مورد بررسی قرار گیرند اگر عامل در لحظه تصمیم‌گیری به زمینه مربوطه دسترسی داشت، از دست می‌روند.

الزام معماری، یکپارچه‌سازی بین پلتفرم داده مشتری، سیستم وفاداری، پلتفرم تجارت و لایه استدلال عامل است. این یکپارچه‌سازی بی‌اهمیت نیست اما بازدهی مرکب را تولید می‌کند که سرمایه‌گذاری مهندسی را بارها و بارها توجیه می‌کند.

طراحی لایه قابلیت مشاهده قبل از اولین مکالمه در محیط تولید

عامل روزانه هزاران بار تصمیم می‌گیرد، فراخوانی‌های API انجام می‌دهد و ارجاعات را در مقیاس میلیون سفارش فعال می‌کند. بدون یک لایه قابلیت مشاهده که قبل از اولین مکالمه در محیط تولید طراحی شده باشد، تیم هیچ دیدگاهی نسبت به آنچه عامل واقعاً انجام می‌دهد، کجا به طور خاموش شکست می‌خورد، و کدام الگوها تجربه مشتری را کاهش می‌دهند، ندارد. استقرارهای تولید در هر چهار محیط پلتفرم از روز اول به این لایه نیاز دارند.

الگویی که کار می‌کند، انتشار رویداد ساختاریافته از هر تصمیم عامل، هر فراخوانی API، هر ارجاع و هر نتیجه حل مشکل است. این رویدادها به پلتفرم‌های قابلیت مشاهده جریان می‌یابند که ناهنجاری‌ها را در زمان واقعی نشان می‌دهند و به تیم اجازه می‌دهند تا مسائل را در عرض چند دقیقه به جای ساعت‌ها تشخیص دهند. برندهایی که این ابزار را ندارند، شکست‌ها را تنها زمانی کشف می‌کنند که مشتریان شکایت می‌کنند، که این به طور چشمگیری گران‌تر از گرفتن آنها در جریان قابلیت مشاهده است.

سرمایه‌گذاری در ابزارهای قابلیت مشاهده برای اکثر استقرارها در محدوده پنج رقمی پایین قرار می‌گیرد و بازدهی را تولید می‌کند که در اولین حادثه بزرگ جبران می‌شود. برندهایی که این سرمایه‌گذاری را انجام داده‌اند، از حوادث پلتفرم، رگرسیون‌های مدل و شکست‌های یکپارچه‌سازی با حداقل تأثیر بر مشتری عبور می‌کنند. برندهایی که این کار را انجام نداده‌اند، حوادث را مشاهده می‌کنند که به اختلالات چند روزه تبدیل می‌شوند که به رتبه‌بندی و ارزش طول عمر مشتری آسیب می‌رسانند.

اصل طراحی قابلیت مشاهده در ابتدا اعمال می‌شود، چه معماری زیربنایی بومی Shopify، مبتنی بر Gorgias، مبتنی بر Zendesk یا مبتنی بر OMS باشد. انتخاب پلتفرم نیاز به دید در مورد آنچه عامل در محیط تولید انجام می‌دهد را تغییر نمی‌دهد.

درباره TFSF Ventures

TFSF Ventures FZ-LLC (RAKEZ License 47013955) یک شرکت معماری سرمایه‌گذاری است که زیرساخت عامل هوشمند را از طریق سه ستون یکپارچه در کسب‌وکارها مستقر می‌کند: زیرساخت عامل‌محور، ریل‌های پرداخت غیرسنتی، و یک موتور سرمایه‌گذاری کامل. TFSF با 27 سال تجربه در پرداخت‌ها و نرم‌افزار، به صورت جهانی فعالیت می‌کند و با متدولوژی استقرار 30 روزه به 21 صنعت خدمات ارائه می‌دهد. برای کسب اطلاعات بیشتر به https://tfsfventures.com مراجعه کنید.

ارزیابی رایگان هوش عملیاتی را انجام دهید. به چند سوال سریع درباره کسب‌وکار خود پاسخ دهید. یک طرح اولیه استقرار AI سفارشی در عرض 24 تا 48 ساعت دریافت کنید که شامل توصیه‌های عامل، معماری و یک نقشه راه مخصوص عملیات شماست. بدون تماس فروش. بدون تعهد. فقط داده. شروع کنید در https://tfsfventures.com/assessment

Originally published at https://tfsfventures.com/blog/architecting-ai-agents-for-e-commerce-customer-service-across-shopify-gorgias

Written by TFSF Ventures Research