در کسب و کار رستوران‌داری، دنیایی از تفاوت است بین آنها که در آشپزخانه کار می‌کنند و آنها که با مشتریها در تماس‌ند. برای هر دو طرف مهم است که یکدیگر را درک کنند و یک‌دل باشند. برای همین است که مدرسه‌های آشپزی و رستوران‌ها اغلب اوقات سرآشپز به عنوان پیش‌خدمت در سالن حضور دارد تا به این ترتیب آدم‌های آشپزخانه بتوانند با مشتریها در تماس باشند و دقیقاً بدانند در خط مقدم چه می‌گذرد.
اغلب توسعه‌دهندگان نرم‌افزار هم جدایی مشابهی دارند. طراح‌ها و برنامه‌نویس‌ها در «آشپزخانه» کار می‌کنند و امور مشتریها با پشتیبانی است. یعنی متأسفانه آشپزهای نرم‌افزار هرگز آن چه مشتری می‌گوید را نمی‌شنوند. این موضوع مشکل‌ساز خواهد شد زیرا گوش دادن به مشتری بهترین راه برای آشنا شدن با نقاط ضعف و قوت برنامه است.
راه‌حل؟ بین مشتریها و تیم طراحی و توسعه دیوار نکشید. پشتیبانی را به مراکز تماس و شرکت‌های دیگر نسپارید. خودتان این کار را انجام دهید. شما و همه اعضای تیم باید بدانید که مشتریها چه می‌گویند. وقتی مشتریها آزرده می‌شوند شما باید مطلع باشید. باید شکایت‌هایشان را بشنوید. شما هم باید ناراحت شوید.
در ۳۷سیگنالز، همه ایمیل‌های پشتیبانی شخصاً توسط کسانی پاسخ داده می‌شود که محصول واقعی را ساخته‌اند. چرا؟ اول از همه این‌که با این کار بهتر از مشتری پشتیبانی می‌شود. آنها پاسخ را از کسی می‌شنوند که برنامه را ساخته است. همچنین باعث می‌شود که ما با کسانی که از محصول ما استفاده می‌کنند در تماس باشیم و از مشکلاتی که آنها با آن برخورد می‌کنند مطلع باشیم. وقتی آنها سرخورده باشند، ما هم سرخورده می‌شویم. آنگاه می‌توانیم در پاسخ بگوییم: «ما درد شما را می‌فهمیم» و واقعاً هم همین‌طور است.
اتکا به تحلیل آماری برای شناخت مشکلات وسوسه کننده است. ولی آمار مانند صداها نیستند. باید تا جایی که می‌توانید هر چیزی را که بین شما و صدای واقعی مشتری‌تان است حذف کنید.
خط مقدم جایی است که کارها اتفاق می‌افتند. به آنجا بروید. آشپزها را وادارید تا مستخدمی کنند. ایمیل‌های مشتریها را بخوانید. سرخوردگی آنها را بشنوید، به پیشنهادهای آنها گوش کنید و از آنها بیاموزید.
مرد میانی را حذف کنید
عمده توسعه، پشتیبانی و بازاریابی Campaign Monitor را دو نفر بر عهده داشته‌اند. حتا اگر مجبور باشیم تیم را گسترش بدهیم، هرگز پشتیبانی را از توسعه جدا نمی‌کنیم. با شخصاً پاسخ دادن به هر درخواستی، خودمان را مجبور می‌کنیم تا کفش‌های مشتری را بپوشیم و چیزها را از نگاه آنها ببینیم.
مهم است که بدانید چرا مشتری‌هایتان چیزی را می‌خواهند نه این که فقط بدانید چه چیزی را می‌خواهند. این زمینه اغلب بر چگونگی طراحی چیزهای مختلف تأثیر مستقیمی دارد. مرد میانی را حذف کنید. وقتی گوش‌هاتان را تیز می‌کنید، آسان‌تر می‌توانید به مشتریها چیزی را بدهید که می‌خواهند.
من در این باره با خیلی‌ها صحبت کرده‌ام و اغلب اوقات اولین چیزی که می‌شنوم این است: «بهتر نیست کار پشتیبانی را به جوانکی بسپارید؟» خودتان را جای مشتری بگذارید. اگر بخواهید استیک‌تان دقیقاً همان‌طور که می‌خواهید درست شود، آیا با سرآشپزی که قرار است آن را بپزد صحبت می‌کنید یا با راننده اتوبوس؟
David Greiner، بنیانگذار Campaign Monitor
برای استفاده از یاهو، گوگل و آمازون نیازی به دفترچه راهنما ندارید. حالا چرا نتوانید برنامه‌ای بسازید که دفترچه راهنما نیاز نداشته باشد؟ بکوشید ابزاری بسازید که نیاز به آموزش نداشته باشد.
چطور این کار را انجام بدهیم؟ همان‌طور که قبلاً به آن اشاره کرده‌ایم همه چیز را ساده کنید. هر چقدر برنامه‌تان ساده‌تر باشد، مردم برای انجام کارهایشان به راهنمایی کمتری نیاز خواهند داشت. بعد از آن، یک راه عالی برای پیش‌دستی کردن در پشتیبانی، ارائه «راهنما» و «پرسش‌های متداول» در خود برنامه و در جاهایی است که نقاط محتمل سردرگمی کاربرند.
مثلاً ما در پشتیبانی پیش‌دستانه را در صفحه‌ای در Basecamp که اجازه می‌دهد کاربر لوگوی خود را بارگذاری کند قرار داده‌ایم. بعضی از مردم بعد از بارگذاری لوگو به مشکل عدم نمایش لوگوی جدید برمی‌خوردند. این مشکل به علت کش مرورگر رخ می‌دهد. بنابراین کنار دکمه «ارسال لوگو» پیوندی به یک پرسش متداول قرار داده‌ایم که به کاربر آموزش می‌دهد چطور مرورگر را مجبور کند که صفحه را دوباره بیاورد تا بتواند لوگوی جدید را ببیند. تا قبل از این که این کار بکنیم، ۵ ایمیل در روز درباره این مشکل داشتیم و بعد از انجام این کار هیچ ایمیلی.
مشتریها وقتی به پرسش‌هایشان زود پاسخ می‌دهید خوشحال می‌شوند. آنها به پاسخ‌های قالبی که با روزها تأخیر به دستشان می‌رسد (یا حتا مواردی اصلاً پاسخی نگرفتن) آشنایند و این همان جایی است که شما می‌توانید با پاسخ فکر شده تفاوت خود را با سایر رقبا به آنها نشان بدهید. ما در ساعت‌های کاری، به ۹۰ درصد درخواست‌های پشتیبانی در زمانی بین نیم ساعت تا ۹۰ پاسخ می‌دهیم. مردم عاشق این سرعت‌اند.
حتا اگر الان پاسخ کاملی ندارید، چیزی بگویید. با پاسخ‌های سریع و صادقانه می‌توانید حسن نیت خودتان را نشان دهید. اگر کسی از موضوعی شکایت می‌کند که نمی‌توان به زودی آن را اصلاح کرد، مثلاً بگویید که «ما حرف‌های شما را شنیدیم و در آینده بر روی آن کار می‌کنیم». این کار، روشی عالی برای از بین بردن موقعیت‌های منفی محتمل است.
مشتریها به صراحت احترام می‌گذارند و اغلب اگر پاسخ دقیق آنها را سریع بدهید، از عصبانیت آنها کم می‌شود و تبدیل به آدم‌های موقز می‌شوند.
ارتش توده‌ها
چطور یک تیم کوچک سه نفره از توسعه‌دهنده‌ها می‌تواند محصولی نوآورانه بسازد و با موفقیت با غول‌ها مبارزه کند؟ با کمک گرفتن از ارتش توده‌ها.
روزهای اولی را به یاد بیاورید که مشتریها باارزش‌ترین دارایی شما و برای موفقیت طولانی مدت شما فوق‌العاده حیاتی بودند. پس با آنها مثل خانواده سلطنتی رفتار کنید. راه رقابت با غول‌ها این است که کار کوچکی را شروع کنید و به تک‌تک مشتری‌هایتان توجه کنید.
مشتری‌هایند که پیش از دیگران خطاها را به شما گوشزد می‌کنند. همان‌ها اولین‌ها هستند که نیازهایی را که باید برآورده سازید به شما می‌گویند. همیشه اولین مشتریها پرچم شما را به دوش می‌کشند و پیغام شما را به گوش دیگران می‌رسانند.
این به این معنی نیست که نرم‌افزار شما باید در اولین عرضه خودش کامل و بی‌نقص باشد. کاملاً بر عکس، سریع و زود به زود عرضه کنید. با این حال هر وقت مشتریها به خطا برخوردند، مطمئن شوید که حتماً به آنها پاسخی می‌فرستید و از آنها به خاطر اطلاع‌رسانی تشکر می‌کنید.
مشتریها توقع ندارند که محصول شما کامل باشد و همه ویژگی‌هایش پیاده‌سازی شده باشد. ولی توقع دارند که به آنها گوش کنید و با پاسخ دادن به آنها نشان دهید که موضوع برای شما مهم است، پس به آنها نشان دهید که به آنها اهمیت می‌دهید. این همانجایی است که خیلی از شرکت‌های بزرگ کمبود دارند. بنابراین همان اول کاری کنید که حس کنند عضو یک گروه و انجمن‌اند.
در BlinkList هر ایمیل مشتری پاسخ داده می‌شود، معمولاً در همان ساعت اول (جز در وقتی که ما خواب باشیم). ما حتا یک انجمن برخط داریم و مطمئن می‌شویم که هر مطلب مشتریها در آنجا پاسخی خواهد داشت.
چیز دیگری که به همین اندازه مهم است این است که همه توسعه‌دهنده‌های ما بازخوردهای کاربران را می‌گیرند و همه آنها اعضای فعال انجمن بحث برخط هستند. با این روش ما به آرامی ولی با اطمینان انجمنی وفادار و فعال برای BlinkList می‌سازیم.
Michael Reining، بنیانگذار مشترک MindValley و Blinklist
وقتی موضوع درخواست ویژگی‌های جدید است، همیشه حق با مشتری نیست. اگر هر چیزی که مشتریها می‌خواستند اضافه می‌کردیم دیگر هیچکس محصول را نمی‌خواست.
اگر از همه علایق مشتریها اطاعت می‌کردیم آنگاه Basecamp باید این‌ها را می‌داشت: مدیریت زمان جامع، صورت حساب جامع، مدیریت ملاقات‌های جامع، تقویم جامع، سامانه وابستگی وظایف جامع، پیغام‌رسان (تیزپیک) جامع، قابلیت‌های ویکی جامع و «هر-چیزی-که-فکرش-را-بکنید» جامع.
در عین حال درخواست شماره یک مشتریها در نظرسنجی‌ها ساده نگه داشتن Basecamp بود.
یک مثال دیگر: علیرغم برخی اعتراض‌ها، تصمیم گرفتیم در محصولاتمان از IE5 پشتیبانی نکنیم. آن زمان IE5 هفت درصد بازار را در اختیار داشت. ولی ما به این نتیجه رسیدیم که آن ۹۳ درصد دیگر مهم‌ترند. گرفتن خطاهای مرتبط با IE5 و آزمودن برنامه با آن ارزش زمانی که برای این کار صرف می‌شد را نداشت. در عوض برای بقیه محصول بهتری می‌ساختیم.
به عنوان یک شرکت نرم‌افزاری، باید مثل پالایه (فیلتر) عمل کنید. هر چیزی که هر کسی پیشنهاد داد، درست نیست. ما به همه درخواست‌ها اهمیت می‌دهیم ولی همیشه حق با مشتری نیست. وقت‌هایی است که باید بعضی‌ها را شست و کنار گذاشت. زندگی یعنی همین.
در همین باره، به عنوان یک شرکت توسعه‌دهنده باید عاشق محصولتان باشید. و اگر آن را با انبوهی از چیزهایی که دوست ندارید پر کنید، دیگر عاشق‌ش نخواهید بود. این معیاری دیگر برای رد کردن درخواست‌هایی از جانب مشتریان است که اعتقاد دارید ضروری نیستند.
انجمن‌ها و گفتگوهای وبی راهی عالی است تا کاربران بتوانند پرسش‌های خود را بپرسند و به دیگران هم کمک کنند. با حذف مرد میانی (که در اینجا خودتان‌اید) جریانی از ارتباطات را به راه می‌اندازید و در این میان وقت خود را پس‌انداز می‌کنید.
در انجمن محصولات ما، مشتریها نکته‌ها و حقه‌ها، درخواست ویژگی، داستان‌ها و خیلی چیزهای دیگر را منتشر می‌کنند. ما هم گاه‌گاهی سر می‌زنیم تا در صورت نیاز کمک کنیم ولی انجمن‌ها در اصل جایی‌اند که اعضا به هم کمک می‌کنند و تجربه‌هایشان درباره محصول را به اشتراک می‌گذارند.
قطعاً از دیدن این که چقدر مردم می‌خواهند به هم کمک کنند شگفت‌زده خواهید شد.
اگر اشتباهی رخ داد، به مردم بگویید. حتا اگر آنها خودشان ممکن بود متوجه نشوند.
مثلاً یک بار Basecamp برای چند ساعت در نیمه شب از کار می‌افتاد. ۹۹ درصد کاربران هرگز از این موضوع مطلع نمی‌شدند ولی ما هشداری با عنوان «خاموشی ناخواسته» را در وبلاگ Everything Basecamp منتشر کردیم. ما فکر می‌کردیم که کاربران حق دارند از این موضوع مطلع باشند.
نمونه‌ای از آن چیزی که وقتی کارها درست پیش نمی‌روند منتشر می‌کنیم این است: «به خاطر قطعی امروز صبح عذر می‌خواهیم. با پایگاه داده مشکلی داشتیم که برای بعضی کاربران باعث کندی شدید برنامه می‌شد. ما این مشکل را حل کرده‌ایم و برای اطمینان از این که این مشکل در آینده رخ نمی‌دهد، گام‌هایی برداشته‌ایم... از شکیبایی شما سپاسگزاریم و یکبار دیگر به خاطر قطعی شرمندگی خود را اعلام می‌کنیم.»
تا جایی که ممکن است باز، راستگو و شفاف باشید. رازداری نکنید و پشت توجیه‌های الکی خودتان را مخفی نکنید. مشتری مطلع، بهترین مشتری است. حسن دیگر این کار این است که می‌فهمید گندکاری‌هایتان آنقدرها هم برای مشتریها مهم نیست. مشتریها اگر بدانند با آنها صادق‌اید، مجالی برای رفع مشکل به شما می‌دهند.
نکته‌ای حاشیه‌ای درباره انتشار اخبار، خبرهای خوب و بد: وقتی خبر بدی را اعلام می‌کنید، به یکباره همه آن را اعلام کنید. ولی از آن طرف، اخبار خوب را قطره‌چکانی بگویید. حتا اگر می‌توانید آن حس خوب را در زمان بیشتری و ذره ذره اعلام کنید، حتماً این کار را بکنید.
سریع، صریح و صادق باشید
ممکن است عجیب به نظر برسد ولی بهترین سناریو وقتی است که شرکتی خودش اخبار بد را اعلام کند. این کار روشی غیر منفعلانه است و مانع این می‌شود که شرکت در موضع ضعف و تدافعی قرار بگیرد.
Greg Sherwin، قائم مقام بخش فناوری‌های کاربردی CNET و Emily Avila رئیس Calypso Communications (به نقل از A Primer for Crisis PR)
