خرید مارکتینگ اتومیشن در ایران؛ ۱۴ نکته قراردادی، فنی و اجرایی

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

وقتی زمان خرید یک سرویس مارکتینگ اتومیشن (Marketing Automation) می‌رسد، معمولاً هزینه سرویس یکی از مهم‌ترین دغدغه‌هاست. در بسیاری از موارد، اولین واکنش این است که سراغ گزینه ارزان‌تر برویم. اگر WebEngage گران است، ابزار داخلی را بررسی کنیم؛ اگر ابزار داخلی هم هزینه بالایی دارد، پلن پایین‌تر بگیریم و اگر باز هم گران بود، شاید به فکر ساختن ابزار اختصاصی بیفتیم.

اما در تجربه من، ارزان‌تر بستن قرارداد همیشه به معنی خریدن ابزار ارزان‌تر نیست.

گاهی می‌توان همان ابزار را با هزینه کمتر، ریسک پایین‌تر و تعهد منطقی‌تر خرید؛ به شرط اینکه پیش از امضا دقیقاً بدانیم چه چیزی می‌خریم و کدام بندهای قرارداد ممکن است در آینده هزینه‌ساز شوند.

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

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

۱. تعریف دقیق MAU؛ اولین گام برای کنترل هزینه

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

بسیاری از ابزارها بر اساس MAU قیمت‌گذاری می‌کنند. مدل کلی ساده به نظر می‌رسد؛ برای مثال، زیر ۱۰۰ هزار کاربر فعال یک قیمت دارد، بین ۱۰۰ تا ۳۰۰ هزار کاربر قیمت دیگری و بین ۳۰۰ تا ۵۰۰ هزار کاربر نیز در سطح دیگری قرار می‌گیرد.

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

کاربر فعال ماهانه دقیقاً به چه معناست؟

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

این‌ها سوال‌های فنی کوچک نیستند؛ مستقیماً سوال‌های مالی هستند.

اگر تعریف MAU دقیق نباشد، ممکن است شرکت برای کاربرانی هزینه پرداخت کند که هیچ نقشی در جرنی‌های واقعی مارکتینگ اتومیشن ندارند. ممکن است قرارداد بر اساس ۵۰۰ هزار کاربر بسته شود، اما در عمل تنها ۲۵۰ هزار کاربر واقعاً در سناریوهای مارکتینگ قابل استفاده باشند.

بنابراین اولین اصل برای ارزان‌تر بستن قرارداد این است:

MAU را به «تعامل معنادار» نزدیک کنید، نه به هر نوع حضور یا ثبت داده.

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

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

۲. مدیریت eventها؛ هر داده‌ای ارزش ارسال ندارد

حتی اگر قرارداد بر اساس MAU بسته شده باشد، eventها همچنان اهمیت زیادی دارند؛ زیرا بخش قابل توجهی از هزینه سرویس‌دهندگان از ذخیره و پردازش eventها ایجاد می‌شود. در برخی مدل‌ها نیز قیمت‌گذاری مستقیماً بر اساس تعداد eventهای ارسالی انجام می‌شود.

یکی از اشتباه‌های رایج در زمان پیاده‌سازی این است که تیم‌ها می‌گویند:

«هر چیزی را بفرستیم، بعداً شاید لازم شد.»

این جمله از نظر داده جذاب است، اما از نظر هزینه می‌تواند خطرناک باشد.

هر کلیک، هر اسکرول، هر refresh، هر مشاهده تکراری، هر event تستی، هر event ناقص و هر attribute اضافه، اگر وارد سیستم شود، می‌تواند بخشی از مصرف شما را افزایش دهد. حتی اگر امروز تأثیر مستقیمی روی فاکتور نداشته باشد، در زمان تمدید قرارداد، مهاجرت به سرویس دیگر، گزارش‌گیری یا عملکرد سیستم خودش را نشان خواهد داد.

در مارکتینگ اتومیشن، تعداد بیشتر event الزاماً به معنی داده بهتر نیست.

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

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

پیش از امضای قرارداد، داشتن یک Tracking Plan اولیه ضروری است؛ نه لزوماً یک سند پیچیده و چندصدصفحه‌ای، بلکه چارچوبی مشخص برای اینکه بدانیم در فاز اول چه eventهایی واقعاً لازم هستند.

برای مثال، در فاز ابتدایی ممکن است این eventها کافی باشند:

• ثبت‌نام
• ورود
• مشاهده محصول یا سرویس
• شروع فرایند خرید
• رها کردن مرحله‌ای از قیف
• پرداخت موفق
• پرداخت ناموفق
• کنسلی
• بازگشت به محصول

سایر eventها را می‌توان در مراحل بعدی اضافه کرد.

این رویکرد هم هزینه را کنترل می‌کند و هم کیفیت داده را افزایش می‌دهد.

۳. جلوگیری از ورود داده‌های تستی به Production

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

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

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

به همین دلیل، بهتر است از ابتدا در قرارداد مشخص شود که شرکت ارائه‌دهنده سرویس اتومیشن، یک workspace تست یا پنل staging یا حداقل یک محیط جداگانه برای پیاده‌سازی اولیه در اختیار شما قرار دهد؛ ترجیحاً بدون هزینه یا با هزینه بسیار محدود.

اگر ارائه‌دهنده چنین امکانی را فراهم نمی‌کند، باید حداقل درباره امکان reset داده‌ها پیش از استقرار نهایی و پس از پایان تست‌های فنی مذاکره کرد.

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

۴. کانال‌های ارتباطی؛ همه قابلیت‌ها را از روز اول نخرید

در دموهای ابزارهای مارکتینگ اتومیشن، معمولاً همه‌چیز کنار هم نمایش داده می‌شود؛ پیامک، پوش نوتیفیکیشن، ایمیل، وب‌پوش، in-app، واتساپ، RCS، تبلیغات گوگل و شبکه‌های اجتماعی.

اما در قرارداد، این کانال‌ها شرایط یکسانی ندارند.

برخی در پلن پایه ارائه می‌شوند، برخی به‌عنوان Add-on فروخته می‌شوند، برخی هزینه فعال‌سازی دارند، برخی هزینه ارسال جداگانه دارند، برخی به سرویس‌دهنده بیرونی نیاز دارند و برخی نیز نیازمند پیاده‌سازی فنی یا تأییدهای حقوقی هستند.

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

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

اما اگر هنوز Use Caseهای اصلی مشخص نشده‌اند و eventها تثبیت نشده‌اند، خرید همه کانال‌ها فقط قرارداد را سنگین‌تر می‌کند.

بهتر است کانال‌ها جداگانه مذاکره شوند و مشخص شود:

• کدام کانال در هزینه پلن پایه قرار دارد؟
• کدام کانال Add-on محسوب می‌شود؟
• هزینه فعال‌سازی هر کانال چقدر است؟
• هزینه ارسال از طریق سرویس اتومیشن محاسبه می‌شود یا Provider جداگانه؟
• آیا امکان اتصال به Provider فعلی پیامک یا ایمیل وجود دارد؟
• اگر یک کانال در ماه‌های آینده اضافه شود، قیمت آن از ابتدا مشخص می‌شود یا نیاز به مذاکره مجدد دارد؟
• اگر یک کانال به دلیل شرایط ایران قابل استفاده نباشد، آیا امکان تعلیق هزینه آن وجود دارد؟

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

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

۵. نگهداشت داده؛ همه داده‌ها ارزش نگهداری بلندمدت ندارند

همه کسب‌وکارها تمایل دارند داده‌های خود را برای همیشه نگهداری کنند. اما نگهداری داده هزینه دارد.

سوال درست این نیست که:

«آیا داده‌ها را نگه می‌دارید؟»

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

«کدام داده، برای چه مدت، با چه سطح دسترسی و با چه هزینه‌ای نگهداری می‌شود؟»

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

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

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

بنابراین نگهداشت داده نباید صرفاً احساسی خریداری شود؛ بلکه باید بر اساس چرخه خرید مشتری و ماهیت صنعت تعیین شود.

یک ترکیب منطقی می‌تواند این باشد:

• برای eventهای پرتعداد و کم‌ارزش، نگهداشت کوتاه‌تر در نظر گرفته شود.
• برای eventهای تراکنشی و مربوط به چرخه عمر مشتری، نگهداشت طولانی‌تر باشد.
• برای attributeهای پروفایل، نگهداری تا زمانی ادامه پیدا کند که کاربر در سیستم فعال است.
• برای داده‌های خام بلندمدت، خروجی منظم به Data Warehouse داخلی انجام شود.

این مدل معمولاً از خرید نگهداشت بلندمدت برای تمام داده‌ها، ارزان‌تر و منطقی‌تر است.

۶. خروجی گرفتن از داده؛ بندی که نباید نادیده گرفته شود

یکی از بندهایی که معمولاً در مذاکره‌ها جدی گرفته نمی‌شود، امکان خروجی گرفتن از داده‌ها (Data Export) است.

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

از ابتدا باید پرسید:

• آیا خروجی گرفتن از داده خام eventها امکان‌پذیر است؟
• خروجی با چه فرمت و چه تناوبی ارائه می‌شود؟
• آیا API وجود دارد یا فقط فایل دریافت می‌کنیم؟
• آیا اتصال به S3، FTP، BigQuery، ClickHouse یا مقصدهای دیگر امکان‌پذیر است؟
• هزینه جداگانه دارد یا در قرارداد لحاظ شده است؟
• پس از پایان قرارداد، چند روز برای خروجی گرفتن از داده‌ها فرصت داریم؟
• آیا خروجی شامل داده‌های تاریخی (Historical Data) نیز می‌شود یا فقط داده‌های پس از فعال‌سازی Export؟
• پس از پایان قرارداد، داده‌ها با چه روالی حذف می‌شوند؟

این بند مستقیماً روی قدرت مذاکره شما در تمدید قرارداد اثر می‌گذارد.

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

بنابراین قرارداد خوب فقط قراردادی نیست که هزینه سال اول را پایین بیاورد؛ قرارداد خوب باید هزینه خروج را هم کاهش دهد.

۷. آنبردینگ و پیاده‌سازی اولیه؛ هزینه‌ای که باید خروجی مشخص داشته باشد

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

مسئله این نیست که چرا سرویس‌دهنده برای آنبردینگ هزینه دریافت می‌کند؛ مسئله این است که در برابر این هزینه دقیقاً چه چیزی تحویل می‌دهد.

آنبردینگ نباید صرفاً به چند جلسه آموزشی و معرفی پنل محدود شود. این فرایند باید خروجی مشخص داشته باشد؛ از جمله:

• بررسی Tracking Plan
• بازبینی دسته‌بندی eventها
• کمک به طراحی ۳ تا ۵ جرنی اولیه
• تست و عیب‌یابی eventها
• آموزش تیم مارکتینگ و محصول
• تعریف Role و سطح دسترسی‌ها
• کمک به تنظیم Frequency Cap
• کمک به طراحی Control Group
• همراهی تا اولین Go-live واقعی

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

برای مثال، به جای عبارتی کلی مانند «پشتیبانی آنبردینگ»، بهتر است در قرارداد مشخص شود:

«تحویل و بررسی نسخه اول Event Schema، دو جلسه تست و عیب‌یابی فنی، پیاده‌سازی سه جرنی آماده اجرا با همکاری تیم مارکتینگ و محصول، آموزش تیم و پشتیبانی تا ۳۰ روز پس از Go-live.»

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

۸. SLA؛ آن را با سناریوهای واقعی ایران بررسی کنید

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

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

همچنین ممکن است:

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

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

بنابراین پیش از امضا باید مشخص شود:

• معیار اندازه‌گیری Uptime و Availability چیست؟
• آیا دسترسی از ایران در SLA لحاظ شده است؟
• اگر مشکل از ISP، فیلترینگ یا محدودیت منطقه‌ای باشد، چه اتفاقی می‌افتد؟
• اگر یک کانال مشخص مانند ایمیل، پوش یا واتساپ دچار اختلال شود، هزینه آن کانال چگونه محاسبه می‌شود؟
• اگر سرویس در یک ماه قابل استفاده نباشد، جبران چگونه انجام می‌شود؟ اعتبار، تمدید مدت قرارداد یا کاهش هزینه؟
• برای ثبت درخواست جبران خسارت، چه فرایندی وجود دارد؟

در بسیاری از SLAها، مواردی مانند به‌روزرسانی‌های زمان‌بندی‌شده، مشکلات سرویس‌دهندگان ثالث، ISP، زیرساخت اینترنت یا خطای سمت مشتری از محاسبه Downtime خارج می‌شوند.

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

بنابراین SLA را نباید فقط به‌عنوان یک سند حقوقی خواند؛ باید آن را با سناریوهای واقعی استفاده در ایران بررسی کرد.

۹. توسعه فازبندی‌شده؛ از روز اول برای همه قابلیت‌ها هزینه ندهید

یکی از بهترین روش‌ها برای ارزان‌تر بستن قرارداد، این است که از ابتدا قرارداد کامل با تمام قابلیت‌ها و ظرفیت‌ها بسته نشود.

بسیاری از شرکت‌ها در شروع مذاکره با هیجان وارد می‌شوند و می‌خواهند از همان ماه اول همه‌چیز فعال باشد:

• همه کانال‌ها
• همه کاربران
• همه eventها
• نگهداشت بلندمدت داده‌ها
• بالاترین سطح پشتیبانی
• چندین جرنی هم‌زمان

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

پس چرا باید از روز اول هزینه کامل پرداخت شود؟

راهکار بهتر، اتصال قرارداد به یک رول‌اوت مرحله‌ای (Phased Rollout) است.

برای مثال:

سه ماه اول:
فاز پیاده‌سازی با MAU محدود، event محدود، کانال محدود، staging فعال و هزینه پایین‌تر.

سه ماه دوم:
Go-live با چند جرنی اصلی و افزایش تدریجی MAU.

از ماه ششم به بعد:
ورود به پلن کامل، در صورتی که KPIهای اولیه محقق شده باشند.

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

در مذاکره باید شفاف گفته شود:

«ما نمی‌خواهیم برای خدماتی هزینه پرداخت کنیم که هنوز از نظر فنی و عملیاتی آماده استفاده از آن نیستیم.»

۱۰. تخفیف سالانه؛ همیشه بهترین انتخاب نیست

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

این تخفیف‌ها جذاب هستند، اما همیشه در سال اول بهترین انتخاب نیستند.

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

در سال اول بهتر است بین تخفیف و انعطاف‌پذیری تعادل ایجاد شود.

برای مثال:

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

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

۱۱. استفاده مازاد بر قرارداد؛ جایی که هزینه‌های پنهان ظاهر می‌شوند

در بسیاری از قراردادهای مارکتینگ اتومیشن، مسئله اصلی قیمت پایه نیست؛ بلکه هزینه مصرف مازاد است.

باید از ابتدا مشخص شود:

• اگر از سقف MAU عبور کنیم چه اتفاقی می‌افتد؟
• اگر تعداد eventها افزایش پیدا کند، هزینه چگونه محاسبه می‌شود؟
• اگر تعداد ایمیل‌های ارسالی بیشتر شود، تعرفه چگونه تغییر می‌کند؟
• اگر یک کانال مانند پوش رایگان باشد اما in-app یا Web Push هزینه جدا داشته باشد، سقف استفاده آن چقدر است؟
• اگر خروجی گرفتن از داده‌ها بیشتر از حد مشخص انجام شود، هزینه آن چقدر خواهد بود؟

شفاف نبودن این موارد می‌تواند در آینده باعث ایجاد هزینه‌های پیش‌بینی‌نشده شود.

همچنین بهتر است در قرارداد یک بازه انعطاف یا اصطلاحاً Grace Period در نظر گرفته شود؛ به این معنا که با یک افزایش کوتاه‌مدت مصرف، بلافاصله وارد پلن بالاتر نشوید.

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

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

۱۲. دام باندلینگ؛ چیزی را نخرید که استفاده نمی‌کنید

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

برای مثال:

• فقط خروجی پیشرفته داده‌ها را می‌خواهید، اما باید AI، کانال‌های بیشتر یا سطح بالاتر پشتیبانی را هم خریداری کنید.
• فقط به قابلیت Control Group نیاز دارید، اما این ویژگی تنها در پلن سازمانی ارائه می‌شود.

در چنین شرایطی باید مذاکره کرد:

• آیا این قابلیت به‌صورت جداگانه قابل خرید است؟
• آیا می‌توان فقط برای شش ماه اول آن را فعال کرد؟
• آیا امکان باز کردن باندل وجود دارد؟
• آیا می‌توان این قابلیت را در ازای تعهد طولانی‌تر دریافت کرد؟

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

اصل ساده است:

قابلیتی را خریداری نکنید که تیم شما در شش ماه آینده از آن استفاده نخواهد کرد.

۱۳. امنیت و NDA؛ محرمانگی کافی نیست

بسیاری از شرکت‌ها به دلیل حساسیت داده‌ها، هنگام انتخاب ابزارهای داخلی یا خارجی مارکتینگ اتومیشن با تردید مواجه می‌شوند. این نگرانی قابل درک است.

اما گاهی به جای مذاکره دقیق درباره امنیت داده، تنها یک NDA عمومی امضا می‌شود و تصور می‌شود مسئله حل شده است.

در حالی که NDA ضروری است، اما کافی نیست.

باید مشخص شود:

• چه داده‌ای به سرویس ارسال می‌شود؟
• آیا امکان حذف یا Hash کردن داده‌های شخصی (PII) وجود دارد؟
• چه فیلدهایی باید Mask شوند؟
• چه افرادی در سمت سرویس‌دهنده به داده‌ها دسترسی دارند؟
• آیا Access Log وجود دارد؟
• خروجی گرفتن از داده‌ها توسط چه Roleهایی امکان‌پذیر است؟
• آیا رمزنگاری داده‌ها در سطح فیلد امکان‌پذیر است؟
• پس از پایان قرارداد، داده‌ها با چه روالی از سرورهای سرویس‌دهنده حذف می‌شوند؟

گاهی با کاهش داده‌های حساس، می‌توان هم ریسک امنیتی را کاهش داد و هم هزینه را کنترل کرد.

لازم نیست همه اطلاعات کاربران را به ابزار ارسال کنیم. برای بسیاری از جرنی‌ها، یک User ID، چند Attribute غیرحساس و eventهای رفتاری کافی است.

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

۱۴. مالکیت داخلی؛ وابستگی بلندمدت ایجاد نکنید

اگر تمام کارها را سرویس‌دهنده برای شما انجام دهد، در ماه اول احتمالاً تجربه ساده‌تری خواهید داشت. اما در ماه ششم، برای هر تغییر کوچک به آن‌ها وابسته می‌شوید.

این وابستگی هم هزینه دارد و هم سرعت تیم را کاهش می‌دهد.

در قرارداد باید بخشی از آنبردینگ و آموزش به توانمندسازی تیم داخلی اختصاص پیدا کند.

هدف این نیست که سرویس‌دهنده همیشه برای شما جرنی طراحی کند؛ هدف این است که تیم مارکتینگ یا محصول شما بتواند پس از مدتی:

• جرنی طراحی کند.
• سگمنت بسازد.
• پیام‌ها را تست کند.
• گزارش‌ها را تحلیل کند.
• خطاها را تشخیص دهد.
• تغییرات مورد نیاز را مدیریت کند.

بنابراین به جای خرید پشتیبانی نامحدود و مبهم، روی آموزش درست سرمایه‌گذاری کنید.

اگر تیم داخلی به بلوغ برسد، هزینه عملیاتی کسب‌وکار در بلندمدت کاهش پیدا می‌کند.

جمع‌بندی: ارزان‌تر خریدن، نتیجه مذاکره دقیق‌تر است

اگر بخواهم همه ۱۴ نکته مطرح‌شده را جمع‌بندی کنم، می‌توان گفت:

• قرارداد مارکتینگ اتومیشن را با تخفیف گرفتن ارزان نمی‌کنند؛ با دقیق بستن ارزان می‌کنند.
• ارزان‌تر بستن قرارداد یعنی MAU را درست تعریف کنیم.
• Eventهای اضافی ارسال نکنیم.
• داده‌های تستی را وارد محیط Production نکنیم.
• کانال‌ها را به‌صورت جداگانه مذاکره کنیم.
• نگهداشت داده‌ها را بر اساس چرخه خرید کسب‌وکار خودمان انتخاب کنیم.
• امکان Export داده‌ها را از روز اول در قرارداد لحاظ کنیم.
• فرایند آنبردینگ را شفاف کنیم و آن را به خروجی‌های مشخص متصل کنیم.
• SLA را با واقعیت‌های استفاده در ایران بررسی کنیم.
• توسعه استفاده از سرویس را مرحله‌بندی کنیم.
• هزینه استفاده مازاد را از ابتدا مشخص کنیم تا در آینده باعث اختلاف نشود.
• فقط قابلیت‌هایی را خریداری کنیم که در آینده نزدیک واقعاً مورد استفاده قرار می‌گیرند.

در نهایت، سوال اصلی در مذاکره این نیست که:

«چقدر تخفیف می‌دهید؟»

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

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

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

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