مارکتینگ اتومیشن را با دمو نمی‌خرند، با قرارداد درست می‌خرند!

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

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

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

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

اما بعد از امضای قرارداد، تازه سؤال‌های اصلی شروع می‌شود:

• این MAU که بر اساس آن پرداخت می‌کنیم، دقیقاً چطور محاسبه می‌شود؟
• کدام کانال‌ها واقعاً در قرارداد هستند؟
• ایونت‌های کاربران تا چند ماه نگهداری می‌شوند؟
• اگر اینترنت ایران دچار اختلال شد، SLA چه می‌گوید؟
• اگر داده‌های تستی وارد پنل اصلی شد، چه کسی مسئول تمیزکاری است؟
• اگر تیم فنی سه ماه درگیر پیاده‌سازی شد، هزینه این تأخیر در بهره‌برداری بر دوش چه کسی می‌افتد؟

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

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

اما انتخاب بین این‌ها نباید به جمله ساده «خارجی بهتر است» یا «داخلی ارزان‌تر است» تقلیل پیدا کند.

سؤال درست این است:

برای مدل کسب‌وکار من، کدام قرارداد کم‌ریسک‌تر است؟

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

در قرارداد، MAU فقط یک عدد ساده نیست، بلکه یک تعریف حقوقی و مالی است.

• آیا کاربری که فقط یک بار وارد سایت شده، حساب می‌شود؟
• آیا کاربر ناشناس هم در MAU می‌آید؟
• آیا کاربرانی که فقط از طریق ایمپورت دیتابیس وارد سیستم شده‌اند، فعال محسوب می‌شوند؟
• آیا کاربرانی که به آن‌ها پیام ارسال شده، اما اپلیکیشن را باز نکرده‌اند، در محاسبه می‌آیند؟
• آیا کاربران تست، کارمندان داخلی، ترافیک QA و داده‌های staging جدا می‌شوند؟

همین چند سؤال ساده می‌تواند تفاوت قابل‌توجهی در مبلغ ماهانه ایجاد کند.

در تجربه‌ای که من داشته‌ام، در مورد وب‌اینگیج، قراردادی که حدود سال ۹۸ برای شرکتی با عددی نزدیک به ۸۰۰ دلار در ماه بسته می‌شد، در سال ۱۴۰۴ برای موردی نسبتاً مشابه می‌توانست به حدود ۲۲۰۰ دلار در ماه برسد. این عدد را به‌عنوان «نرخ دقیق بازار» در نظر نگیرید، چون قیمت نهایی به مذاکره، حجم کاربران، کانال‌ها، فیچرها، سطح پشتیبانی و شرایط قرارداد بستگی دارد. منتهی این عدد برای بسیاری از شرکت‌ها، یک هزینه جدی ماهانه است و نشان می‌دهد که مارکتینگ اتومیشن دیگر یک ابزار جانبی ارزان نیست.

مسئله دوم، کانال‌هاست

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

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

مسئله سوم، داده است

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

• کاربر چه چیزی دیده؟
• کجا کلیک کرده؟
• چه چیزی را به سبد خرید اضافه کرده؟
• کجا رها کرده؟
• چند بار برگشته؟
• از چه کمپینی آمده؟
• چه زمانی خرید کرده؟

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

پس در قرارداد فقط نباید بپرسیم «داده‌ها را ذخیره می‌کنید؟»

باید بپرسیم:

• ایونت‌ها تا چند ماه نگهداری می‌شوند؟
• داده خام قابل خروجی گرفتن است؟
• اگر بخواهیم retention طولانی‌تر داشته باشیم، هزینه‌اش چقدر است؟
• آیا بعد از پایان قرارداد، امکان export کامل داده‌ها وجود دارد؟
• اگر بخواهیم داده‌ها را به data warehouse خودمان ببریم، مسیر فنی و هزینه آن چیست؟

مسئله چهارم SLA است

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

در چنین فضایی، یک SLA عمومی کافی نیست.

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

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

مسئله پنجم، پیاده‌سازی است

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

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

بعد برای هر journey باید مشخص شود چه eventهایی لازم است، هر event چه attributeهایی دارد، کجا ارسال می‌شود، با چه اصول نام‌گذاری(naming convention) ثبت می‌شود و چه کسی مسئول صحت آن است.

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

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

مسئله ششم، امنیت داده است

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

اما امنیت داده را نباید فقط با NDA حل‌شده فرض کرد!

باید دقیق پرسید:

• داده کجا ذخیره می‌شود؟
• چه کسانی در سمت سرویس‌دهنده به داده دسترسی دارند؟
• سطح دسترسی‌ها لاگ می‌شود؟
• امکان masking یا encryption وجود دارد؟
• اگر داده حساس است، آیا self-encryption یا client-side encryption ممکن است؟
• اگر داده رمزنگاری شود، چه فیچرهایی از کار می‌افتد یا پیچیده‌تر می‌شود؟
• در پایان قرارداد، حذف داده‌ها چگونه انجام می‌شود؟

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

اگر بخواهم خیلی کوتاه جمع‌بندی کنم:

مارکتینگ اتومیشن را نباید فقط با دمو خرید.

حتی نباید فقط با مقایسه فیچرها خرید.

باید آن را با فهم قرارداد، فهم داده، فهم هزینه پنهان و فهم توان اجرایی سازمان خرید.

اگر تیم شما هنوز journeyهای اصلی‌اش را نمی‌شناسد، اگردسته‌بندی‌های ایونت‌های کسب و کار یا event taxonomy  ندارد، اگر بین مارکتینگ، محصول و فنی مالکیت روشنی وجود ندارد، اگر نمی‌دانید MAU قراردادی چطور محاسبه می‌شود، اگر retention داده و SLA را دقیق نپرسیده‌اید، احتمالا هنوز برای امضای قرارداد آماده نیستید حتی اگر دمو خیلی جذاب بوده باشد.

در خرید مارکتینگ اتومیشن، سوال اصلی این نیست که «کدام ابزار بهتر است؟»

سوال اصلی این است:

آیا سازمان ما می‌داند دقیقا چه چیزی می‌خرد، چطور قرار است از آن استفاده کند و هزینه واقعی آن در دوازده ماه آینده چقدر خواهد بود؟