Customer 360 و دادهٔ یکپارچه

تقریباً هر سازمان مشتری‌محوری در جایی از مسیر خود «نمای ۳۶۰ درجهٔ مشتری» را هدف‌گذاری کرده است، و بسیاری از آن‌ها پس از یک یا دو سال با یک داشبورد زیبا اما ناقص روبه‌رو شده‌اند. کارشناس مرکز تماس هنوز باید سه سامانه را باز کند تا تاریخچهٔ کامل را ببیند. تیم بازاریابی هنوز به مشتری‌ای که هفتهٔ پیش شکایت کرده، پیشنهاد فروش می‌فرستد. مدیر ریسک هنوز نمی‌داند که این مشتری در واحد دیگری ضامن است. مشکل نه در داشبورد بلکه در لایه‌های زیرین آن است.

اهمیت این موضوع در سه جا آشکار می‌شود. در تجربهٔ مشتری، هر باری که مشتری مجبور می‌شود اطلاعاتی را که قبلاً داده تکرار کند، اعتماد کاهش می‌یابد. در ریسک و تطبیق، ناتوانی در دیدن تصویر کامل یک شخص، یعنی ناتوانی در سنجش تعهدات تجمیعی و شناسایی الگوهای مشکوک. و در هوش مصنوعی، هر مدلی که بر دادهٔ پراکنده آموزش ببیند، پراکندگی را یاد می‌گیرد، نه مشتری را. نمای ۳۶۰ درجه بنابراین یک پروژهٔ گزارش‌گیری نیست؛ پیش‌نیاز عملیات، ریسک و هوش است.

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

نخستین ملاحظهٔ عملی، تعریف «مشتری» است؛ پرسشی که ساده به نظر می‌رسد اما هر واحد پاسخ متفاوتی به آن می‌دهد. برای فروش، مشتری کسی است که خرید کرده؛ برای بازاریابی، هر کسی که ثبت‌نام کرده؛ برای ریسک، هر شخصی که تعهدی دارد یا ضامن است. نمای ۳۶۰ درجه باید این تعاریف را نه یکی کند، بلکه همه را در یک مدل جا دهد: شخص، نقش‌های او و روابطش. برای مثال، یک فرد می‌تواند همزمان مشتری خرد، مدیرعامل یک مشتری شرکتی و ضامن یک تسهیلات باشد و هر سه نقش باید در یک نما دیده شود.

دومین ملاحظه، تازگی داده است. نمای ۳۶۰ درجه‌ای که شبانه به‌روزرسانی می‌شود، برای گزارش مدیریتی کافی است اما برای کارشناس مرکز تماس بی‌فایده است؛ مشتری دربارهٔ تراکنشی می‌پرسد که ده دقیقه پیش انجام داده است. راه‌حل، ترکیب دو مسیر است: بارگذاری دسته‌ای برای تاریخچه و تحلیل، و جریان رویداد برای به‌روزرسانی‌های نزدیک به بلادرنگ. با این ترکیب، نمای مشتری هم عمق تاریخی دارد و هم آخرین تعاملات را نشان می‌دهد.

دام‌های رایج آشنا هستند. نخست، ساختن داشبورد پیش از ساختن مرجع اشخاص؛ نتیجه، نمایی است که برای هر شناسهٔ محلی یک «مشتری» جداگانه نشان می‌دهد. دوم، کپی کردن داده به یک انبار جدید بدون تعریف مالک و قواعد کیفیت، که فقط پراکندگی را به مکان جدیدی منتقل می‌کند. سوم، بی‌توجهی به حریم خصوصی و کنترل دسترسی؛ نمای ۳۶۰ درجه دقیقاً همان چیزی است که نباید برای همه در دسترس باشد و باید بر اساس نقش، فیلدها را پنهان کند. و چهارم، طراحی برای انسان و فراموش کردن سامانه‌ها؛ ارزش بزرگ‌تر زمانی است که همین نما از طریق API در اختیار کانال‌ها و ایجنت‌ها قرار بگیرد.

در نیاداد، این سه ستون به سه پلتفرم مکمل نگاشت می‌شوند. «آشنا» مرجع اشخاص است و هویت طلایی و روابط را نگه می‌دارد. «دریا» دریاچهٔ داده است که تعاملات و رویدادها را از همهٔ کانال‌ها با شناسهٔ مشترک جمع‌آوری می‌کند. و «بینش» لایهٔ هوش تجاری است که نماهای مشتری، داشبوردها و تحلیل‌ها را بر روی این داده می‌سازد. در پروژهٔ بانکی نیاداد، این سه در کنار لایهٔ رویداد قرار گرفته‌اند تا نمای مشتری هم عمق تاریخی داشته باشد و هم با آخرین تعاملات به‌روز بماند.

نمای ۳۶۰ درجهٔ مشتری مقصد نیست؛ نقطهٔ شروع است. وقتی سازمان بتواند با اطمینان بگوید این شخص کیست، چه کرده و چه روابطی دارد، تازه می‌تواند به پرسش‌های ارزشمندتر بپردازد: چه چیزی برای او مناسب است، چه ریسکی دارد و چگونه می‌توان تجربه‌اش را بهتر کرد. ارزش واقعی برای مشتری در همین پرسش‌ها ساخته می‌شود و رسیدن به آن‌ها، به کار صبورانهٔ زیربنایی در هویت، داده و حاکمیت نیاز دارد.