فروش حضوری، یک پرونده‌ی مشتری و گزارش پورسانت

مسئله تجاری

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

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

آنچه تحویل دادم

• موتور ورود برای خروجی اکسل سیستم حسابداری: ستون شرح را موقعیتی به کانال، درگاه و برند تجزیه می‌کند، کد کالا را به ویژگی رفرنس کاتالوگ وصل می‌کند، چهار انبار و فروش-در-برابر-تعویض را ثبت می‌کند، و سطرهای بایت‌به‌بایت یکسانی را که خروجی تکرار می‌کند جمع می‌کند — تعداد واقعی را از ستون خودش می‌خواند.
• پول خطوط، درست: هر خط حالا ناخالص، تخفیف و خالص دارد تا فاکتور با خطوطش بخواند؛ حالت مبهم — یک کد کالا روی دو خط غیریکسان از یک فاکتور — هیچ‌وقت حدس زده نمی‌شود بلکه شمرده، ارزش‌گذاری و با شماره‌ی فاکتور در گزارش بارگذاری فهرست می‌شود تا یک نفر با کاغذ مقایسه کند.
• پرونده‌ی مشتری‌ای که از ورود جان سالم به در می‌برد: پروفایل‌ها با شماره تلفن از همان مسیر ساخت مشتری فروشگاه ساخته یا وصل می‌شوند با قلاب‌های ثبت‌نام خاموش، پس صدها حساب بدون حتی یک پیامک باز شد؛ خانه‌ی مشتری در خروجی به‌جای نام یک کد حسابداری دارد، پس تجزیه‌گر کد را به متادیتا می‌برد و هیچ‌وقت رقم را به‌عنوان نام برنمی‌گرداند؛ و upsert مخاطب ادغام می‌کند نه جایگزینی، بعد از آنکه یک ورود مجموعه‌ای از نام‌های واقعی را عدد کرده بود.
• پنل بارگذاری به تفکیک شعبه، جاسازی‌شده داخل صفحه‌ی فروش حضوری CRM — بدون منوی جدا — با ورودی که سرنخ‌های باز را با یادداشت شعبه به «خرید حضوری» می‌بندد، و بررسی فاکتوری که هر شماره‌ای را که اپراتور تایپ کرده و ظرف یک هفته در هیچ ورودی نیامده علامت می‌زند.
• یک قاعده برای فروشی که دو طرف ثبت شده: همان شماره، مبلغ در محدوده‌ی کوچک و تاریخ در سه روز یعنی یک فروش، و اینکه کدام طرف نگهش می‌دارد به تاریخی بستگی دارد که مالک تعیین کرده؛ داشبورد مدیر، کارت پول-به-مقصد و نمودار ماهانه‌ی تعداد همه از یک فهرست جفت‌ها استفاده می‌کنند.
• گزارش پورسانتی که حقوق، واریزی، هزینه و مانده‌ی قبل از بازه‌ی انتخابی محاسبه و فقط‌خواندنی نشان داده می‌شوند؛ مانده همان فرمول است که از اول سال جلالی تا یک ثانیه قبل از بازه اجرا می‌شود، شش ساعت کش می‌شود و با مُهری که هر تغییر دریافتی یا هزینه می‌زند باطل می‌شود؛ دریافتی دستی می‌تواند اعلام کند که سطرهای خودکار درگاهی ماهش را پوشش می‌دهد تا هیچ‌چیز دوبار کم نشود.

رویکرد فنی

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

نتیجه و شواهد

ورود تاریخی، پیشخوان را با آگاهی از شعبه به CRM آورد، با پنل بارگذاری‌ای که مالک خودش استفاده می‌کند. آنچه تأیید کردم نه تخمین: صفحه‌ی ادمین، تب داشبورد مالک و کارت مالی تلگرام حالا پورسانت را از یک تابع حساب می‌کنند و تا تومان توافق دارند؛ گزارش ترکیب‌پذیر است — بازه‌ی دوماهه برابر ماه دوم به‌تنهایی است با ماه اول به‌عنوان مانده‌اش؛ واریزی‌های دوبار شمرده رفته‌اند و سطرهای تجمیعی که باعثش بودند علامت خورده‌اند؛ ورود تکراری بی‌اثر است. حدود یک‌سوم خطوط کالا با رفرنس به کاتالوگ وصل شد، چون بسیاری از کالاهای پیشخوان هیچ‌وقت آنلاین منتشر نشده‌اند — این محدودیت گزارش شده، نه پنهان. یک رقم هنوز با محاسبه‌ی پایان‌ماه خود مالک نمی‌خواند و در حال بررسی است؛ ترجیح می‌دهم این را بگویم تا فرمول را برای رسیدن به آن دست‌کاری کنم.

اهمیت برای کارفرما

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