«سفارشم کی میرسه؟»
«بسته من الان کجاست؟»
«کد رهگیری برای من نیومده.»
اگر فروشگاه اینترنتی دارید، احتمالاً این سؤالها برایتان آشناست.
گاهی مشکل این نیست که اطلاعات را در سایت نگذاشتهاید. ممکن است زمان ارسال را در صفحه محصول نوشته باشید، در صفحه تشکر بعد از خرید توضیح داده باشید که کد رهگیری چه زمانی ارسال میشود و حتی داخل حساب کاربری مشتری هم وضعیت سفارش را نمایش دهید.
با این حال باز هم تلفن زنگ میخورد:
«سفارشم چی شد؟»
در واتساپ پیام میآید:
«کد رهگیریم رو میفرستید؟»
و مشتری دیگری در چت سایت میپرسد:
«کی به دستم میرسه؟»
در یک فروشگاه واقعی که درباره فرایندش اطلاعات داشتیم، روزانه حدود ۱۰۰ سفارش ثبت میشد و تقریباً ۳۰ مشتری در روز فقط برای سؤال درباره وضعیت سفارش، زمان تحویل یا کد رهگیری تماس میگرفتند یا پیام میدادند.
بعضی مشتریها اصلاً وارد حساب کاربری خود نمیشدند. بعضی نمیدانستند از کجا باید وضعیت سفارش را ببینند. گاهی هم کد رهگیری ثبت شده بود اما پیامک به مشتری نرسیده بود و مسئول سایت مجبور میشد سفارش را پیدا کند و کد را دوباره دستی بفرستد.
این عدد را نمیتوان به همه فروشگاهها تعمیم داد، اما یک سؤال مهم ایجاد میکند:
اگر تعداد سفارشهای فروشگاه دو برابر شود، آیا حجم کار دستی پشتیبانی هم باید دو برابر شود؟
لزومی ندارد.
بخشی از این فرایند را میتوان با اطلاعرسانی بهتر، یک افزونه مناسب، مسیر سادهتر برای پیگیری سفارش، چتبات متصل به اطلاعات واقعی یا یک اتوماسیون یکپارچهتر بهبود داد.
نکته مهم این است که راهحل را از قبل انتخاب نکنیم.
ممکن است یک فروشگاه فقط به یک تغییر کوچک نیاز داشته باشد و فروشگاه دیگری لازم باشد چند سیستم را به هم متصل کند.
در دانیرا نقطه شروع، انتخاب ابزار نیست؛ بررسی فرایند فعلی کسبوکار است.
باید ببینیم مشتری در کدام مرحله سؤالش شکل میگیرد، تیم شما برای پیدا کردن جواب چه مراحلی را طی میکند و کدام بخش واقعاً ارزش خودکار شدن دارد.
چرا مشتری سؤال میپرسد، حتی وقتی همهچیز را در سایت نوشتهایم؟
این جمله را زیاد از صاحبان فروشگاه میشنویم:
«همهچیز رو نوشتیم. توی صفحه محصول گفتیم، بعد از خرید توضیح دادیم، توی حساب کاربری هم هست. ولی باز تماس میگیرن!»
واقعیت این است که همیشه نمیتوان مسئله را با «توضیحات بیشتر» حل کرد.
مشتری لزوماً نمیخواهد ساختار سایت شما را یاد بگیرد.
ممکن است نداند باید وارد کدام صفحه شود، رمزش را فراموش کرده باشد، نداند با چه شمارهای ثبتنام کرده یا اصلاً حوصله ورود به حساب کاربری را نداشته باشد.
گاهی هم خیلی ساده، پیام دادن در واتساپ یا تماس با پشتیبانی را سریعتر از گشتن در سایت میداند.
از دید صاحب فروشگاه، اطلاعات وجود دارد.
اما از دید مشتری، رسیدن به اطلاعات سختتر از پرسیدن سؤال است.
و تا زمانی که پرسیدن سادهتر باشد، بخشی از مشتریها همان مسیر را انتخاب میکنند.
پس سؤال فقط این نیست:
«آیا اطلاعات را در سایت گذاشتهایم؟»
سؤال بهتر این است:
«مشتری با چند مرحله میتواند به جوابش برسد؟»
همین تفاوت کوچک میتواند مسیر طراحی راهحل را عوض کند.
قبل از خودکار کردن جواب، بعضی سؤالها را اصلاً حذف کنیم
اولین قدم همیشه ساخت چتبات نیست.
گاهی باید ببینیم چه چیزی باعث شده سؤال شکل بگیرد.
مثلاً مشتری بعد از خرید فقط میبیند:
«سفارش شما با موفقیت ثبت شد.»
اما هنوز نمیداند بعدش چه اتفاقی میافتد.
اگر همانجا به او گفته شود:
«سفارش شما ثبت شد. آمادهسازی معمولاً دو تا سه روز کاری زمان میبرد. پس از تحویل سفارش به شرکت ارسال، اطلاعات رهگیری برای شما فرستاده خواهد شد.»
بخشی از ابهام همان ابتدا از بین میرود.
همین منطق را میتوان در مراحل مختلف سفارش ادامه داد.
| مرحله سفارش | اطلاعاتی که مشتری احتمالاً نیاز دارد |
|---|---|
| قبل از خرید | زمان تقریبی آمادهسازی و شرایط ارسال |
| بعد از ثبت سفارش | تأیید ثبت و توضیح مرحله بعد |
| هنگام آمادهسازی | اینکه سفارش هنوز ارسال نشده است |
| بعد از ارسال | روش ارسال و کد رهگیری |
| در مسیر | آخرین وضعیت معتبر مرسوله، در صورت دسترسی |
| بروز مشکل | توضیح وضعیت و قدم بعدی |

اطلاعرسانی خودکار فقط برای جواب دادن نیست؛ میتواند جلوی شکل گرفتن بخشی از سؤالها را بگیرد.
البته نباید اطلاعاتی را اعلام کنیم که واقعاً در اختیارمان نیست.
اگر فقط میدانیم آمادهسازی معمولاً دو روز طول میکشد، نباید تاریخ قطعی تحویل را حدس بزنیم.
اگر شرکت حملونقل زمان دقیق تحویل را مشخص نمیکند، سیستم هم نباید چنین تاریخی بسازد.
اگر مشتری وارد حساب کاربری نمیشود، مسیر کوتاهتری بسازیم
این یکی از کاربردیترین فرصتهای اتوماسیون در فروشگاه اینترنتی است.
لزومی ندارد مشتری برای دیدن یک اطلاعات ساده حتماً وارد حساب کاربری شود، رمز عبورش را پیدا کند، وارد بخش سفارشها شود و سفارش موردنظر را باز کند.
میتوان مسیر بسیار کوتاهتری ساخت.
مثلاً یک گزینه واضح در سایت داشته باشیم:
«پیگیری سریع سفارش»
مشتری شماره موبایل یا شماره سفارش را وارد کند.
سیستم با یک روش ساده بررسی کند سفارش واقعاً متعلق به همان مشتری است؛ مثلاً با کد یکبارمصرف، اطلاعات سفارش یا یک لینک امن.
بعد فقط اطلاعات مرتبط با سفارش خودش را ببیند.
شماره سفارش یا موبایل ← تأیید ساده مشتری ← نمایش وضعیت سفارش و اطلاعات رهگیری
برای مثال:
سفارش شماره ۱۲۴۸
وضعیت سفارش: ارسال شده
روش ارسال: پست
کد رهگیری: …
آخرین وضعیت معتبر مرسوله: وارد مرکز توزیع مقصد شده است.
یا ممکن است پاسخ این باشد:
«سفارش شما هنوز در مرحله آمادهسازی است و کد رهگیری برای آن ثبت نشده است.»
برای فروشگاههای ووکامرسی حتی یک قابلیت پایه برای مشاهده وضعیت سفارش بدون ورود کامل به حساب وجود دارد. فرم پیگیری سفارش ووکامرس به مشتری اجازه میدهد با شماره سفارش و ایمیل صورتحساب وضعیت و جزئیات سفارش را مشاهده کند.
اما لازم نیست تجربه نهایی فروشگاه به همان فرم پیشفرض محدود بماند.
بسته به نیاز کسبوکار میتوان مسیر کوتاهتر و سادهتری طراحی کرد.
نکته امنیتی: صرفاً با دانستن یک شماره سفارش نباید آدرس، اطلاعات شخصی یا جزئیات خرید در اختیار هر فردی قرار بگیرد. هدف حذف امنیت نیست؛ هدف کوتاه کردن مسیر رسیدن مشتری به جواب است.

اینجا دانیرا چه چیزی را بررسی میکند؟
قبل از ساخت چنین قابلیتی باید ببینیم اطلاعات سفارش الان کجا قرار دارد، مشتری معمولاً چه اطلاعاتی در دسترس دارد و برای تأیید اینکه سفارش متعلق به همان مشتری است چه روش سادهای مناسبتر است.
بعد بررسی میشود که آیا یک قابلیت آماده یا افزونه موجود نیاز را حل میکند یا بهتر است مسیر اختصاصیتری برای پیگیری طراحی شود.
گاهی پاسخ واقعاً یک افزونه است.
و این هم اتوماسیون محسوب میشود.
اگر یک افزونه بتواند کاری را که امروز نیروی انسانی بارها انجام میدهد بهشکل قابلاعتماد انجام دهد، دلیلی ندارد فقط برای پیچیدهتر شدن پروژه سراغ راهحل بزرگتری برویم.
مشتری مجبور نباشد برای کد رهگیری تماس بگیرد
یکی از واضحترین نمونههای کار تکراری همین است:
کد رهگیری وجود دارد، اما به دست مشتری نرسیده است.
بعد چه اتفاقی میافتد؟
مشتری پیام میدهد ← پشتیبانی سفارش را پیدا میکند ← وضعیت ارسال را بررسی میکند ← کد رهگیری را پیدا میکند ← کد را دوباره برای مشتری میفرستد
و مدتی بعد همین فرایند برای مشتری دیگری تکرار میشود.
در ظاهر مشکل کوچکی است، اما کافی است هر روز چند بار اتفاق بیفتد تا تبدیل به یک وقفه دائمی برای تیم شود.
اول باید فرایند فعلی بررسی شود.
- آیا کد رهگیری درست ثبت میشود؟
- آیا در جای مناسبی ذخیره میشود؟
- آیا پیام برای مشتری ارسال میشود؟
- اگر ارسال نشد، فروشگاه متوجه میشود؟
- آیا مشتری میتواند بعداً بدون تماس با پشتیبانی همان کد را دوباره پیدا کند؟
فرایند ارسال کد رهگیری ساده به نظر میرسد، اما کافی است یکی از مراحل ثبت کد، ارسال پیام یا ذخیره اطلاعات درست انجام نشود تا دوباره کار به پشتیبانی برگردد.
ممکن است انتخاب و تنظیم درست یک افزونه همین مسئله را کامل حل کند.
در فروشگاه دیگری ممکن است کد رهگیری در سیستم جداگانهای تولید شود و لازم باشد بهصورت خودکار وارد سیستم سفارش شود.
هر دو اتوماسیون هستند؛ فقط راهحل آنها یکسان نیست.
فقط کد رهگیری ندهیم؛ وضعیت بسته را هم نشان بدهیم
کد رهگیری به مشتری اجازه میدهد وارد سامانه شرکت حملونقل شود و وضعیت بسته را بررسی کند.
برای خیلی از فروشگاهها همین کافی است.
اما در بعضی موارد میتوان یک مرحله جلوتر رفت.
اگر سرویس حملونقل یا سرویس مورد استفاده فروشگاه امکان دریافت اطلاعات رهگیری را در اختیار سیستم قرار دهد، میتوان با استفاده از کد مرسوله آخرین وضعیت معتبر ثبتشده بسته را دریافت کرد.
در این صورت مشتری بهجای اینکه فقط ببیند:
«کد رهگیری: ۱۲۳۴۵۶…»
میتواند اطلاعاتی شبیه این ببیند:
- بسته وارد مرکز توزیع مقصد شده است.
- مرسوله برای تحویل در اختیار مأمور قرار گرفته است.
- تحویل ناموفق ثبت شده است.
- مرسوله تحویل گیرنده شده است.
اینجا بهتر است از عبارت «موقعیت لحظهای بسته» استفاده نکنیم. چیزی که معمولاً در اختیار سیستم قرار میگیرد آخرین رویداد یا وضعیت ثبتشده توسط سرویس حملونقل است، نه موقعیت دقیق لحظهای بسته.
امکان اجرای این قابلیت هم به روش ارسال بستگی دارد.
اگر فروشگاه از چند شرکت حملونقل یا پیک محلی استفاده میکند، ممکن است برای هرکدام مسیر متفاوتی وجود داشته باشد.
قبل از طراحی چنین قابلیتی باید بررسی شود سرویس مورد استفاده فروشگاه واقعاً چه اطلاعاتی در اختیار قرار میدهد.
یک قدم جلوتر: سیستم خودش مرسوله را دنبال کند
فرض کنید دیگر نه مشتری و نه پشتیبانی مجبور نباشند مرتب وضعیت بسته را بررسی کنند.
کد رهگیری ثبت میشود و مرسوله وارد فرایند پیگیری میشود.
سیستم در بازههای منطقی وضعیت آن را بررسی میکند.
اگر اتفاق جدیدی نیفتاده، کاری انجام نمیشود.
اما اگر تغییر مهمی رخ دهد، اقدام مناسب انجام میشود.
تحویل به مأمور ← اطلاعرسانی در صورت نیاز
تحویل ناموفق ← هشدار به پشتیبانی
مرسوله در حال برگشت ← مشخص شدن سفارش برای بررسی
تحویل نهایی ← پایان پیگیری مرسوله
تیم پشتیبانی مجبور نیست تکتک بستهها را بررسی کند؛ فقط مواردی که واقعاً نیاز به توجه دارند به تیم میرسند.
هدف فقط این نیست که همان کار قدیمی کمی سریعتر انجام شود.
هدف این است که بخشی از کارهای غیرضروری اصلاً به انسان نرسند.
اگر مشتری باز هم بخواهد سؤالش را بپرسد چه؟
حتی اگر صفحه پیگیری خوبی داشته باشید، بعضی مشتریها باز هم ترجیح میدهند سؤالشان را مستقیم بپرسند.
این لزوماً مشکل نیست.
میتوان همان رفتار طبیعی مشتری را حفظ کرد و پاسخگویی را سادهتر کرد.
مثلاً یک چتبات یا دستیار داخل سایت داشته باشیم.
مشتری مینویسد:
«بسته من کجاست؟»
بعد از اینکه سیستم مطمئن شد سفارش متعلق به همان مشتری است، اطلاعات واقعی سفارش بررسی میشود و پاسخ میتواند چیزی شبیه این باشد:
«آخرین وضعیت ثبتشده مرسوله شما: بسته وارد مرکز توزیع مقصد شده است.»
یا مشتری میپرسد:
«کد رهگیری برای من نیومده.»
اگر کد وجود داشته باشد، همان کد نمایش داده میشود.
اگر هنوز وجود نداشته باشد، پاسخ میتواند این باشد:
«سفارش شما در مرحله آمادهسازی است و هنوز کد رهگیری برای آن ثبت نشده است.»
اگر مشتری بپرسد «کی ارسال میشه؟»، سیستم فقط اطلاعاتی را ارائه میکند که واقعاً برای آن سفارش وجود دارد.
چتبات خوب قرار نیست وضعیت سفارش را حدس بزند؛ باید راه سادهتری برای دسترسی مشتری به اطلاعات واقعی ایجاد کند.
اگر اطلاعات کافی نبود یا موضوع نیاز به تصمیم انسانی داشت، درخواست میتواند به پشتیبانی منتقل شود.
چتبات در اینجا جای تیم پشتیبانی را نمیگیرد؛ سؤالهای تکراری و قابلپاسخ را مدیریت میکند تا انسان روی مواردی تمرکز کند که واقعاً به بررسی نیاز دارند.
و لازم نیست چتبات یک سیستم جدا از بقیه باشد.
همان اطلاعاتی که در صفحه پیگیری استفاده میشود، میتواند برای اطلاعرسانی یا پاسخ به سؤال مشتری هم به کار برود.
یک مشتری صفحه پیگیری را باز میکند، مشتری دیگری سؤالش را در چت میپرسد و نفر دیگری پیام خودکار دریافت میکند؛ اما پشت صحنه، همه از اطلاعات واقعی همان سفارش استفاده میکنند.
وقتی چند بخش باید با هم کار کنند
تا اینجا خیلی از مشکلات ممکن است با تنظیمات سایت یا یک افزونه مناسب حل شوند.
اما بعضی فروشگاهها شرایط پیچیدهتری دارند.
مثلاً اطلاعات سفارش در یک سیستم است، کد رهگیری در سیستم دیگری تولید میشود، پیامک از سرویس دیگری ارسال میشود، وضعیت مرسوله باید از شرکت حملونقل دریافت شود و پشتیبانی هم از چند کانال با مشتری ارتباط دارد.
حالا دیگر با یک کار مستقل روبهرو نیستیم.
با یک فرایند چندمرحلهای روبهرو هستیم.
در این شرایط یک سیستم اتوماسیون پشت صحنه میتواند این بخشها را به هم متصل کند تا اطلاعات بین آنها خودکار جابهجا شود و هر اتفاق، مرحله بعدی مناسب را فعال کند.
یکی از ابزارهایی که میتواند برای ساخت چنین فرایندهایی استفاده شود n8n است. برای مثال در فروشگاههای ووکامرسی میتوان اطلاعات سفارش را دریافت یا بهروزرسانی کرد و آن را به سرویسهای دیگر متصل کرد.
اما برای صاحب کسبوکار، اسم ابزار مهمترین بخش ماجرا نیست.
معنای تجاری آن ساده است: اطلاعاتی که امروز در چند سیستم مختلف پخش شدهاند، میتوانند در یک فرایند واحد با هم کار کنند.
سفارش آماده ارسال شد ← کد رهگیری دریافت شد ← مشتری مطلع شد ← مرسوله وارد پیگیری شد ← تغییر مهم تشخیص داده شد ← اقدام مناسب انجام شد
اگر مشکلی وجود داشت، پشتیبانی مطلع میشود.
اسم ابزار بعد از شناخت نیاز انتخاب میشود، نه قبل از آن.
لازم نیست از روز اول بزرگترین سیستم ممکن را بسازیم
فرض کنید مشکل فعلی فروشگاه فقط این است که کد رهگیری گاهی به مشتری نمیرسد.
در چنین شرایطی احتمالاً منطقی نیست از همان ابتدا چتبات، داشبورد، CRM و یک سیستم بزرگ پیگیری بسازیم.
بهتر است از همان مشکل شروع کنیم.
مرحله اول: ارسال مطمئن کد رهگیری
کد درست ثبت و برای مشتری ارسال شود و بعداً هم قابل دسترسی باشد.
مرحله دوم: پیگیری سریع سفارش
مشتری بتواند با یک مسیر کوتاه و امن وضعیت سفارش خودش را ببیند.
مرحله سوم: نمایش وضعیت مرسوله
اگر اطلاعات سرویس ارسال در دسترس است، آخرین وضعیت معتبر بسته نیز نمایش داده شود.
مرحله چهارم: پیگیری و هشدار خودکار
سیستم تغییرات مهم را دنبال کند و در زمان مناسب به مشتری یا تیم اطلاع دهد.
مرحله پنجم: پاسخگویی خودکار
در صورت نیاز، مشتری همان اطلاعات را از طریق چتبات یا یک دستیار دریافت کند.
مرحله ششم: توسعه سیستم
CRM، گزارشها، داشبورد، کانالهای ارتباطی یا قابلیتهای دیگر فقط در صورت نیاز اضافه شوند.

اتوماسیون خوب لازم نیست از روز اول بزرگ باشد؛ باید از جای درست شروع شود و امکان رشد داشته باشد.
اگر همهچیز طبق انتظار پیش نرفت چه؟
اتوماسیون فقط برای شرایط ایدهآل نیست.
اتفاقاً ارزش واقعی آن زمانی مشخص میشود که یک مرحله درست پیش نرود.
- اگر کد رهگیری ثبت نشده باشد چه؟
- اگر پیام برای مشتری ارسال نشده باشد چه؟
- اگر سرویس رهگیری موقتاً پاسخ ندهد چه؟
- اگر چند روز هیچ وضعیت جدیدی ثبت نشود چه؟
- اگر تحویل ناموفق باشد چه؟
- اگر بسته برگشت بخورد چه؟
- اگر چتبات جواب سؤال مشتری را نداند چه؟
یک فرایند خوب برای این اتفاقها هم مسیر دارد.
گاهی باید کمی بعد دوباره بررسی شود.
گاهی مسئول فروشگاه باید هشدار بگیرد.
گاهی مشتری باید یک پیام روشن دریافت کند.
و گاهی پرونده باید از مسیر خودکار خارج شود و به یک انسان برسد.
اتوماسیون قابلاعتماد فقط مسیر موفق را خودکار نمیکند؛ برای استثناها هم برنامه دارد.
قبل و بعد از اتوماسیون چه تفاوتی ایجاد میشود؟
قبل
مشتری پیام میدهد ← پشتیبانی سفارش را پیدا میکند ← کد رهگیری را پیدا میکند ← وضعیت مرسوله را بررسی میکند ← پاسخ میدهد ← همین مسیر برای مشتری بعدی تکرار میشود
بعد
کد رهگیری ثبت میشود ← مشتری خودکار مطلع میشود ← وضعیت بسته در صورت امکان دنبال میشود ← مشتری خودش اطلاعات را میبیند یا سؤالش را میپرسد ← فقط موارد خاص به پشتیبانی میرسند

تفاوت اصلی فقط در سرعت پاسخ نیست؛ در تعداد کارهایی است که دیگر لازم نیست یک انسان انجام دهد.
برای فروشگاه شما کدام راهحل مناسبتر است؟
همه فروشگاهها به یک سطح از اتوماسیون نیاز ندارند.
| مشکل | نقطه شروع احتمالی |
|---|---|
| مشتری زمان ارسال را نمیداند | اطلاعرسانی بهتر |
| اطلاعات در سایت هست ولی مشتری پیدایش نمیکند | مسیر پیگیری سادهتر |
| مشتری نمیخواهد وارد حساب کاربری شود | پیگیری سریع با تأیید اطلاعات |
| کد رهگیری به مشتری نمیرسد | اصلاح فرایند ثبت و ارسال کد |
| مشتری میخواهد خودش وضعیت را ببیند | صفحه پیگیری |
| مشتری میخواهد بداند بسته در چه مرحلهای است | اتصال به سرویس رهگیری |
| تعداد زیادی مرسوله باید بررسی شوند | پایش خودکار |
| سؤالهای تکراری زیاد است | چتبات یا پاسخگویی خودکار |
| چند سیستم باید با هم کار کنند | اتوماسیون یکپارچه |
| مشکلات ارسال دیر شناسایی میشوند | هشدار و مدیریت استثناها |
نکته مهم این جدول ستون دوم است:
نقطه شروع احتمالی؛ نه نسخه قطعی.
ممکن است یک افزونه مناسب دقیقاً همان چیزی باشد که فروشگاه شما نیاز دارد.
ممکن است مشکل با سادهتر کردن مسیر پیگیری حل شود.
ممکن است چتبات بیشترین اثر را داشته باشد.
و ممکن است اطلاعات بین چند سیستم جدا افتاده باشند و لازم باشد یک فرایند یکپارچه ساخته شود.
راهحل باید بعد از شناخت مسئله انتخاب شود.
چطور بفهمیم اتوماسیون واقعاً ارزش ایجاد کرده؟
اگر چیزی را خودکار کنیم ولی نتوانیم بفهمیم چه تغییری ایجاد کرده، ارزیابی نتیجه سخت میشود.
قبل از اجرا کافی است چند عدد ساده ثبت کنیم:
- روزانه چند سؤال درباره وضعیت سفارش دریافت میشود؟
- چند مورد درباره کد رهگیری است؟
- پاسخ به هر درخواست تقریباً چقدر زمان میگیرد؟
- چند مشتری برای یک سفارش بیشتر از یک بار تماس میگیرد؟
- چند درخواست فقط با پیدا کردن اطلاعاتی حل میشوند که از قبل در سیستم وجود دارد؟
- چند مشکل ارسال دیر شناسایی میشوند؟
بعد از اجرای راهحل همین موارد دوباره بررسی میشوند.
هدف لزوماً این نیست که تماس مشتری به صفر برسد.
بعضی مسائل واقعاً نیاز به گفتوگوی انسانی دارند.
هدف این است که تیم بهجای پاسخ دادن مداوم به سؤالهای تکراری، زمانش را برای مواردی بگذارد که واقعاً به تصمیم، بررسی یا ارتباط انسانی نیاز دارند.
سؤالهای متداول درباره خودکارسازی پیگیری سفارش
آیا این نوع اتوماسیون فقط برای فروشگاههایی با سیستم خاص قابل اجراست؟
نه. چیزی که اهمیت دارد این است که اطلاعات سفارش کجا نگهداری میشود و چه میزان دسترسی برای خواندن یا بهروزرسانی آن وجود دارد.
در فروشگاههای ووکامرسی امکانات و اتصالهای زیادی برای این کار وجود دارد، اما همین منطق میتواند برای سیستمهای فروشگاهی دیگر هم اجرا شود. روش پیادهسازی بسته به زیرساخت هر فروشگاه متفاوت است.
آیا مشتری بدون ورود به حساب کاربری هم میتواند سفارش خودش را پیگیری کند؟
بله. میتوان مسیری طراحی کرد که مشتری با اطلاعاتی مثل شماره سفارش و تأیید شماره موبایل، کد یکبارمصرف یا لینک امن به وضعیت سفارش خودش دسترسی پیدا کند.
نکته مهم این است که این مسیر هم ساده باشد و هم اطلاعات سفارش را در اختیار فرد اشتباه قرار ندهد.
آیا میتوان وضعیت بسته را مستقیماً داخل سایت نمایش داد؟
اگر سرویس حملونقل امکان دریافت اطلاعات رهگیری را در اختیار سیستم قرار دهد، بله.
در این شرایط میتوان آخرین وضعیت معتبر ثبتشده مرسوله را داخل سایت یا از طریق یک دستیار پاسخگو نمایش داد. نوع اطلاعات قابل نمایش به امکانات سرویس ارسال بستگی دارد.
اگر کد رهگیری برای مشتری ارسال نشود، میتوان این مشکل را خودکار مدیریت کرد؟
در بسیاری از سناریوها بله.
مثلاً سیستم میتواند نبودن کد یا شکست بخشی از فرایند اطلاعرسانی را شناسایی کند و بسته به طراحی، دوباره بررسی کند یا مسئول مربوط را مطلع کند.
هدف این است که فروشگاه قبل از تماس مشتری متوجه مشکل شود.
آیا برای خودکار کردن پیگیری سفارش حتماً به چتبات یا هوش مصنوعی نیاز داریم؟
نه.
گاهی یک افزونه، صفحه پیگیری سادهتر یا اصلاح فرایند اطلاعرسانی تمام چیزی است که نیاز دارید.
چتبات زمانی ارزش بیشتری پیدا میکند که مشتریها ترجیح میدهند سؤالشان را مستقیم بپرسند و سیستم بتواند جواب را از اطلاعات واقعی سفارش دریافت کند.
چتبات از کجا میفهمد سفارش مشتری در چه مرحلهای است؟
نباید از روی حدس جواب بدهد.
بعد از اینکه سیستم مطمئن شد سفارش مربوط به همان مشتری است، اطلاعات واقعی سفارش و در صورت امکان وضعیت مرسوله بررسی میشود و پاسخ بر اساس همان دادهها ارائه میشود.
اگر اطلاعات کافی در دسترس نباشد، بهتر است درخواست به پشتیبانی منتقل شود.
اگر فروشگاه از چند روش ارسال مختلف استفاده کند، باز هم امکان خودکارسازی وجود دارد؟
بله، اما ممکن است یک راهحل واحد برای همه روشهای ارسال وجود نداشته باشد.
باید بررسی شود هر سرویس چه اطلاعاتی در اختیار فروشگاه میگذارد و کدام قسمت از فرایند آن قابلیت خودکار شدن دارد.
آیا دانیرا برای همه این مشکلات یک سیستم پیچیده میسازد؟
نه.
اول فرایند بررسی میشود و بعد راهحل انتخاب میشود.
ممکن است راهحل یک افزونه مناسب باشد، یک تغییر در سایت، صفحه پیگیری، چتبات، اتصال چند سیستم یا یک اتوماسیون چندمرحلهای.
هدف استفاده از پیچیدهترین ابزار نیست؛ هدف حل مسئله با یک راهحل قابلاعتماد و متناسب با نیاز کسبوکار است.
آیا میتوان این سیستم را مرحلهبهمرحله اجرا کرد؟
بله، و در خیلی از موارد همین روش منطقیتر است.
مثلاً ابتدا مشکل ثبت و ارسال کد رهگیری حل شود، بعد پیگیری ساده سفارش اضافه شود و در مراحل بعد، وضعیت مرسوله، هشدارها، چتبات یا اتصال سیستمهای دیگر توسعه پیدا کنند.
از کجا بفهمیم فروشگاه ما اصلاً به این اتوماسیون نیاز دارد؟
اگر تیم شما هر روز زمان قابلتوجهی برای پیدا کردن سفارش، ارسال مجدد کد رهگیری، بررسی وضعیت بسته یا جواب دادن به سؤالهای مشابه صرف میکند، ارزش بررسی دارد.
اما اینکه دقیقاً کدام بخش باید خودکار شود فقط بعد از دیدن فرایند فعلی مشخص میشود.
دانیرا قبل از پیشنهاد راهحل چه چیزی را بررسی میکند؟
مسیر سفارش از ثبت تا تحویل، روشهای ارسال، نحوه تولید و ثبت کد رهگیری، کانالهای ارتباط با مشتری، کارهای دستی تیم و سیستمهایی که اطلاعات بین آنها جابهجا میشود.
بعد مشخص میشود مشکل اصلی کجاست و کدام بخشها واقعاً ارزش خودکارسازی دارند.
رشد سفارش نباید الزاماً به معنی رشد کار دستی باشد
وقتی فروشگاه کوچک است، خیلی از این کارها قابل تحمل به نظر میرسند.
یک نفر کد رهگیری میخواهد؛ دستی میفرستیم.
مشتری وضعیت بسته را میپرسد؛ بررسی میکنیم.
یک پیام ارسال نشده؛ دوباره میفرستیم.
اما وقتی تعداد سفارشها بالا میرود، همین کارهای کوچک تبدیل به دهها وقفه روزانه میشوند.
و راهحل الزاماً استخدام یک نفر دیگر برای انجام همان کارها نیست.
گاهی باید سؤال را قبل از شکل گرفتن پاسخ داد.
گاهی باید مسیر رسیدن مشتری به اطلاعات را کوتاه کرد.
گاهی یک افزونه مناسب کافی است.
گاهی مشتری باید بتواند بدون درگیر شدن با حساب کاربری سفارش خودش را پیگیری کند.
گاهی یک دستیار میتواند سؤال را مستقیم از اطلاعات واقعی جواب دهد.
و گاهی سیستم باید خودش بستهها را دنبال کند و فقط موارد غیرعادی را به تیم نشان دهد.
اتوماسیون پشتیبانی فقط به معنی «جواب دادن خودکار» نیست؛ هدف این است که کارهای تکراری تا جایی که منطقی است از دوش انسان برداشته شوند و مشتری هم سریعتر به اطلاعاتی که نیاز دارد برسد.
و برای رسیدن به این نقطه، لازم نیست از قبل تصمیم بگیریم راهحل افزونه است، چتبات است یا یک اتوماسیون بزرگتر.
اول باید خود فرایند را ببینیم.