فروشنده یک پخشکننده لوازم کافه سفارش ۱۲ کارتن شربت را نهایی میکند. هر کارتن شش بطری دارد. در پیام فروش، تعداد «۱۲» نوشته شده، اما واحد آن مشخص نیست. حسابدار سفارش را ۱۲ بطری میخواند و فاکتوری صادر میکند که یکششم مقدار توافقشده است. مشتری هم انتظار دارد کالا همان روز از انبار خارج شود.
اتصال CRM به حسابداری قرار است چنین خطایی را کم کند، اما سیمکشی دو نرم افزار به تنهایی کافی نیست. تیم باید بداند هر عدد چه واحدی دارد، کدام سیستم مرجع نهایی آن است، چه رویدادی اجازه انتقال میدهد و اگر انتقال شکست خورد چه کسی آن را میبیند. CRM، یعنی نرم افزار مدیریت ارتباط با مشتری، برای سابقه مشتری و مسیر فروش است؛ حسابداری مرجع سند مالی، دریافت و مانده حساب میماند.
پیش از اتصال، مرجع هر داده را تعیین کنید
نام مشتری ممکن است در CRM «کافه بهار شعبه ولیعصر» و در حسابداری «شرکت بهار نوش» باشد. تطبیق فقط با نام، دیر یا زود دو پرونده را اشتباه میگیرد. یک کد ثابت برای مشتری تعیین کنید که در هر دو سیستم یک معنی داشته باشد. شعبه یا محل تحویل را نیز جدا از شخصیت اصلی مشتری نگه دارید.
برای کالا هم همین کار لازم است. شربت وانیل یک نام بازاری دارد، یک کد داخلی و یک واحد فروش. حسابداری شاید موجودی را با بطری نگه دارد، اما فروش با کارتن قیمت بدهد. در نگاشت داده بنویسید کد کالا چیست، واحد اصلی کدام است و تبدیل کارتن به بطری با چه عددی انجام میشود.
سپس مشخص کنید چه کسی مسئول درست نگه داشتن هر داده است. تلفن و مکالمه مشتری در پرونده فروش بهروز میشود. قیمت مصوب، کد حساب، فاکتور، دریافت و مانده در سیستم مالی تایید میشوند. موجودی و واحد انبار هم مرجع خود را دارند. اگر دو سیستم اجازه ویرایش یک داده را داشته باشند، باید روشن باشد هنگام اختلاف کدام مقدار برنده است.
چارچوب کیفیت داده دولت بریتانیا دقت، کامل بودن، یکتا بودن، سازگاری و بهروز بودن را از هم جدا میکند. یک پرونده ممکن است همه فیلدها را داشته باشد، اما هنوز کد مشتری یا واحد کالا در آن غلط باشد. اتصال، داده غلط را درست نمیکند؛ فقط آن را سریعتر جابهجا میکند.
فرصت فروش، فاکتور و دریافت سه چیز جدا هستند
فرصت فروش میگوید تیم در حال پیگیری چه معاملهای است. مبلغ آن برآورد یا پیشنهاد تجاری است و ممکن است در مذاکره تغییر کند. فاکتور سندی است که مالی بر پایه اطلاعات تاییدشده صادر میکند. دریافت نیز پولی است که حسابدار ورود آن را تایید کرده است. یکی دانستن این سه، گزارش فروش و گفتوگو با مشتری را خراب میکند.
وقتی مشتری تلفنی میگوید «سفارش را میخواهم»، هنوز معلوم نیست اطلاعات لازم برای صدور سند کامل است. نشانی صورتحساب، نام طرف قرارداد، اقلام، واحد، تخفیف، روش پرداخت و محل تحویل باید با توافق نهایی هماهنگ باشند. رویداد انتقال را دقیق تعریف کنید؛ مثلا «سفارش توسط مشتری تایید شد و مسئول فروش اطلاعات لازم را کامل کرد».
اگر مشتری بعدا مقدار را از ۱۲ به ۱۵ کارتن تغییر داد، سفارش قبلی را بیردپا ویرایش نکنید. نسخه تازه یا تغییر مشخصی ثبت کنید و حسابداری را از همان تغییر باخبر کنید. مالی باید بداند سند قبلی هنوز پیشنویس است، باطل شده یا باید اصلاح شود. این واژهها را خود تیم با روش مالی شرکت هماهنگ میکند.
فروشنده نیز نباید بر اساس پیام «واریز کردم» وضعیت را پرداختشده بداند. مشتری میتواند تصویر رسید بفرستد، اما تایید دریافت با مالی است. پاسخ حرفهای روشن است: «رسید را برای مالی فرستادم و پس از تایید، وضعیت سفارش را خبر میدهم.»
واحد و پول باید کنار هر عدد باشند
محاسبه زیر فقط بهای کالا و تخفیف آن را در نظر میگیرد. مالیات، عوارض و هزینههای جداگانه باید با تایید مالی به سند نهایی اضافه شوند. در سفارش شربت، عدد ۱۲ بدون «کارتن» خطرناک است. اگر هر کارتن شش بطری دارد، مقدار انبار میشود:
۱۲ کارتن × ۶ بطری در هر کارتن = ۷۲ بطری
قیمت هم باید واحد داشته باشد. مثلا قیمت هر کارتن ۱٬۸۰۰٬۰۰۰ تومان است. مبلغ پیش از تخفیف برابر است با:
۱۲ × ۱٬۸۰۰٬۰۰۰ = ۲۱٬۶۰۰٬۰۰۰ تومان
اگر فروشنده پنج درصد تخفیف تاییدشده داده باشد، مبلغ تخفیف ۱٬۰۸۰٬۰۰۰ تومان و مبلغ پس از تخفیف ۲۰٬۵۲۰٬۰۰۰ تومان میشود. مشتری ۸٬۰۰۰٬۰۰۰ تومان پیشپرداخت میکند، پس مانده این بخش از سفارش، پیش از مالیات و هزینههای جداگانه، برابر است با:
۲۰٬۵۲۰٬۰۰۰ − ۸٬۰۰۰٬۰۰۰ = ۱۲٬۵۲۰٬۰۰۰ تومان
ممکن است نرم افزار مالی مبلغ را به ریال نگه دارد. در این صورت واحد پول باید پیش از انتقال روشن باشد:
۲۰٬۵۲۰٬۰۰۰ تومان × ۱۰ = ۲۰۵٬۲۰۰٬۰۰۰ ریال
هیچکدام از این تبدیلها نباید از ظاهر عدد حدس زده شوند. نام فیلد، واحد و قاعده تبدیل را کنار هم بنویسید و با چند سفارش آزمایشی بررسی کنید. برای معامله ارزی نیز مبلغ پیشنهادی، نرخ برآورد و دریافت واقعی را جدا نگه دارید؛ راهنمای فروش چند ارزی این مسیر را با مثال کامل توضیح میدهد.
هر انتقال باید یک شماره قابل پیگیری داشته باشد
برای سفارش تاییدشده یک شماره یکتا بسازید؛ مثلا ۱۴۰۵-۰۱۷۸. همین شماره باید در پیام تحویل به مالی، سند حسابداری مرتبط و گزارش خطا دیده شود. اگر یک سفارش به دو فاکتور یا دو ارسال تقسیم شد، رابطه آنها با شماره اصلی باقی بماند.
شماره سفارش برای تطبیق تجاری است. هر عملیات انتقال هم باید شناسه جداگانه داشته باشد؛ مثلا ایجاد فاکتور اول و ایجاد فاکتور دومِ همان سفارش دو عملیاتاند. اصلاح محتوای یک سند نیز با تلاش دوباره برای ارسال همان محتوای قبلی فرق دارد.
برای درخواستهای تکراری قاعده روشن بگذارید: تلاش دوباره با همان شناسه عملیات و همان محتوا انجام شود. مقصد باید آن را تشخیص دهد، سند دوم نسازد و نتیجه یا شناسه سند قبلی را برگرداند. صرف فرستادن یک شماره این رفتار را ایجاد نمیکند؛ باید در اتصال و مقصد پشتیبانی شود و در محیط آزمایشی با دو ارسال همزمان بررسی شود. محتوای متفاوت، عملیات تازه میخواهد.
وضعیت انتقال را ساده نگه دارید: آماده ارسال، در حال بررسی مالی، ثبتشده، خطا یا نتیجه نامعلوم. کنار هر انتقال، شماره سفارش، شناسه عملیات، نسخه داده، زمان و نتیجه ثبت شود. پس از موفقیت، شناسه سند مقصد را هم نگه دارید. اطلاعات حساس مالی لازم نیست در متن خطا تکرار شوند. یک نفر نیز باید مسئول دیدن خطاها و تصمیم درباره تلاش دوباره یا ثبت دستی باشد.
تیم و توسعهدهنده باید پیش از ساخت اتصال این روش را نهایی کنند: نرم افزار فروش و نرم افزار مالی چه شناسهای میپذیرند، چگونه نتیجه موفق را برمیگردانند و چه چیزی را خطا حساب میکنند.
تطبیق روزانه فقط شمردن فاکتورها نیست
فرض کنید فروش در یک روز هشت سفارش تاییدشده به مالی تحویل داده است. حسابداری ممکن است برای یکی از سفارشها دو فاکتور صادر کند و یک سفارش را به دلیل اطلاعات ناقص نگه دارد. مقایسه «هشت سفارش با هشت فاکتور» میتواند ظاهرا درست و در عمل غلط باشد.
هر سفارش را با شماره خودش تطبیق دهید. نتیجه میتواند یک سند، چند سند، در انتظار تکمیل یا لغوشده باشد. مبلغها را فقط پس از یکسان کردن واحد پول و کنار گذاشتن اسناد باطلشده جمع کنید. مرجوعی هم باید به سفارش و سند اصلی وصل شود، نه اینکه مانند فروش تازه در جمع ظاهر شود.
برای سفارش نمونه، مالی باید بتواند این زنجیره را ببیند: ۱۲ کارتن، ۷۲ بطری، مبلغ ۲۰٬۵۲۰٬۰۰۰ تومان، پیشپرداخت ۸٬۰۰۰٬۰۰۰ تومان و مانده ۱۲٬۵۲۰٬۰۰۰ تومان. اگر یکی از این عددها فرق دارد، ابتدا منبع اختلاف را پیدا کنید؛ تغییر سفارش، تبدیل واحد، تخفیف یا ثبت دریافت.
پایان روز، سه فهرست کوتاه کافی است: سفارشهای رسیده و ثبتشده، موارد منتظر اطلاعات و خطاهای نیازمند رسیدگی. این کار باید پیش از آن انجام شود که مشتری برای وضعیت سفارش تماس بگیرد. تطبیق منظم، اعتماد فروش و مالی را بسیار سریعتر از یک داشبورد پرزرقوبرق میسازد.
تغییر سفارش بعد از انتقال مسیر جدا میخواهد
گاهی مشتری پس از صدور سند، مقدار را کم میکند یا نشانی تحویل را عوض میکند. فروشنده نباید ردیف قبلی را پاک کند و سفارش تازهای بیارتباط بسازد. درخواست تغییر باید همان شماره سفارش، نسخه تازه، دلیل و زمان تغییر را داشته باشد. حسابدار بر اساس روش مالی شرکت تصمیم میگیرد سند قبلی چگونه اصلاح شود.
اگر سفارش ۱۲ کارتن به ۱۰ کارتن کاهش یافت، فروش نسخه دوم را با مقدار تازه میفرستد و انبار تا روشن شدن سند درست، نسخه قبلی را مبنای خروج نمیگذارد. مالی نیز به جای تغییر خاموش عدد، رابطه اصلاح با سند اول را نگه میدارد. لغو، مرجوعی و کاهش مقدار سه وضعیت متفاوتاند و گزارش باید تفاوت آنها را حفظ کند.
پس از اصلاح، خلاصهای که فروش لازم دارد به پرونده مشتری برمیگردد: کدام نسخه تایید شده، مبلغ مورد تایید مالی چیست و اقدام بعدی چه زمانی است. جزئیات دفتر مالی در همان سیستم مالی میماند. این رفتوبرگشت کنترلشده اجازه میدهد فروش پاسخ درست بدهد، بدون اینکه CRM به دفتر حسابداری دوم تبدیل شود.
شکست انتقال باید راه برگشت داشته باشد
اتصال ممکن است به دلیل قطع اینترنت، تغییر کد کالا، نامعتبر بودن مشتری یا پاسخ ندادن سیستم مقصد متوقف شود. سفارش نباید بیصدا ناپدید شود. نسخه اصلی اطلاعات در منبع تعیینشده باقی بماند و تلاش انتقال در فهرست خطا ثبت شود.
قطع ارتباط لزوما به معنی ساخته نشدن سند نیست. ابتدا با شناسه عملیات یا سند مقصد، نتیجه را بررسی کنید. اگر نتیجه هنوز نامعلوم است، نه تلاش خودکار تازه انجام دهید و نه همان سند را دستی بسازید. برای تکرار همان عملیات، شناسه و محتوا ثابت میمانند. اگر مقدار سفارش تغییر کرده، نسخه و عملیات تازه لازم است. اتصال باید نسخه جاری را بررسی کند تا درخواست قدیمی پس از نسخه تازه، بدون تصمیم مالی دوباره اجرا نشود.
اگر بررسی نشان داد سندی ساخته نشده و مسیر دستی انتخاب شد، کارشناس مالی اطلاعات را با فرم ثابت وارد میکند. شماره سفارش، شناسه عملیات و شناسه سند ساختهشده در ثبت دستی به هم وصل میشوند و همان عملیات انجامشده علامت میخورد. پس از برگشت ارتباط، صف انتقال باید این نتیجه را بشناسد و دوباره همان سند را نسازد.
پاسخ مشتری باید از منبع درست بیاید
مشتری میپرسد: «واریز من ثبت شد؛ سفارش چه زمانی ارسال میشود؟» فروشنده میتواند مکالمه و تعهد تحویل را ببیند، اما تایید پرداخت را از مالی میگیرد. انبار نیز زمان ارسال را بر پایه موجودی و برنامه خودش تایید میکند. یک پاسخ خوب این سه موضوع را قاطی نمیکند.
در نرم افزار CRM کلید، منبع، مسئول، وضعیت، مکالمات و اقدام بعدی مشتری در یک پرونده قرار میگیرند. فرصت فروش نیز مرحله معامله، مبلغ، احتمال موفقیت و اقدام بعدی دارد. فروشنده میتواند نتیجه تایید مالی را در مکالمه ثبت و تماس بعدی را برای خبر دادن به مشتری مشخص کند.
خدمات کلید اطلاعات فروش، بازاریابی و پشتیبانی را در داشبورد کنار هم میآورد و مدیر میتواند گزارش بگیرد و سطح دسترسی تعیین کند. اطلاعات مالی لازم برای فروش را محدود و روشن تعریف کنید؛ دسترسی به یک وضعیت تاییدشده با دسترسی به دفترهای مالی شرکت یکسان نیست.
اتصال حسابداری را در دمو قطعی ندانید
نیاز اتصال در گفتوگوی اولیه کلید بررسی میشود تا مسیر مناسب پیشنهاد شود. اتصال آماده به نرم افزار حسابداری، صدور خودکار فاکتور، همگامسازی پرداخت، مالیات، موجودی یا سقف اعتبار را از قبل جزو محصول ندانید. نام نرم افزار مالی، نسخه آن، دادههای مورد نیاز، جهت انتقال، زمان اجرا، هزینه، مسئول نگهداری و راه برگشت هنگام خطا را در دمو و توافق راهاندازی روشن کنید.
دمو را با یک مشتری، دو کالا، یک تخفیف، پیشپرداخت و مرجوعی اجرا کنید. فقط مسیر موفق را نبینید؛ کد کالای اشتباه و قطع موقت را هم امتحان کنید. فروش، مالی و انبار باید نتیجه را کنار هم ببینند و درباره مرجع هر عدد توافق داشته باشند.
پس از شروع کار، ابتدا حجم کوچکی از سفارشها را عبور دهید. هر مورد را با شماره سفارش، شناسه عملیات، سند مقصد و مبلغ همواحد تطبیق دهید. وقتی خطا، تلاش دوباره و ثبت دستی بدون سند تکراری مدیریت شد، دامنه را افزایش دهید. سرعت بالا روی داده مبهم فقط اختلاف را سریعتر میکند.
صبح روز بعد، حسابدار شماره ۱۴۰۵-۰۱۷۸ را باز میکند. ۱۲ کارتن به ۷۲ بطری تبدیل شده، مبلغ خالص ۲۰٬۵۲۰٬۰۰۰ تومان است و پیشپرداخت ۸٬۰۰۰٬۰۰۰ تومان تایید شده. فروشنده نیز میداند مانده را از روی پیام مشتری اعلام نکند و برای زمان ارسال از انبار پاسخ بگیرد. حالا سه تیم درباره یک سفارش حرف میزنند، نه سه نسخه متفاوت از آن.
