Zapier эсвэл Make: нэг урсгалын алхам төлбөрийг эргүүлнэ

Техникийн бус баг энгийн урсгалыг хурдан эхлүүлэх бол Zapier, олон салаатай ажлыг нарийн удирдах бол Make-ийг эхэлж үнэлэх нь зүйтэй. TechRadar-ийн хэрэглээнд тулгуурласан үнэлгээ Zapier-ийг техникийн бус багт хүртээмжтэй, Make-ийг салаалсан урсгалд уян хатан боловч сурахад илүү хугацаа шаарддаг гэж үзжээ.

Гэхдээ хэрэглээний хэмжээг тооцохгүйгээр сарын үнийг харьцуулбал сонголт төөрөгдөнө. Маягтын хүсэлтийг CRM-д бүртгээд имэйл илгээх ижил үр дүнд Zapier амжилттай үйлдлийг task-аар, Make ажилласан модулийн үйлдлийг credit-ээр тоолдог. Тиймээс нэг урсгал хэдэн удаа ажиллах, хүсэлт бүрд ямар алхам гүйцэтгэх нь багцын эхлэх үнээс илүү хэрэгтэй мэдээлэл юм.

Task ба credit яг хаана зарцуулагдах вэ?

Zapier-ийн task тоолох дүрэмд амжилттай гүйцэтгэсэн ердийн action task хэрэглэдэг, харин trigger, polling шалгалт, Filter болон Paths алхам хэрэглэдэггүй. Алдаа гарсан эсвэл нөхцөлөөс шалтгаалан ажиллаагүй action мөн тооцогдохгүй. Харин алдаа боловсруулах салаанд амжилттай ажилласан action, эсвэл бүх урсгалыг дахин ажиллуулахад давтагдсан амжилттай action хэрэглээнд орно.

Make-ийн credit-ийн албан ёсны тайлбарт өгөгдөл унших, хайх, бүртгэл үүсгэх, хувиргах зэрэг ердийн модулийн үйлдэл ихэвчлэн нэг credit хэрэглэдэг. Зарим дэвшилтэт боломж илүү credit хэрэглэж болно. Router болон Rollback, Break, Resume, Commit, Ignore зэрэг алдаа боловсруулах модуль өөрөө credit хэрэглэдэггүй ч тэдгээрийн цаана ажилласан ердийн модулиуд хэрэглэнэ.

Иймээс урсгалын зураг дээрх нийт хайрцгийг тоолоод хоёр үйлчилгээний хэрэглээг харьцуулж болохгүй. Zapier-д үр дүнтэй дууссан action гол нэгж бол Make-д хүсэлт хүлээн авах, хайх, хувиргах, цааш илгээх модулийн ажил тус бүр тооцоонд нөлөөлнө. Салаалалт нэмэгдсэн үед аль зам бодитоор ажилласныг мөн ялгах хэрэгтэй.

Маягт → CRM → имэйл: сарын хэрэглээний тооцоо

Дараах нь бодит байгууллагын тайлан бус, сард 10 мянган хүсэлт хүлээн авдаг нөхцөлт жишээ. Хүсэлт бүр CRM-д нэг шинэ бүртгэл үүсгээд нэг имэйл илгээнэ. Давхардал хайх, өгөгдөл хувиргах, алдаа засах, дахин оролдох алхам байхгүй; бүх үйлдэл амжилттай дуусна гэж үзэв.

Zapier-д маягтын шинэ хүсэлт trigger болно. Дараа нь CRM-д бүртгэл үүсгэх, имэйл илгээх гэсэн хоёр ердийн action ажиллавал нэг хүсэлт хоёр task, 10 мянган хүсэлт 20 мянган task хэрэглэнэ. Trigger-ийг гурав дахь task болгон нэмэхгүй. Энэ тоо нь хэрэглээний хэмжээ бөгөөд төлөх мөнгөн дүн хараахан биш.

Make-д маягт хүсэлтээ custom webhook руу илгээдэг хувилбарыг авъя. Make Academy-ийн webhook-ийн тайлбарт хүсэлт ирж scenario ажиллахад custom webhook модуль нэг credit хэрэглэдэг гэж заасан. Түүний дараах CRM болон имэйлийн ердийн модуль тус бүр нэг удаа ажиллавал нэг хүсэлт гурван credit, 10 мянган хүсэлт 30 мянган credit болно.

Хоёр дүнг хооронд нь шууд үнэ болгон хөрвүүлэх аргагүй: task ба credit өөр өөр тооллоготой, багц бүр өөр хэмжээний эрх олгодог. Харин тооцоо нэг чухал зүйлийг ил гаргана. Ижил хүсэлтийг боловсруулахад Zapier-ийн trigger хэрэглээнд орохгүй, Make-ийн сонгосон custom webhook модуль орж байна. Урсгалд нэмсэн нэг төлбөртэй үйлдэл хүсэлт бүр дээр ажиллавал сарын хэрэглээ мөн хүсэлтийн тоогоор өснө.

Маягтын хүсэлт ирэх арга яагаад чухал вэ?

Make-д webhook ашиглах боломж нь маягтын үйлчилгээ хүсэлт илгээж чаддаг эсэхээс хамаарна. Ийм боломжгүй үед scenario өгөгдлийг хуваарийн дагуу шалгах өөр модулиар эхэлж болно. Тэгвэл шинэ хүсэлт олдоогүй шалгалт ч credit хэрэглэх боломжтой тул webhook-той жишээний 30 мянган credit-ийг тэр тохиргоонд хэвээр хэрэглэх нь буруу.

Шалгах давтамж нэмэгдэхэд хоосон шалгалтын хэрэглээ ч нэмэгдэнэ. Гэхдээ нэг шалгалтаар хэд хэдэн шинэ бүртгэл ирж болох учраас шалгалтын тоог хүсэлтийн тоотой адилтгаж болохгүй. Make талын төсөвт шалгасан давтамж, буцсан өгөгдлийн хэмжээ, үргэлжлүүлэн ажилласан модулиудыг тус тус тоолно. Zapier-ийн polling trigger task хэрэглэдэггүй гэсэн дүрэм нь энэ хоёр тохиргооны ялгааг улам тодруулдаг.

Webhook нь зардлаас гадна ажлын цагт нөлөөлнө. Маягтын үйлчилгээтэй холбох, ирсэн талбаруудыг CRM-ийн талбарт тааруулах, имэйлд ашиглах өгөгдлийг шалгах ажил бий. Хуваарьт шалгалт сонговол хүсэлт хэдий хугацаанд хоцорч боловсруулагдахыг багийн шаардлагатай харьцуулна. Эдгээр нь хэрэглээний нэгжид шууд харагддаггүй ч тохируулах болон арчлах ажлын бодит хэсэг юм.

Хайлт, салаалалт, алдаа нэмэгдэхэд

CRM-д бүртгэл үүсгэхээсээ өмнө ижил хүн байгаа эсэхийг хайдаг бол үндсэн жишээ өөрчлөгдөнө. Zapier-д search action task хэрэглэх эсэх нь хайлтын тохиргооноос хамаардаг. Make-д хайлт хийсэн ердийн модуль ажиллавал credit хэрэглэнэ. Давхардал олдсон үед бүртгэл шинээр үүсгэхгүй байхаар тохируулсан бол тухайн хүсэлтийн цаашдын хэрэглээ ч өөр болно.

Хүсэлтийг борлуулалтын өөр багт чиглүүлэхэд Zapier-ийн Paths, Make-ийн router өөрсдөө үндсэн хэрэглээг нэмэхгүй. Гэхдээ сонгогдсон замд ажилласан CRM, имэйл эсвэл мэдэгдлийн үйлдэл тооцогдоно. Нэг хүсэлт хэд хэдэн замаар үргэлжилж, хэд хэдэн амжилттай үйлдэл хийвэл «нэг хүсэлт = нэг төлбөртэй ажил» гэсэн төсөв хүрэлцэхгүй.

Алдаа боловсруулах зардал мөн хоёр давхаргатай. Make-ийн error handler модуль credit хэрэглэхгүй ч алдааны дараа мэдэгдэл илгээх зэрэг ердийн модуль ажиллавал хэрэглээ үүснэ. Zapier-д алдааны салааны амжилттай action task хэрэглэнэ. Давтан ажиллуулахдаа CRM-ийн бүртгэл давхар үүсэх, имэйл давхар очих эрсдэлийг хэн шалгахыг шийдэх нь төлбөртэй нэгж тоолохоос тусдаа хүний ажил юм.

Багцын үнэ ба багийн цагийг хамт харьцуул

Zapier-ийн багцын хуудсанд сарын task-ийн хэмжээг сонгодог, олон алхамтай Zap нь төлбөртэй багцын боломж гэж заасан. Хязгаарт хүрсний дараа нэмэлт task-ийн төлбөрийг идэвхжүүлсэн бол хэрэглээ үргэлжилж болно; идэвхжүүлээгүй бол шинэ ажил түр зогсоно. Make-д ч худалдан авсан credit дуусахад scenario үргэлжлэн ажиллахын тулд нэмэлт credit эсвэл тохирох багц шаардлагатай.

Тиймээс дээрх нөхцөлт урсгалд Zapier талд 20 мянган task, Make талд 30 мянган credit багтаах сонголтыг үнийн ижил хугацаа, ижил төлбөрийн давтамжаар харьцуулна. Эхлэх үнэ нь бага харагдсан багц шаардлагатай хэрэглээг багтаахгүй байж болно. Монголын баг ам.долларын төлбөрөө төгрөгөөр төсөвлөдөг бол ханшийн өөрчлөлт болон төлбөрийн үйлчилгээний нөхцөлийг өөрийн зардалд нэмж тооцох нь зүйтэй.

Тохируулах болон засварлах цагийг платформын төлбөрөөс тусад нь үнэл. Энгийн дарааллыг техникийн бус баг Zapier-д хурдан ажиллуулж чадвал эхлэх үеийн хөдөлмөрийн зардал бага байж болно. Олон нөхцөл, өгөгдлийн хувиргалт, алдааны салаатай урсгалыг хариуцах чадвартай хүн байгаа бол Make-ийн харагдах бүтэц засвар хийхэд үнэ цэнтэй байж мэднэ. Аль нь хэдэн цаг хэмнэхийг багийн туршлага, ашиглах CRM болон маягтын үйлчилгээ тодорхойлно.

Цөөн алхамтай, хурдан эхлүүлэх шаардлагатай ажилд Zapier-ийн тохируулах хялбар байдал жин дарна. Давтамж өндөр эсвэл олон салаатай ажилд Make-ийн удирдах боломжийг үнэлэх шалтгаан нэмэгдэнэ. Эцсийн сонголтод нэг хүсэлтийн төлбөртэй алхмууд, сарын хүсэлтийн хэмжээ, ашиглах багц, урсгалыг арчлах хүний цагийг нэг төсөвт нийлүүлэх хэрэгтэй.

Мөн уншаарай:

• n8n эсвэл Make: сарын үнэ биш, алхам тоолох арга нь сонголтыг шийднэ
• CapCut эсвэл Adobe Express: хурдан эвлүүлэг үү, брэндийн урсгал уу
• ChatGPT эсвэл Gemini: ижил үнээс илүү экосистемийн түгжээ шийднэ