چطور اپ ساختهشده با هوش مصنوعیتان را به ابزارهایی که همین حالا استفاده میکنید وصل کنید
اپ ساختهشده با هوش مصنوعی شما تنها زندگی نمیکند. دیر یا زود باید با Google Sheets، Slack، Zapier یا هر چیز دیگری که تیمتان با آن کار میکند حرف بزند. این هم سادهترین راه برای سیمکشی کردنش بدون خراب کردن آنچه قبلاً ساختهاید.
یک لحظهٔ آشنا در زندگی یک اپ ساختهشده با هوش مصنوعی: کار میکند، یک هفته از آن استفاده میکنید، و بعد متوجه میشوید که دارید داده را از آن کپی میگیرید.
شاید دارید ثبتنامهای مشتری جدید را در یک Google Sheet میچسبانید که فروشندهتان آن را میخواند. شاید فرمهای ارسالشده را دستی به یک کانال Slack فوروارد میکنید. شاید تقویم تیمتان در یک جا زندگی میکند و رزروهایتان در جای دیگر، و شما چسب انسانی بین آن دو هستید.
این همان لحظهای است که باید اپتان را به بقیهٔ ابزارهایتان وصل کنید. به یک برنامهنویس نیاز ندارید. به یک تصویر روشن از اینکه چه چیزی باید با چه چیزی حرف بزند، و چند تصمیم دربارهٔ چگونگی آن نیاز دارید. این راهنمایی است برای جا انداختن آن در مجموعهابزاری که همین حالا استفاده میکنید.
حقیقت صادقانه دربارهٔ یکپارچهسازیها
بیشتر مردم یکپارچهسازیها را مثل یک قابلیت میبینند که اضافه میکنید، مثل حالت تاریک یا یک نوار جستوجو. اما اینطور نیست. یکپارچهسازیها توافقهایی میان دو سیستماند دربارهٔ اینکه چه کسی مالک چه دادهای است و وقتی چیزی تغییر میکند چه باید بشود.
پیش از اینکه از اپساز هوش مصنوعیتان بخواهید «به Slack وصل شو»، به سه پرسش پاسخ دهید:
- چه تغییراتی در اپ من باید چیزی را در جای دیگری راه بیندازد؟ (یک ثبتنام جدید، یک بهروزرسانی وضعیت، یک فایل آپلودشده.)
- وقتی آن تغییرات رخ میدهند، در جای دیگر چه باید بشود؟ (یک پیام بفرست، یک ردیف اضافه کن، یک ایمیل ارسال کن.)
- آیا چیزی باید به اپ من برگردد؟ (گاهی پاسخ نه است، که خیلی آسانتر است.)
هر چه دربارهٔ این سه چیز روشنتر باشید، یکپارچهسازی سادهتر است. دلیل بههمریختگی یکپارچهسازیها معمولاً فناوری نیست — این است که هیچکس از قبل تصمیم نگرفته کدام سیستم «مالک» یک قطعه اطلاعات مشخص است. اگر هم اپ شما و هم Google Sheet شما هر دو فکر کنند منبع حقیقت برای ایمیلهای مشتریاند، تا ابد دارید آن دو را با هم تطبیق میدهید.
سه راه برای وصل کردن چیزها
اساساً سه الگو برای قلاب کردن اپتان به ابزارهای دیگر وجود دارد. یکی را که جا میافتد انتخاب کنید و دربارهٔ بقیه زیاد فکر نکنید.
۱. اعلانهای خروجی (یکطرفه به بیرون)
این سادهترین است و موارد بیشتری از آنچه مردم انتظار دارند را پوشش میدهد. اپ شما کاری میکند. جایی پیامی میفرستد. تمام.
نمونهها:
- یک ارسال فرم جدید به یک کانال Slack پست میشود.
- یک مشتری جدید از طریق ابزار ایمیلتان یک ایمیل خوشآمدگویی راه میاندازد.
- از یک فایل آپلودشده یک کپی در یک پوشهٔ مشترک Google Drive قرار میگیرد.
به اپساز هوش مصنوعیتان بگویید: «وقتی یک پروژهٔ جدید ساخته میشود، یک پیام به یک کانال Slack بفرست با نام پروژه، نام مشتری و یک لینک به صفحهٔ پروژه.» این یک دستور واحد است و بیشتر اپسازها آن را با یک وبهوک یا یکپارچهسازی داخلی Slack سیمکشی میکنند.
این الگو کار میکند چون چیزی به عقب جریان پیدا نمیکند. Slack سعی نمیکند اپ شما را بهروزرسانی کند. اپ شما شلیک میکند و فراموش میکند. اگر Slack یک ساعت از کار بیفتد، اپ شما همچنان درست کار میکند — فقط تا وقتی برگردد اعلان نمیگیرید.
۲. همگامسازیهای زمانبندیشده (یکطرفه به داخل یا بیرون، روی ساعت)
وقتی ابزاری دارید که کس دیگری آن را بهروزرسانی میکند و اپ شما باید از تغییرات باخبر شود، آسانترین الگو یک همگامسازی زمانبندیشده است. هر ساعت یک بار، هر روز یک بار، اپ شما جدیدترین دادهها را به داخل میکشد.
نمونهها:
- روزی یک بار، ردیفهای جدید را از یک Google Sheet بهعنوان آیتمهای پیشنویس برای بررسی به اپتان بکشید.
- ساعتی یک بار، فهرست رزروهای پیشرو را از تقویمتان تازه کنید.
دلیل اینکه این از یکپارچهسازیهای بلادرنگ خیلی آسانتر است: ترتیب اهمیت ندارد. اگر یک همگامسازی امروز شکست بخورد، همگامسازی فردا همه چیز را جبران میکند. لازم نیست هر حالت مرزی را آنطور که در یک اتصال زنده مدیریت میکنید، مدیریت کنید.
بیشتر اپسازهای هوش مصنوعی میتوانند یک کار زمانبندیشده را با یک دستور برپا کنند: «هر روز صبح ساعت ۸، پاسخهای جدید را از این Google Form بگیر و برای هر کدام یک رکورد در جدول Submissions بساز.»
۳. وبهوکها (الگوی بلادرنگ)
الگوی سوم، و آن که باید با احتیاط با آن رفتار کرد، وبهوکهاست. یک وبهوک یک پیام کوچک است که ابزار دیگری هر وقت چیزی رخ میدهد به اپ شما میفرستد. این نسخهٔ زندهٔ یک همگامسازی زمانبندیشده است.
وبهوکها قدرتمندند و یکپارچهسازیهای جدی با آنها ساخته میشوند. همچنین جاییاند که اپهای ساختهشده با هوش مصنوعی بیش از همه از مسیر منحرف میشوند، چون دارید به سرویس دیگری اعتماد میکنید که داده را درست برایتان بفرستد، و به اپتان اعتماد میکنید که هر چه دریافت میکند را مدیریت کند.
وقتی از وبهوک استفاده کنید که:
- به پاسخ در عرض چند ثانیه نیاز دارید، نه چند دقیقه.
- ابزار مبدأ آنها را ارائه میدهد (بیشتر ابزارهای مدرن این کار را میکنند).
- حاضرید حالتهای شکست را آزمایش کنید — اگر وبهوک دو بار برسد چه میشود؟ اگر اصلاً نرسد چه؟
یک دستور معقول برای وبهوک: «یک نقطهٔ پایانی وبهوک در /webhooks/stripe اضافه کن که رویدادهای پرداخت را بپذیرد. وقتی یک پرداخت موفق میرسد، مشتری منطبق را با ایمیل پیدا کن و وضعیتش را به ‹پرداختشده› بهروزرسانی کن.» بعد آزمایشش کنید. یک پرداخت قلابی بفرستید. یک پرداخت واقعی بفرستید. دو تا پشت سر هم بفرستید.
مسئلهٔ Zapier
خیلی از مردم وقتی میخواهند چیزها را به هم وصل کنند، اول سراغ Zapier یا Make میروند. دلیل خوبی هم دارد — آن ابزارها خودشان یکپارچهسازی بهعنوان یک محصولاند. به شما یک سازندهٔ بصری میدهند که در آن «وقتی X در ابزار A رخ میدهد، Y را در ابزار B انجام بده» را به هم وصل میکنید.
شما کاملاً میتوانید Zapier را با اپ ساختهشده با هوش مصنوعیتان استفاده کنید. تمیزترین الگو این است:
- اپ شما وقتی چیز جالبی رخ میدهد یک وبهوک به Zapier میفرستد.
- Zapier پخشکردن را انجام میدهد — پیامهای Slack، اعلانهای ایمیلی، ردیفهای صفحهٔ گسترده، بهروزرسانیهای CRM.
چرا به جای اینکه از اپساز هوش مصنوعیتان بخواهید مستقیماً به هر ابزار وصل شود، از مسیر Zapier برویم؟ دو دلیل. اول، وقتی فردا تصمیم بگیرید که میخواهید یک کارت Trello هم ساخته شود، آن را در Zapier در دو دقیقه اضافه میکنید، به جای اینکه از اپساز هوش مصنوعیتان بخواهید دوباره استقرار دهد. دوم، اگر یک ابزار پاییندستی API خود را تغییر دهد (و این کار را میکنند)، Zapier این را بدون اینکه لازم باشد به اپتان دست بزنید مدیریت میکند.
نقطهٔ معاوضه هزینه است. اگر حجم بالایی داشته باشید، Zapier سریع گران میشود. اگر کمتر از چند صد رویداد در ماه میفرستید، Zapier احتمالاً انتخاب درست است. اگر دهها هزار میفرستید، از اپساز هوش مصنوعیتان بخواهید مستقیماً یکپارچه شود.
پیش از اعتماد، چه چیزی را آزمایش کنید
یکپارچهسازیها بیسروصدا شکست میخورند. این بدترین ویژگیشان است. فرم شما ممکن است همگامسازی با صفحهٔ گستردهتان را متوقف کند، و شما تا یک هفته بعد که کسی متوجه میشود صفحهٔ گسترده دوازده ردیف کم دارد، خبردار نمیشوید.
سه آزمونی که روی هر یکپارچهسازیای که اضافه میکنید اجرا کنید:
- آیا واقعاً سرتاسری کار میکند؟ فقط تأیید نکنید که اپتان پیام را شلیک کرده. به ابزار مقصد بروید و تأیید کنید که پیام رسیده و درست به نظر میرسد.
- وقتی مقصد از کار افتاده یا اشتباه است چه میشود؟ زپ Zapier خود را متوقف کنید. داده بفرستید. آیا اپ شما با ظرافت آن را مدیریت میکند، یا خطا میدهد و از ذخیرهٔ محلی داده سر باز میزند؟ (ظرافت را میخواهید.)
- آیا راهی برای تلاش مجدد یا ارسال دوباره هست؟ اگر چیزی اشتباه پیش رفت، میتوانید یکپارچهسازی را برای یک رکورد خاص دوباره اجرا کنید؟ اگر پاسخ نه است، یک درِ یکطرفهٔ سقوطی ساختهاید.
اگر اپساز هوش مصنوعیتان داوطلبانه پاسخ اینها را نمیدهد، بپرسید. «از کجا بفهمم که یک پیام Slack در ارسال شکست خورده؟» پرسش معقولی است، و پاسخ باید چیزی شبیه «خطاها اینجا ثبت میشوند، و میتوانید از این صفحه دوباره تلاش کنید» باشد.
یک نقطهٔ شروع معقول
اگر تازه دارید شروع به اضافه کردن یکپارچهسازیها میکنید، این هم یک ترتیب عملی:
- یک اعلان خروجی — مفیدترین یکی را انتخاب کنید. «وقتی یک سرنخ جدید میآید، به Slack پست کن» یا «وقتی یک پروژه بهعنوان تکمیلشده علامت میخورد، به مشتری ایمیل بزن.»
- یک همگامسازی زمانبندیشده — معمولاً کشیدن داده به بیرون از اپتان به جایی که تیمتان همین حالا کار میکند (یک صفحهٔ گستردهٔ مشترک، یک CRM).
- بعد، فقط اگر واقعاً به آن نیاز دارید، یک وبهوک برای یک مورد بلادرنگ خاص.
بیشتر اپها هیچوقت به بیش از این نیاز ندارند. آنهایی که نیاز دارند، کسبوکارهای واقعی را اداره میکنند، و تا وقتی به آن مقیاس برسید، دقیقاً میدانید کدام اتصالها کم است.
اگر دارید به یک اپ ساختهشده با هوش مصنوعی خیره میشوید و حس میکنید مثل یک جزیره است، آن یک یکپارچهسازیای را که این هفته بیشترین کپیپیست را برایتان ذخیره میکند انتخاب کنید و از همانجا شروع کنید. بقیه وقتی آن یکی کار کند، خودشان روشن میشوند.