دیکشنری فیلد CRM توضیح می‌دهد هر ستون چه معنایی دارد، چه نوع داده‌ای می‌گیرد و چه کسی حق تغییر آن را دارد. فقط نام ستون‌ها برای اتصال کافی نیست. قبل از تبادل داده، یک نمونه مجاز و یک نمونه نامجاز برای هر فیلد بنویسید تا دو تیم از یک عنوان، دو برداشت متفاوت نداشته باشند.
تعریف را با کاربرد فرایندی شروع کنید
فیلدی به نام وضعیت می‌تواند وضعیت مشتری، سفارش یا درخواست را نشان دهد. تعریف دقیق باید بگوید این مقدار در چه تصمیمی استفاده می‌شود. در نمونه آموزشی، وضعیت درخواست شامل تازه، در بررسی و بسته است؛ همین واژه‌ها برای مرحله فروش معنی دیگری دارند. فیلد مشابه را صرف شباهت نام به مقصد وصل نکنید. اگر کاربرد مشخص نیست، اول از مالک فرایند بپرسید تا داده مبهم وارد کار خودکار نشود.
نوع و مقدار مجاز را جدا ثبت کنید
نوع متن، عدد، تاریخ یا فهرست انتخابی فقط یک بخش قرارداد است. برای فهرست، کد مجاز و عنوان نمایشی را هم بنویسید. مقدار خالی با نامعلوم و نامرتبط ممکن است تفاوت داشته باشد؛ اگر مقصد این تفاوت را پشتیبانی می‌کند، تعریف آن را روشن کنید. تبدیل همه این حالت‌ها به یک خط تیره، اطلاعات تصمیم را از بین می‌برد. محدودیت طول یا قالب را از سامانه واقعی بگیرید، نه از حدس نویسنده فرم.
مالک و مسیر تغییر را مشخص کنید
برای هر فیلد معلوم باشد چه واحدی صحت را تأیید می‌کند و کدام نقش اجازه نوشتن دارد. خواندن وضعیت توسط دستیار با تغییر آن یک اختیار نیست. مثلاً نتیجه تماس می‌تواند توسط کارشناس ثبت شود، اما تغییر مرحله سفارش نیازمند روال دیگر باشد. این مقاله اجازه دسترسی یا نوشتن به CRM نمی‌دهد؛ فقط برگه‌ای برای سؤال از مسئول سامانه فراهم می‌کند. داده محرمانه و کلید اتصال نباید داخل دیکشنری عمومی نوشته شود.
از نمونه خوب و بد برای توافق استفاده کنید
برای فیلد اقدام بعدی، «پیگیری شود» ممکن است از نظر نوع متن پذیرفته شود ولی از نظر معنا ناقص باشد. دیکشنری می‌تواند بگوید این فیلد باید فعل، مسئول و موعد مرتبط داشته باشد؛ جزئیات نگارش آن در راهنمای جداست. برای شناسه، نمونه دارای صفر آغازین بگذارید تا خطر تبدیل عددی دیده شود. نمونه نامجاز باید علت رد داشته باشد، وگرنه دو تیم فقط روی ظاهر واژه‌ها توافق کرده‌اند.
نسخه دیکشنری را کنار نگاشت نگه دارید
وقتی مقدار مجاز تازه‌ای اضافه شد یا معنی فیلد تغییر کرد، نگاشت‌ها و آزمون‌های وابسته را بررسی کنید. تغییر نام نمایشی لزوماً تغییر کد ذخیره‌شده نیست. در اجرای نمونه، یک ردیف را از مبدأ تا مقصد دنبال کنید و ببینید همان معنا حفظ شده است. موفقیت فنی ارسال داده، صحت معنایی آن را ثابت نمی‌کند. این برگه کمک می‌کند سؤال‌ها پیش از اتصال مطرح شوند و خطای ناشی از برداشت متفاوت زودتر دیده شود.
واژه‌نامه فیلد مقصد؛ نمونه آموزشی
داده‌های جدول زیر ساختگی‌اند و نتیجه اجرای واقعی هیچ محصولی نیستند. آن‌ها را برای تمرین تیم به کار ببرید و قواعد اجرایی را با مسئول همان فرایند تأیید کنید.
| فیلد آموزشی | تعریف معنایی | نوع و مقادیر مجاز نمونه | مالک تعریف | نمونه نامجاز |
|---|---|---|---|---|
| request_status | مرحله رسیدگی همان درخواست | فهرست تازه و بررسی و بسته | مالک پشتیبانی | استفاده از مرحله فروش |
| source_record_id | شناسه ردیف مبدأ | متن با حفظ شکل اولیه | مالک داده | تبدیل حدسی به عدد |
| next_owner_role | نقش مسئول اقدام بعد | نقش مصوب | سرپرست فرایند | نام مبهم همه |
دانلود واژه‌نامه فیلد مقصد با قالب CSV سازگار با اکسل. فایل از داده آموزشی تشکیل شده و اطلاعات مشتری واقعی ندارد. پیش از استفاده عملی، عنوان ستون‌ها و مقادیر مجاز را با سامانه خودتان تطبیق دهید.
منبع و ادامه مسیر
Microsoft نوع داده را در Power Query در سطح فیلد یا ستون توضیح می‌دهد. Data types in Power Query. این ارجاع، روش اختصاصی این مقاله یا قابلیت اپرا را گواهی نمی‌کند؛ روش و مثال‌های بالا پیشنهاد تحریریه برای طراحی و آزمون هستند.
برای زمینه مرتبط، اتصال ایجنت صوتی به CRM؛ چه اطلاعاتی قبل و بعد از تماس ثبت می‌شود؟ و نام و شماره مشتری در تماس اشتباه ثبت می‌شود؛ روش بازخوانی اطلاعات را بخوانید. اگر دنبال راهکار اجرایی هستید، بسته‌ها و مسیر درخواست پیشنهاد اپرا را بررسی کنید؛ امکان اجرای سناریوی خود را با تیم فروش مشخص کنید. انتخاب بسته به معنی ثبت خودکار درخواست، صدور فاکتور یا فعال‌شدن فوری خدمت نیست.
راهنماهای مرتبط با این مسئله
آماده‌سازی CSV برای ورود به CRM؛ چک‌لیست قبل از ایمپورت و ورود تاریخ شمسی به CRM؛ قرارداد تبدیل و کنترل رفت‌وبرگشت می‌توانند گام بعدی بررسی تیم شما باشند.