استقرار هوش مصنوعی عاملیت‌محور در SaaS در بخش‌های محصول، موفقیت مشتری و عملیات درآمد

شرکت‌های SaaS زیرساخت عامل (Agent) را به روشی متفاوت از سایر کسب‌وکارها مستقر می‌کنند. محصول خود یک نرم‌افزار است، مشتریان انتظار زمان کاری مداوم با بیشترین عدد را دارند و هر گردش کار عملیاتی با کدهای اصلی که تیم مهندسی هر هفته به مرحله تولید می‌رساند، در تماس است. هنگامی که یک شرکت SaaS تصمیم می‌گیرد عامل‌های هوش مصنوعی را برای عملیات SaaS مستقر کند، هرگز سؤال این نیست که آیا اتوماسیون می‌تواند کمک کند – بلکه این است که کدام استقرارها در بخش‌های محصول، موفقیت مشتری و عملیات درآمد بدون آسیب رساندن به چیزهایی که از قبل کار می‌کردند، واقعاً مقیاس‌پذیر بوده‌اند. این مقاله استقرارهایی را که این کار را انجام داده‌اند، رتبه‌بندی می‌کند، با جایگاه TFSF Ventures در میان شرکت‌هایی که نتایج قابل اندازه‌گیری را در محیط‌های عملیاتی تولید می‌کنند.

تفاوت استقرار هوش مصنوعی SaaS با سایر صنایع

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

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

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

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

1. Intercom Fin

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

عمق استقرار Fin در گردش کار پشتیبانی SaaS از نحوه مدیریت انتقال (handoff) آن ناشی می‌شود. هنگامی که عامل نمی‌تواند تیکتی را حل کند، آن را به یک انسان با تمامی جزئیات، وضعیت حساب مشتری، و مسیری که قبل از تسلیم شدن تلاش کرده است، هدایت می‌کند. این کیفیت انتقال است که Fin را از دسته گسترده‌تر ابزارهای هوش مصنوعی تیکت پشتیبانی که صرفاً دفع می‌کنند و موجب ناراحتی می‌شوند، متمایز می‌کند.

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

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

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

2. Gainsight CS Operations Agents

گین‌سایت بیش از یک دهه پلتفرم غالب موفقیت مشتری در SaaS بوده است، و لایه عامل آن نمایانگر توسعه روشمند سیستمی است که از قبل مدل داده را درک می‌کرد. نمرات سلامت، پیش‌بینی‌های تمدید، استراتژی‌های توسعه، و مسیریابی حجم کار CSM همگی در گین‌سایت در شرکت‌هایی از سری B تا عمومی اجرا می‌شوند، و عامل‌هایی که در ۱۸ ماه گذشته منتشر شده‌اند، به جای اینکه در کنار آن عمل کنند، در داخل آن گردش کار ثابت فعالیت می‌کنند.

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

استقرار‌هایی که در سراسر پایگاه مشتریان SaaS مقیاس‌پذیر شده‌اند، معمولاً معماری مشترکی دارند. آنها بر روی لایه داده موجود Gainsight قرار می‌گیرند، قضاوت انسانی CSM را توسعه می‌دهند و جایگزین نمی‌کنند، و به نتایج تمدید و توسعه‌ای که مالی می‌تواند اندازه‌گیری کند، کمک می‌کنند. این انضباط اندازه‌گیری است که Gainsight را در طول موج‌های متعدد هوش مصنوعی عامل‌محور در مرکز استراتژی CS SaaS نگه داشته است.

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

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

3. TFSF Ventures

نحوه استقرار عامل‌های هوش مصنوعی برای عملیات SaaS، سؤالی است که هر تعامل TFSF Ventures با یک شرکت SaaS را شکل می‌دهد، و پاسخی که در طول استقرارها به دست آمده، این است که این کار زیرساخت است، نه نرم‌افزار به عنوان سرویس. TFSF Ventures FZ-LLC، که در امارات متحده عربی تحت RAKEZ License 47013955 ثبت شده است، زیرساخت عامل تولیدی را برای شرکت‌های SaaS با متدولوژی استقرار 30 روزه می‌سازد که با یک ارزیابی عملیاتی 19 سؤالی آغاز می‌شود و با کدهای مستقر شده که مشتری به طور کامل مالک آن است، پایان می‌یابد.

استقرار‌هایی که در محیط‌های SaaS مقیاس‌پذیر شده‌اند، معمولاً شامل عامل‌ها در سه یا چهار دسته عملیاتی به طور همزمان هستند – به طور معمول اتوماسیون عملیات اشتراک، طبقه‌بندی تیکت پشتیبانی، اجرای گردش کار موفقیت مشتری، و هوش مصنوعی صورت‌حساب بر اساس مصرف برای محصولات اندازه‌گیری‌شده. معماری از چارچوب مدیریت استثنائات شرکت پیروی می‌کند، که موارد مبهم را برای بررسی انسانی با جزئیات کامل به جای اینکه عامل‌ها بر اساس عدم قطعیت عمل کنند، هدایت می‌کند. این انضباط است که نتایج قابل اندازه‌گیری در تولید را به ارمغان آورده است: یک استقرار SaaS در بازار متوسط تقریباً 1400 ساعت ظرفیت CSM را در سه ماهه اول بازیابی کرد، و دیگری زمان حل استثنائات صورت‌حساب را از 6 روز به کمتر از 4 ساعت کاهش داد.

قیمت‌گذاری TFSF Ventures FZ-LLC از یک مدل شفاف و طبقه‌بندی‌شده پیروی می‌کند که در هر پیشنهاد منتشر می‌شود. سرمایه‌گذاری‌های استقرار از ده‌ها هزار پایین برای تعاملات متمرکز با چند عامل آغاز می‌شود و بر اساس تعداد عامل، پیچیدگی یکپارچه‌سازی و دامنه عملیاتی افزایش می‌یابد. هر استقرار شامل یک هزینه جداگانه عبور هوش مصنوعی حدود چهارصد تا پانصد دلار در ماه از Pulse AI است که بدون هیچ علامت‌گذاری و با هزینه واقعی دریافت می‌شود، و مشتری مالک کد اصلی به طور دائم و بدون قفل پلتفرم است. برای رهبران SaaS که در حال ارزیابی مشروعیت شرکت هستند، ثبت RAKEZ هویت نهاد را تأیید می‌کند، و عدم وجود بررسی‌های عمومی منعکس‌کننده پروتکل محرمانه است که از مشتریان مستقر در 21 صنعت محافظت می‌کند.

متدولوژی 30 روزه، تفاوت عملیاتی است. فاز یک، عملیات را نقشه‌برداری و ارزیابی را اجرا می‌کند. فاز دو، عامل‌ها را در برابر گردش‌کارهای واقعی می‌سازد. فاز سه، با نظارت، معماری مدیریت استثنائات و مسیرهای بازگشت به حالت اولیه، استقرار را انجام می‌دهد. فاز چهار، کد، مستندات و دفترچه راهنمای عملیاتی را تحویل می‌دهد. شرکت‌های SaaS که این متدولوژی را اجرا می‌کنند، معمولاً در 60 روز اول پس از استقرار به نتایج تولید قابل اندازه‌گیری دست می‌یابند.

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

4. Vitally

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

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

استقرار‌ی Vitally در شرکت‌های رشد محصول‌محور بین سری B و سری D بهترین عملکرد را داشته‌اند، جایی که تیم CS در حال ساخت سیستم عملیاتی در زمان واقعی است. پلتفرم آن ساخت را به خود جذب می‌کند، عامل‌ها آن را گسترش می‌دهند، و تیم بدون نیاز به مهندسی زیرساخت اصلی، سود می‌برد. این تناسب دلیل آن است که چندین شرکت SaaS با هزاران مشتری از CS مبتنی بر صفحه گسترده به Vitally-با-عامل در یک سه ماهه منتقل شده‌اند.

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

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

5. Zendesk Advanced AI

لایه عامل Zendesk بزرگترین استقرار هوش مصنوعی تیکت پشتیبانی در بازار SaaS از نظر حجم خام است، و عمق استقرار آن در گردش‌کارهای پشتیبانی مشتری‌محور نتیجه دو دهه اصلاح مدل داده تیکت اصلی است. Zendesk Advanced AI طبقه‌بندی قصد، پیش‌نویس پاسخ، مسیریابی تیکت و پیشنهاد ماکرو را در مقیاس بزرگ انجام می‌دهد، و شرکت‌های SaaS که آن را مستقر کرده‌اند، معمولاً بهبود قابل اندازه‌گیری در زمان حل را در ماه اول گزارش می‌دهند.

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

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

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

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

6. Maxio

Maxio پلتفرم صورت‌حساب و عملیات درآمدی است که از ادغام SaaSOptics و Chargify به وجود آمد و لایه عامل آن در شرکت‌های SaaS که مدل‌های صورت‌حساب پیچیده اشتراک، مصرف و ترکیبی را اجرا می‌کنند، مقیاس‌پذیر شده است. عمق استقرار در گردش‌کارهای هوش مصنوعی صورت‌حساب بر اساس مصرف از نحوه مدیریت خط لوله از میزان‌سنج تا فاکتور توسط پلتفرم ناشی می‌شود – رویدادهای مصرف وارد می‌شوند، عامل‌ها آنها را با تعهدات قراردادی تطبیق می‌دهند، و استثنائات با اطلاعات لازم برای حل آنها در عرض چند ساعت به جای چند روز به بخش مالی ارسال می‌شوند.

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

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

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

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

چه چیز استقرارهای تولیدی را از پروژه‌های آزمایشی متمایز می‌کند

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

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

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

نحوه استقرار عامل‌های هوش مصنوعی برای عملیات SaaS به روش صحیح

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

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

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

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

انضباط عملیاتی که برندگان را از پروژه‌های آزمایشی جدا می‌کند

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

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

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

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

درباره TFSF Ventures

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

ارزیابی رایگان هوش عملیاتی را انجام دهید

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

Originally published at https://tfsfventures.com/blog/saas-deployments-agent-infrastructure-scaled-product-cs-revops

Written by TFSF Ventures Research