ორმხრივი ბაზრის მობილური აპი: როგორ შეუკვეთოთ
ბიზნესისთვის პრაქტიკული გზამკვლევი: მყიდველისა და გამყიდველის როლები, შემოწმება, სადავო ოპერაციები და პირველი ვერსიის საზღვრები.
ორმხრივი ბაზრის მობილური აპის შეკვეთაში მყიდველისა და გამყიდველის გზები ცალ-ცალკე უნდა დაიწეროს. პირველ ვერსიას სჭირდება პასუხი, ვინ დებს შეთავაზებას, ვინ ამოწმებს მას, როგორ ხდება შეკვეთის დადასტურება და ვინ წყვეტს სადავო შემთხვევას. მხოლოდ პროდუქტების კატალოგის ეკრანი მარკეტპლეისს ვერ შექმნის.
ორმხრივი ბაზრის ახალი აპისთვის aiAPP-ს გაუგზავნეთ ერთი სრული გარიგების გზა. მყიდველისა და გამყიდველის მოქმედებები ცალკე აღწერეთ, რათა შეთავაზებაში მხოლოდ კატალოგის ეკრანები არ აღმოჩნდეს.
ორმხრივი ბაზრის განსხვავება მაღაზიისგან
ჩვეულებრივ ონლაინ მაღაზიაში საქონლისა და შეკვეთის პირობებს ერთი გამყიდველი მართავს. ორმხრივ ბაზარში რამდენიმე დამოუკიდებელი მონაწილე შეიძლება აქვეყნებდეს შეთავაზებას და თითოეულს თავისი პასუხისმგებლობა ჰქონდეს. ამიტომ აპს შეიძლება დასჭირდეს გამყიდველის მიღების წესი, განცხადების შემოწმება, მყიდველის შეკითხვაზე პასუხი და ოპერატორის ჩარევა. ეს ფუნქციები ერთნაირად არ ერგება ყველა ბიზნესს; პირველ რიგში დაწერეთ, ვინ არის გარიგების მხარე და ვინ იღებს გადახდას.
მაგალითად, ადგილობრივი სერვისების პლატფორმაზე მომსახურების გამწევი უთითებს თავისუფალ დროს, მომხმარებელი აგზავნის მოთხოვნას, ხოლო დადასტურებამდე ოპერატორი ამოწმებს პირობებს. ეს მხოლოდ ილუსტრაციული სცენარია. შესაძლოა სხვა მოდელში ოპერატორი საერთოდ არ იყოს, მაგრამ მაშინ შეცდომისა და დავის წესიც სხვაგვარად უნდა განისაზღვროს.
პირველი ვერსიის სამუშაო მოცულობა
დაიწყეთ ერთი კატეგორიითა და ერთი სრულად დასასრულებელი გარიგებით. ჩაწერეთ თითოეული როლის აუცილებელი მოქმედება: შეთავაზების შექმნა, პოვნა, არჩევა, დადასტურება, გაუქმება და მხარდაჭერა. თუ რომელიმე როლი მხოლოდ ხელით იმუშავებს, ესეც შეთანხმებაში ჩანდეს. პირველ ვერსიას არ სჭირდება ყველა შესაძლო რეიტინგი, აუქციონი და რთული საკომისიო, თუ ძირითადი გარიგება ჯერ შეუმოწმებელია.
შეთავაზებების შედარებისას მოითხოვეთ როლების ცხრილი და მოქმედების უფლებები. გამყიდველის მიერ შეცვლილი ფასი უკვე დაწყებულ შეკვეთას ეხება თუ მხოლოდ მომავალს? შეიძლება თუ არა განცხადების დამალვა და ვის შეუძლია ამის გაკეთება? მსგავსი კითხვები მონაცემთა მოდელსა და ადმინისტრატორის ეკრანებს განსაზღვრავს, ამიტომ ისინი დიზაინის ბოლოს ვერ გადაიდება.
განსაზღვრეთ გამყიდველის მიღების გზაც. ნებისმიერი მსურველი მაშინვე აქვეყნებს შეთავაზებას თუ ოპერატორი ჯერ ამოწმებს მის პროფილს? თუ დამტკიცებაა საჭირო, რა ჩანს მას მანამდე და რა შეტყობინებას იღებს უარის შემთხვევაში? ამ კითხვებს აქვთ პირდაპირი გავლენა დეველოპმენტის მოცულობაზე: საჭირო ხდება სტატუსები, შეტყობინებები და ადმინისტრატორის გადაწყვეტილების ეკრანი. ხშირად სწორედ ეს სამუშაო აკლია შეთავაზებას, რომელიც მხოლოდ კატალოგისა და კალათის სურათებს აჩვენებს.
მარკეტპლეისის ბიზნესს ასევე სჭირდება პასუხი, ვინ ამოწმებს პროდუქტის ან მომსახურების აღწერის სისწორეს. აპმა შეიძლება ტექსტის ფორმა შეამოწმოს, მაგრამ ვერ დაადასტურებს განცხადების რეალურ ხარისხს. მყიდველმა უნდა იცოდეს, ვის მიმართავს, თუ მიღებული ნივთი აღწერას არ ემთხვევა. სანამ ეს წესი არ არსებობს, შეფასებებისა და საჩივრების ეკრანის დიზაინი მხოლოდ გარეგნული გადაწყვეტილებაა.
როგორ გაყოფოთ გადახდისა და დავის პასუხისმგებლობა?
თუ აპში გადახდა ხდება, უნდა გაირკვეს, ვის ანგარიშზე შედის თანხა, როდის სრულდება გარიგება, რა ხდება გაუქმებისას და ვის ეკუთვნის დაბრუნების გადაწყვეტილება. Apple-ისა და Google Play-ის მოქმედი წესები სხვადასხვა ტიპის ციფრულ და ფიზიკურ საქონელზე განსხვავებულ მოთხოვნებს ადგენს. ამიტომ გადახდის არხის არჩევა მხოლოდ ტექნიკური ბიბლიოთეკის არჩევა არ არის. კონკრეტული საქონლისა და ბაზრისთვის წესები გამოშვებამდე უნდა შემოწმდეს.
ვინ მართავს პრობლემურ შეთავაზებას?
ორმხრივი ბაზარი მოიცავს სხვა ადამიანების მიერ დამატებულ შინაარსს. წინასწარ განსაზღვრეთ, ვინ ხედავს საჩივარს, როგორ დროებით იმალება საეჭვო განცხადება და რა მტკიცებულება რჩება გადაწყვეტილების შემდეგ. მყიდველს უნდა ჰქონდეს გასაგები გზა შეცდომის შესატყობინებლად. თუ მოდერაცია მხოლოდ „მერე გავაკეთებთ“ ჩანაწერად დარჩა, პროდუქტის ოპერაციული მოვლა გაურკვეველი იქნება.
როგორ მიიღოთ ფუნქციური შედეგი?
მიღების ტესტში სხვადასხვა როლის სატესტო ანგარიშებით გაიარეთ ერთი სრული გარიგება, გაუქმება და საჩივარი. შეამოწმეთ, რომ გამყიდველი ვერ ცვლის სხვის მონაცემს, მყიდველი ხედავს შეთანხმებულ ფასსა და სტატუსს, ხოლო ოპერატორს შეუძლია მიზეზით იმოქმედოს. გაითვალისწინეთ უარის გზა: რა ჩანს მაშინ, როცა განცხადება ჯერ არ არის დამტკიცებული ან მომსახურება აღარ არის ხელმისაწვდომი.
aiAPP-ის დადასტურებული მომსახურება ახალი iOS და Android აპის შექმნას მოიცავს. არც მარკეტპლეისის მზა მოდული, არც გადახდის პროვაიდერი და არც სამართლებრივი მოდელი არ არის ამით დადასტურებული. გაუგზავნეთ aiAPP-ს ორი როლისა და ერთი გარიგების აღწერა, რათა წერილობით შეთავაზებაში სამუშაოს ზღვარი გამოჩნდეს. საერთო მოთხოვნების ფორმულირებისთვის იხილეთ მოთხოვნების ჩეკლისტი და დეველოპერის შერჩევის კრიტერიუმები.
რა უნდა დარჩეს ცალკე გადაწყვეტილებად?
აპი ვერ უზრუნველყოფს თავისით გამყიდველის სანდოობას, პროდუქტის ხარისხს ან დავის სამართლიან გადაწყვეტას. ეს ოპერაციული და სამართლებრივი პროცესებია. თუ ბიზნესს ჯერ არ ჰყავს პასუხისმგებელი ადამიანი მოდერაციასა და დავებზე, სრული ავტომატიზაციის დაპირება სახიფათო იქნება. ჯერ განსაზღვრეთ წესი და გამონაკლისები, შემდეგ შეუკვეთეთ მათი ტექნიკური მხარდაჭერა.
გაშვების შემდეგაც ახალი მონაწილეების დამატება მოდელის გამოცდაა. პირველივე მოცულობაში არ არის საჭირო ყველა კატეგორიის, ქალაქისა და გადახდის ვარიანტის ჩართვა. სჯობს ერთი გარიგების გზა სრულად გამოსცადოთ და გაიგოთ, რომელი კითხვა რჩება ოპერატორთან. მომდევნო კატეგორიის დამატება უკვე ნანახ წესებზე უნდა დაეფუძნოს, თორემ პირველი შეცდომა უბრალოდ მეტ მონაწილეზე გავრცელდება.
მომწოდებელს მოსთხოვეთ, აჩვენოს არა მარტო წარმატებული შესყიდვა, არამედ შემთხვევა, როცა გამყიდველი შეთავაზებას უკან იღებს მას შემდეგ, რაც მყიდველმა მოთხოვნა გაგზავნა. ამ მომენტში უნდა ჩანდეს, რა იცვლება ორივე მხარის ეკრანზე და ვის შეუძლია დავის გახსნა. მსგავსი მიღების სცენარი ერთდროულად ამოწმებს როლებს, შეტყობინებებს, ისტორიის შენარჩუნებასა და ოპერატორის უფლებას. სწორედ ასეთი შემოწმება განასხვავებს სამუშაო ბაზარს ლამაზი კატალოგის დემოსგან.
წყაროები
Google Play-ის მომხმარებლის კონტენტის წესი: თუ გამყიდველები საჯარო შეთავაზებებს აქვეყნებენ, საჩივრისა და მოდერაციის გზა წინასწარ უნდა დაიგეგმოს.
სარედაქციო შენიშვნა: ტექსტის მომზადებაში გამოყენებულია ხელოვნური ინტელექტი.