فرض کنید مشتری در دایرکت می‌پرسد «این کیف چند است؟» و دستیار هوشمند فوری جواب می‌دهد: «۱٬۸۵۰٬۰۰۰ تومان». مشکل این‌جاست که این عدد در هیچ فهرست قیمتی وجود ندارد. به این اتفاق قیمت‌سازی می‌گوییم: دستیار برای پر کردن جای خالی، عددی می‌نویسد که شبیه واقعیت است ولی منبع ندارد.
نوشتن جملهٔ «حدس نزن» در دستورالعمل لازم است، اما کافی نیست. اگر داده ناقص باشد و آزمون جدی انجام نشود، مدل در اولین موقعیت مبهم دوباره به حدس‌زدن برمی‌گردد.
قیمت‌سازی معمولاً از کجا شروع می‌شود؟
بیشتر وقت‌ها مشکل از خود مدل نیست، از داده‌ای است که به آن داده‌ایم. فهرست قیمتی که دو ماه پیش به‌روز شده، محصولی که چند سایز و رنگ دارد ولی فقط یک قیمت برایش ثبت شده، یا تخفیفی که تمام شده اما هنوز در متن تنظیمات مانده است. دستیار در این شرایط چیزی را از خودش نمی‌سازد، فقط به همان داده‌های کهنه یا مبهم اعتماد می‌کند. پس پیش از اصلاح لحن و دستور، باید داده را درست کرد.
کنترل‌هایی که واقعاً جواب می‌دهند
- شناسهٔ دقیق برای هر گزینه: هر محصول را با کد، سایز، رنگ یا مشخصات مشخص ثبت کنید تا دستیار قیمت «کیف» را با قیمت «کیف مشکی بزرگ» اشتباه نگیرد.
- منبع و زمان بررسی: کنار هر قیمت معلوم باشد از کجا آمده و آخرین بار کِی تأیید شده است. قیمتی که تاریخ ندارد، قابل اتکا نیست.
- سؤال تکمیلی: اگر مشتری فقط نوشته «قیمت این چنده؟» و محصول مشخص نیست، دستیار باید اول بپرسد کدام مدل یا کدام سایز.
- توقف پاسخ عددی: وقتی قیمت معتبر پیدا نشد، دستیار نباید عددی بدهد و باید درخواست را برای بررسی انسانی بفرستد.
وقتی جواب را نمی‌داند، چه بگوید؟
پاسخ جایگزین باید صادقانه و کوتاه باشد، مثلاً: «برای این گزینه قیمت تأییدشده در دسترس ندارم. کد و مشخصات را برای همکار فروش می‌فرستم تا مبلغ صحیح اعلام شود.» مشتری از این جمله ناراحت نمی‌شود. ناراحتی وقتی پیش می‌آید که عددی بشنود و بعد در پرداخت چیز دیگری ببیند.
مثالی از یک فروشگاه لوازم ورزشی
فروشگاه فرضی «ورزش‌بان» کفش رانینگ را در سایزهای ۳۹ تا ۴۵ می‌فروشد و قیمت سایزهای بزرگ‌تر کمی بالاتر است. در فهرست داخلی فقط یک قیمت برای کل مدل ثبت شده بود. مشتری پرسید «سایز ۴۵ چند است؟» و دستیار همان قیمت عمومی را داد، که ۲۰۰ هزار تومان کمتر از قیمت واقعی بود. مشتری عکس گفتگو را فرستاد و تیم فروش مجبور شد یا ضرر کند یا مشتری را ناراضی کند.
راه‌حل سه کار ساده بود: ثبت قیمت جدا برای هر سایز، اضافه‌کردن تاریخ بررسی کنار هر ردیف، و قاعده‌ای که می‌گفت اگر سایز ذکر نشده، اول سایز را بپرس. بعد از این تغییر، همان سؤال یا با قیمت درست پاسخ گرفت یا به کارشناس ارجاع شد.
آزمون و ثبت خطا
پیش از راه‌اندازی، سناریوهای دردسرساز را عمداً امتحان کنید: تخفیف منقضی‌شده، کالایی که اصلاً وجود ندارد، قیمت گزینهٔ دیگر، و مشتری‌ای که اصرار می‌کند «همین‌جوری یه عدد بگو». پاسخ درست در همهٔ این موارد خودداری از ساختن عدد است.
اگر بعداً قیمت نادرستی ثبت شد، سؤال مشتری، منبع داده و نسخهٔ تنظیمات را یادداشت کنید. تا وقتی علت برطرف نشده، می‌توانید پاسخ خودکار همان بخش را محدود کنید. مبلغ نهایی سفارش هم همیشه باید از مسیر معتبر خود فروشگاه تأیید شود، نه از متن گفتگو.
سوال‌های رایج
آیا یک دستور قاطع در پرامپت برای جلوگیری از حدس کافی است؟
نه. دستور لازم است، ولی وقتی داده مبهم باشد مدل باز هم راهی برای جواب‌دادن پیدا می‌کند. ترکیب داده دقیق، قاعدهٔ توقف و آزمون منظم نتیجهٔ پایدارتری می‌دهد.
اگر قیمت‌ها زیاد تغییر می‌کنند چه کنیم؟
برای قیمت‌های پرنوسان، یک تاریخ اعتبار تعیین کنید. اگر آخرین بررسی از آن مدت قدیمی‌تر بود، دستیار باید عدد ندهد و پرسش را به همکار فروش بسپارد.
آیا ارجاع به انسان مشتری را فراری نمی‌دهد؟
معمولاً برعکس. پاسخ شفاف و سریع که می‌گوید چه کسی و چه زمانی جواب می‌دهد، اعتماد بیشتری می‌سازد تا عددی که بعداً اصلاح شود.
جمع‌بندی
جلوی قیمت‌سازی را داده تمیز، قاعدهٔ توقف روشن و آزمون واقعی می‌گیرد، نه فقط یک جمله در تنظیمات. همین سناریو را با اطلاعات واقعی کسب‌وکارتان بررسی کنید و نتیجه را پیش از انتخاب پلن بسنجید.
دموی ایجنت فروش را بررسی کنید | مشاهدهٔ دمو
