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