აუქციონის მონაცემების ჩართვამდე: ავტოდილერის ტექნიკური შემოწმების სია

აუქციონის კატალოგის ჩართვამდე საჭიროა ოთხი პასუხი: რომელი წყარო გჭირდებათ, რომელი მონაცემი გამოჩნდება, სად ტოვებს კლიენტი მოთხოვნას და ვინ ამოწმებს ცვლილებას გაშვების შემდეგ.

რით დაიწყოთ წყაროს შემოწმება?

ჯერ დაასახელეთ, რომელი წყაროს მონაცემის ჩვენება გსურთ: Copart, IAAI, Manheim თუ სხვა. შემდეგ გადაამოწმეთ, გაქვთ თუ არა შესაბამისი წვდომა და გამოყენების უფლება. აუქციონის საჯარო გვერდის ნახვა ავტომატურად არ ნიშნავს, რომ მისი ყველა მონაცემის ხელახლა გამოქვეყნება შეგიძლიათ. წყაროს პირობები და მონაცემის გამოყენების წესი ყოველთვის ცალკე გადასამოწმებელია.

Copart-ის ოფიციალური გვერდი, IAAI-ის რეგისტრაციის გვერდი და Manheim-ის Simulcast გზამკვლევი დაგეხმარებათ გაიგოთ თითოეული პლატფორმის მონაწილეობის გარემო. ისინი არ ადასტურებს aiVIN-ის რეალურ ინტეგრაციას. aiVIN-ის დღევანდელი საჯარო კატალოგი დემოს ფორმატია.

რომელი ველები უნდა შეთანხმდეს?

დაიწყეთ მცირე სქემით: წყარო, ლოტის ნომერი, მანქანის დასახელება, წელი, VIN-ის დაფარული ნაწილი, გარბენი, დაზიანების აღწერა, ფოტო, ადგილმდებარეობა, გაყიდვის თარიღი და ბიდთან დაკავშირებული განმარტება. თუ ველი ყველა წყაროდან ერთნაირად არ მოდის, გვერდმა უნდა შეინახოს ეს სხვაობა. არ შექმნათ ხელოვნური თანასწორობა მხოლოდ დიზაინისთვის.

რით განსხვავდება კატალოგი და ბიდის სისტემა?

კატალოგი მომხმარებელს აჩვენებს მანქანებს, ფილტრებს და მოთხოვნის გზას. Bid Control კომპანიის შიდა გადაწყვეტილებას ეხება: დილერის ლიმიტს, დამტკიცებას და ისტორიას. ორი ბლოკი შეიძლება ერთ საიტზე იყოს, მაგრამ მომხმარებლის კატალოგში ნაჩვენები მანქანა არ უნდა წარმოაჩინოთ როგორც რეალური ბიდის შესაძლებლობა, სანამ ეს ფუნქცია არ არსებობს.

რომელი რამ არ უნდა დაჰპირდეთ გაშვებამდე?

არ დაასახელოთ მონაცემი ცოცხლად განახლებად, თუ განახლების წესს ვერ ამოწმებთ. არ დაჰპირდეთ ავტომატურ მოთხოვნის გადაცემას CRM-ში, თუ ეს კავშირი ჯერ არ არის ჩართული. არ გამოიყენოთ რეალური ლოტის ფოტო ისე, თითქოს ავტომობილი თქვენი მარაგია. ასეთ დაპირებებს მომხმარებელი მოგვიანებით ადვილად ამჩნევს.

რა არის მინიმალური გაშვების სია?

1. წყაროსა და გამოყენების უფლების გადამოწმება.
2. მონაცემის ველების ჩამონათვალი.
3. წყაროსა და განახლების დროის ეტიკეტები.
4. მობილურზე გამოსადეგი ძიება და ფილტრები.
5. ლოტთან მიბმული მოთხოვნის ფორმა.
6. ტესტი, რომ ფორმაში გადადის სწორი ლოტის კონტექსტი.

ვინ ფლობს თითოეულ პასუხს?

გაშვების მზადყოფნის სია ტექნიკურ ველებთან ერთად პასუხისმგებლობის სქემასაც უნდა მოიცავდეს. ვინ ამოწმებს, რომ წყაროს გამოყენების უფლება სწორად არის გაგებული? ვინ წყვეტს, რომელი ლოტი დარჩეს კატალოგში? ვინ ამოწმებს მომხმარებლის მოთხოვნას და ვინ პასუხობს, თუ წყაროს სტატუსი შეიცვალა? ეს როლები შეიძლება ერთ ადამიანს ეკუთვნოდეს, მაგრამ მათი დასახელება მაინც საჭიროა. წინააღმდეგ შემთხვევაში, ფორმა მუშაობს, ბარათი ჩანს, ხოლო შეცდომაზე პასუხისმგებელი არ ჩანს.

თითოეულ მნიშვნელოვან მოქმედებას დაურთეთ სტატუსი: დაგეგმილი, შემოწმებული, გაშვებისთვის მზად ან გაჩერებული. „გაშვებული“ არ გამოიყენოთ მხოლოდ იმიტომ, რომ გვერდი ბრაუზერში იხსნება. ტექნიკური ხელმისაწვდომობა და მონაცემის სისწორე სხვადასხვა შემოწმებაა.

მონაცემის სიხშირე და ძველი ლოტი

კატალოგის მნახველს უნდა ესმოდეს, რომ აუქციონის ლოტის მდგომარეობა შეიძლება შეიცვალოს. თუ განახლების ავტომატური მექანიზმი არ არსებობს, გვერდზე არ დაწეროთ „ცოცხალი მონაცემი“ ან „ყოველ წუთს განახლდება“. გამოიყენეთ უფრო ზუსტი ტექსტი, მაგალითად „წყაროში გადაამოწმეთ საბოლოო სტატუსი“. თუ გუნდი პერიოდულად ამოწმებს მონაცემს, შიდა წესში ჩაიწეროს ვინ აკეთებს ამას და რას ნიშნავს მოძველებული ლოტის შეჩერება.

ძველი ლოტის ავტომატურად დატოვება ცუდად მოქმედებს როგორც მომხმარებლის ნდობაზე, ისე შიდა სამუშაოზე. თუმცა ყველა ძველი ლოტის წაშლა შეიძლება ართულებდეს ისტორიის შენახვას. ამიტომ წინასწარ გადაწყვიტეთ, რომელი ჩანაწერი უნდა დაიმალოს საჯარო კატალოგიდან, რომელი დარჩეს არქივად და როგორ აღინიშნოს ეს განსხვავება. კონკრეტული ვადა მხოლოდ მაშინ მიუთითეთ, როცა მას რეალური პროცესი ამყარებს.

მოთხოვნის ფორმის ტესტირება

ფორმის ტესტი მხოლოდ ღილაკის დაჭერა არ არის. გახსენით ერთი ლოტი, ჩაწერეთ სატესტო სახელი, გაგზავნეთ მოთხოვნა და გადაამოწმეთ, რომ მიღებულ შეტყობინებაში იგივე ლოტის ნომერი და დასახელება ჩანს. შემდეგ სცადეთ სხვა ლოტი და ნახეთ, ხომ არ რჩება პირველი მანქანის კონტექსტი. ბოლოს შეამოწმეთ, რას ხედავს ადამიანი შეცდომის დროს და შეუძლია თუ არა მოთხოვნის ხელახლა გაგზავნა. ეს არის ტექნიკური შემოწმება, არა მომხმარებლის რეალური შედეგის მტკიცებულება.

თუ ფორმა ცარიელ შეტყობინებას ან სხვა ლოტის მონაცემს გზავნის, გაშვება უნდა შეჩერდეს. მომხმარებელს არ უნდა სთხოვოთ, ბმული ხელით დააკოპიროს, თუ თქვენივე გვერდი კონკრეტულ ლოტზე საუბრობს. ამავე დროს, ნუ დაჰპირდებით ავტომატურ CRM გადაცემას, სანამ ის კავშირი ფაქტობრივად არ არის ჩართული და გამოცდილი.

პლატფორმის წყარო და პროდუქტის საზღვარი

Copart-ის ოფიციალური მონაწილეობის გვერდი, IAAI-ის რეგისტრაციის მასალა და Manheim-ის Simulcast Buyer’s Guide აღწერს შესაბამისი აუქციონის გარემოს. ამ გვერდების არსებობა არ ნიშნავს, რომ aiVIN-ს აქვს მათი რეალური ინტეგრაცია ან რომ კონკრეტული ლოტი ავტომატურად გადავა თქვენს სისტემაში. წყაროს სახელი შეიძლება იყოს კვლევის დასაწყისი, მაგრამ ჩართული პროდუქტის ფუნქცია მხოლოდ შემოწმებული კოდის, მონაცემისა და რეალური ტესტის საფუძველზე უნდა აღწეროთ.

კატალოგი და Bid Control ასევე არ უნდა გაერთიანდეს ერთ დაპირებად. კატალოგი აჩვენებს წყაროს ლოტებს და მოთხოვნის გზას. შიდა დამტკიცება ეხება კომპანიის უფლებებს, ლიმიტებსა და გადაწყვეტილების ისტორიას. სანამ ეს საზღვრები ცალკეა აღწერილი, მომხმარებელს უფრო მარტივად ესმის, რა ხდება გვერდზე და რა უნდა გადაამოწმოს შემდეგ.

გაშვების წინ საბოლოო კითხვები

გაშვებამდე ჰკითხეთ საკუთარ თავს: წყარო და გამოყენების უფლება დადასტურებულია? თითოეული მნიშვნელოვანი ველი გასაგებად არის მონიშნული? ძველი ან უცნობი სტატუსი მომხმარებელს არ ატყუებს? მოთხოვნის ფორმა სწორ ლოტს გადასცემს? არსებობს ადამიანი, რომელიც შეცდომას შეამოწმებს? თუ რომელიმე პასუხი არაა, სტატუსი უნდა დარჩეს მზადყოფნის წინა ეტაპზე. ეს არ ნიშნავს პროდუქტის უარყოფას. ნიშნავს, რომ ჯერ კიდევ არის დადასტურების სამუშაო.

დაკავშირებული საკითხები

• Copart, IAAI და Manheim ერთ საიტზე
• კატალოგის ფილტრები
• მონაცემის განახლების წესები
• კატალოგისა და Bid Control-ის დემო

თუ გაქვთ საიტი და გინდათ ჩართვის რეალური მოცულობის შეფასება, მოითხოვეთ დემო.