მობილური აპის booking flow: რა ჩაიწეროს დაკვეთაში
ჯავშნის გზის შესყიდვის ჩარჩო: დროის სლოტი, რესურსი, დადასტურება, გაუქმება, კონფლიქტი, გადახდა და ტესტი.
ჯავშნის აპში კალენდართან ერთად განსაზღვრეთ, ვინ იკავებს სლოტს, როდის დასტურდება ჯავშანი და რა ხდება გადატანის ან გაუქმებისას.
თუ ეს წესები ჯერ დაუმუშავებელია, aiAPP-ის პროექტის განხილვაში გამოგზავნეთ მომსახურების ტიპი, რესურსები და გაუქმების სცენარი.
ჯავშნის გზა ბიზნესის ენაზე
ჯავშნის პროცესი არის გზა მოთხოვნიდან დადასტურებულ ჯავშნამდე. მასში შედის სერვისის ან რესურსის არჩევა, ხელმისაწვდომი დროის ნახვა, მომხმარებლის მონაცემების შეყვანა, პირობების მიღება, გადახდის საჭიროება, დადასტურება და შემდგომი ცვლილება. სალონის ვიზიტი, კლინიკის დრო, ტურისტული ტური და ტექნიკოსის ვიზიტი ერთმანეთისგან განსხვავდება, თუმცა ყველა მათგანს სჭირდება მკაფიო სტატუსები.
მომხმარებელი კალენდარში თავისუფალ დროს ხედავს, მაგრამ ეს დრო საბოლოოდ თავისუფალი შეიძლება აღარ იყოს, როცა სხვა ადამიანი იმავე სლოტს იკავებს. ამიტომ სერვერმა უნდა გადაამოწმოს ხელმისაწვდომობა დადასტურების მომენტში. აპის ეკრანზე ნაჩვენები დრო ვერ იქნება ერთადერთი სიმართლე.
Apple-ის Human Interface Guidelines date picker-ს კონკრეტული თარიღის, დროის ან ორივეს ასარჩევად აღწერს და აღნიშნავს, რომ მნიშვნელობები მოწყობილობის ენასა და მდებარეობაზეა დამოკიდებული. ეს მყიდველს ახსენებს, რომ კალენდრის ვიზუალი ბიზნესის დროის ზონას, ადგილობრივ ფორმატს და მომხმარებლის მოწყობილობას უნდა მოერგოს.
ჯავშნის მონაწილეები და საგანი
პირველი ნაბიჯია მონაწილეებისა და რესურსების ჩამოწერა. მომხმარებელი შეიძლება ჯავშნიდეს ადამიანს, ოთახს, მანქანას, მომსახურების სლოტს ან რამდენიმე რესურსს ერთად. ოპერატორი შეიძლება ამტკიცებდეს, ცვლიდეს ან აუქმებდეს ჯავშანს. მენეჯერს შეიძლება ჰქონდეს კალენდრის დაბლოკვის უფლება, ხოლო ფინანსურ როლს თანხის დაბრუნების მართვა.
- რესურსი: რა ერთეული იკავება და შეიძლება თუ არა ერთდროულად რამდენიმე ჯავშანი?
- დრო: რომელია დროის ზონა, სამუშაო საათები, შესვენება და დღესასწაული?
- მონაწილე: რა მონაცემი სჭირდება მომხმარებელს და რას ხედავს ოპერატორი?
- წესი: რამდენი ხნით ადრე შეიძლება დაჯავშნა, გაუქმება ან გადატანა?
- მტკიცებულება: რომელი შეტყობინება, კოდი ან ჩანაწერი ადასტურებს ჯავშანს?
თუ რესურსი რამდენიმე ადგილზე მუშაობს, ფილიალი და ლოკაცია ცალკე ობიექტებია. თუ მომსახურებას რამდენიმე თანამშრომელი ასრულებს, კალენდარი მხოლოდ თავისუფალ საათებს არ უნდა აჩვენებდეს. საჭიროა უნარების, სამუშაო ზონის ან ხელმისაწვდომობის ბიზნესწესი.
ჯავშნის სტატუსები
ჯავშნის მინიმალური სტატუსები ჩვეულებრივ მოიცავს ინიციაციას, დროებით დაკავებას, დადასტურებას, შესრულებას, გაუქმებას და არმოსვლას. კონკრეტული სახელები თქვენს პროცესს ეკუთვნის. მთავარი მოთხოვნაა, რომ თითოეულ მდგომარეობას ჰქონდეს შემდგომი მოქმედება, პასუხისმგებელი და მომხმარებლისთვის გასაგები ტექსტი.
დროის სლოტის დროებით დაკავება შეიძლება სასარგებლო იყოს გადახდის წინ, მაგრამ მისი ხანგრძლივობა და გათავისუფლების წესი წერილობით უნდა ჩაიწეროს. თუ აპი დაიხურა ან კავშირი გაწყდა, მომხმარებელმა უნდა იცოდეს, ჯავშანი შეიქმნა თუ არა. ოპერატორს უნდა შეეძლოს დავის მიზეზის პოვნა ჟურნალში.
რით განსხვავდება ჯავშანი, მოთხოვნა და რიგი?
| მოდელი | რას ჰპირდება მომხმარებელს | რა უნდა დაამტკიცოს აპმა |
|---|---|---|
| დადასტურებული ჯავშანი | კონკრეტული დრო და რესურსი დაკავებულია | ორმაგი დაკავება არ ხდება და დადასტურება ინახება |
| მოთხოვნა | ბიზნესი მოგვიანებით პასუხს გასცემს | მოთხოვნის სტატუსი და პასუხის პასუხისმგებელი ჩანს |
| რიგი | მომხმარებელი ელოდება ხელმისაწვდომობას | რიგის ადგილი, წინსვლა და გასვლის წესი გასაგებია |
ეს განსხვავება მნიშვნელოვანია შეთავაზებების შედარებისას. ერთმა დეველოპერმა შეიძლება „booking“ მოთხოვნის ფორმად ჩათვალოს, მეორემ კი ორმხრივი კალენდარი, გადახდა და ოპერატორის პანელი იგულისხმოს. მოთხოვნების ჩეკლისტი დაგეხმარებათ ფუნქციის ნაცვლად მომხმარებლის შედეგი აღწეროთ.
რა ხდება ჯავშნის რთულ შემთხვევებში?
ჩაწერეთ ორმაგი დაჯავშნა, რესურსის ხელმიუწვდომლობა, არასწორი დროის ზონა, დაგვიანებული გადახდის პასუხი, მომხმარებლის გაუქმება, ოპერატორის ცვლილება და შეტყობინების მიუღებლობა. თითოეულს აქვს განსხვავებული შედეგი. მაგალითად, ოპერატორის მიერ ცვლილება მომხმარებელს უნდა ეცნობოს, ხოლო წარუმატებელი გადახდა არ უნდა ტოვებდეს დადასტურებულ ჯავშანს, თუ ბიზნესი ამას არ უშვებს.
Freeterium-ის საჯარო აღწერაში ჯავშანი და გადახდა ერთად არის წარმოდგენილი. ეს კონკრეტული შეთავაზების მაგალითია; თქვენი ჯავშნისა და გადახდის წესები ცალკე უნდა ჩაიწეროს.
როგორ შეამოწმოთ ჯავშნის პროცესი?
მიღების ტესტი დაწერეთ სცენარებად. ერთ მომხმარებელს მიეცით თავისუფალი სლოტი, მეორეს იგივე სლოტი, შემდეგ შეცვალეთ პირველი ჯავშანი, გააუქმეთ მეორე მოთხოვნა და გაითამაშეთ კავშირის გაწყვეტა. შეამოწმეთ აპი, ოპერატორის პანელი, შეტყობინება და ჟურნალის ჩანაწერი. დროისა და მოწყობილობის ენა ცალკე გამოცადეთ.
განსაზღვრეთ, რა არის pass: ერთი საბოლოო დადასტურება, სწორად გათავისუფლებული სლოტი, ერთმნიშვნელოვანი მომხმარებლის ტექსტი და მფლობელისთვის მოძებნადი ისტორია. თუ დეველოპერი მხოლოდ კალენდრის ვიზუალურ დემოს აჩვენებს, ეს ტესტი ჯერ არ დასრულებულა.
რა უნდა მიიტანოთ პროექტის განხილვაზე?
- მიუთითეთ მომსახურება, რესურსი, მომხმარებელი და ოპერატორი.
- დახაზეთ დროის სლოტის შექმნა, დაჭერა, დადასტურება და გათავისუფლება.
- ჩამოწერეთ გაუქმების, გადატანის, დაგვიანებისა და არმოსვლის წესები.
- მიუთითეთ payment, reminder, calendar ან სხვა გარე კავშირები.
- შეადგინეთ ერთდროული მოთხოვნებისა და კავშირის დაკარგვის ტესტები.
- დაასახელეთ ვინ იღებს საბოლოო ჯავშნის გადაწყვეტილებას.
ეს პაკეტი გაუგზავნეთ aiAPP-ის განხილვას. ინტეგრაციების გვერდი დაგეხმარებათ შესაძლო კავშირების დასახელებაში, სამუშაო ფორმატი კი გამორიცხვებისა და შეთანხმების კითხვების მომზადებაში.
რომელი შეცდომები ჩანს უკვე პირველ დემოში?
ხშირია თავისუფალი დროის ჩვენება საბოლოო დადასტურების გარეშე. ასევე პრობლემურია კალენდრისა და backend-ის სხვადასხვა დროის ზონა, გაუქმების წესის ტექსტში დაუწერლობა, reminder-ის პასუხისმგებლის არარსებობა და ერთი ოპერატორის ანგარიშით ყველა ცვლილების გაკეთება.
არ უნდა აირიოს მობილური ჯავშნის აპი მზა კალენდრის ჩაშენებაში. შესაძლოა მზა სერვისი გამოგადგეთ, მაგრამ თუ თქვენ გაქვთ რესურსის რთული შეზღუდვა, რამდენიმე მონაწილე ან თანხის დაბრუნების წესი, ინდივიდუალურად განსაზღვრული გზის მიღების მტკიცებულება მაინც დაგჭირდებათ.
რა ვერ დაამტკიცებს booking აპი?
ჯავშნის ავტომატიზაცია ვერ დაამტკიცებს, რომ მომხმარებელი მოვა, რესურსი ყოველთვის თავისუფალი იქნება ან ბიზნესი მეტ შემოსავალს მიიღებს. გარე კალენდარი, გადახდის provider, SMS ან push არხი შეიძლება შეფერხდეს. ზუსტი წესები თქვენს ოპერაციასა და ხელშეკრულებას ეკუთვნის.
aiAPP ქმნის ახალ მობილურ აპებს, მაგრამ კონკრეტული booking სისტემის ხელმისაწვდომობა წინასწარ არ არის დაპირებული. შედეგი უნდა განისაზღვროს თქვენი რესურსებით, სტატუსებით, გამონაკლისებითა და ტესტით.
ხშირად დასმული კითხვები
ჯავშნის აპს აუცილებლად სჭირდება გადახდა?
არა. ზოგიერთ ბიზნესში ჯავშანი მხოლოდ მოთხოვნაა, ზოგში კი დადასტურებამდე ან შემდეგ გადახდას მოითხოვს. ეს წესი თავიდანვე უნდა ჩაიწეროს.
კალენდრის ეკრანი საკმარისია MVP-სთვის?
არა, თუ მომხმარებლის გზა მოიცავს დაჯავშნას. საჭიროა დადასტურება, სტატუსი, შეცდომა, გაუქმება და ოპერატორის მტკიცებულება.
როგორ ამოწმებს სისტემა ორმაგ ჯავშანს?
სერვერმა უნდა გადაამოწმოს რესურსისა და დროის ხელმისაწვდომობა დადასტურებისას და აჩვენოს მკაფიო შედეგი, როცა სხვა მოთხოვნამ სლოტი უკვე დაიკავა.
დაკავშირებული მასალა
- მობილური აპის მოთხოვნების ჩეკლისტი
- დეველოპერის შერჩევის კრიტერიუმები
- ჯავშნის პროცესის განხილვა
- ინტეგრაციების გვერდი
- უსაფრთხოების ინფორმაცია
გამოყენებული წყაროები
სარედაქციო შენიშვნა: ტექსტის მომზადებაში გამოყენებულია ხელოვნური ინტელექტი.