სამედიცინო კონფერენციის რეგისტრაციის პროგრამის ჩეკლისტის გამოყენებისას მხოლოდ იმის შემოწმება საკმარისი არ არის, შეუძლია თუ არა პლატფორმას სახელისა და ელფოსტის შეგროვება. თქვენს გუნდს შეიძლება დასჭირდეს ბრენდირებული Public Registration Page, სტრუქტურირებული კითხვები, ტევადობის კონტროლი, ვერიფიკაცია, დამტკიცება, ჯგუფური რეგისტრაციისას ინდივიდუალური ჩანაწერები და მკაფიო გზა Registration-იდან Invitation-მდე, QR Ticket-მდე და Check-in-მდე.
გამოიყენეთ ქვემოთ მოცემული ცხრა კრიტერიუმი პლატფორმების შედარებისას. თითოეულ კრიტერიუმში მოცემულია დემოს დროს დასასმელი პრაქტიკული კითხვა და ზღვარი, რომელიც შეძენამდე უნდა გადაამოწმოთ. მიზანია ერთმანეთისგან განასხვავოთ შენახული Registration submission და მიღებული Event Guest, ასევე QR კოდი და ვალიდირებული შესვლის ჩანაწერი.
ჩეკლისტამდე: განსაზღვრეთ ოპერაციული პრობლემა
სამედიცინო კონფერენციის გუნდი ხშირად იწყებს მარტივი მოთხოვნით: მონაწილეთა მონაცემების ონლაინ შეგროვება. სირთულე მოგვიანებით ჩნდება. ფორმის submission შეიძლება მიღებულ მონაწილედ ჩაითვალოს, რამდენიმე ადამიანი ერთ საკონტაქტო პირზე იყოს მიბმული, ტევადობა ჯგუფებად დაითვალოს, ხოლო მორგებული პასუხები შენიშვნებში ან ერთმანეთთან დაუკავშირებელ ცხრილებში აღმოჩნდეს. ასეთი მიდგომა სტუმრებისა და ორგანიზატორებისთვის გაურკვევლობას ქმნის. მონაწილემ შეიძლება არ იცოდეს, ადასტურებს თუ არა ფორმის გაგზავნა მის მონაწილეობას. ორგანიზატორმა კი შეიძლება ვერ დაინახოს, ვინ არის ვერიფიცირებული, დამტკიცებული, Guest List-ში გადატანილი ან Invitation-ისა და Check-in-ისთვის მზად. ცხრილები დროებით შეიძლება დაგეხმაროთ, თუმცა ხშირად მოითხოვს მონაცემების განმეორებით გადაკოპირებას, დუბლიკატების შემოწმებასა და ცალკე შეჯერებას. უკეთესი შეფასება იწყება workflow-ის მდგომარეობებითა და მათი კონტროლირებადი გადასვლებით.
- დააზუსტეთ, სად ინახება Public submission, სანამ ის მიღებულ Event Guest-ად იქცევა.
- მოთხოვნებში ცალ-ცალკე გამოყავით Registration, Guest List, Invitation, RSVP, QR Ticket და Check-in.
- შეამოწმეთ როგორც ინდივიდუალური რეგისტრაცია, ისე ერთი საკონტაქტო პირის მიერ რამდენიმე მონაწილის რეგისტრაცია.
- დაადასტურეთ, რომელი სამედიცინო კონფერენციის მოთხოვნებია რეალურად მხარდაჭერილი და რომელი საჭიროებს სხვა სისტემას ან ცალკე პროცესს.
1. შეამოწმეთ მონაცემების მიღების მოდელი და Public Registration Page
პირველი კრიტერიუმია, გთავაზობთ თუ არა პლატფორმა შესაბამის საჯარო intake ფენას ისე, რომ intake არ აირიოს დაშვებაში. მოძებნეთ Event-ზე მიბმული, responsive სარეგისტრაციო გვერდი, რომელსაც შეუძლია აჩვენოს Event-ის სახელი, ბრენდინგი, თარიღი და დრო, ორგანიზატორის მიერ განსაზღვრული ინფორმაცია და თავად ფორმა. იკითხეთ, შესაძლებელია თუ არა გვერდის გაზიარება Public URL-ით, ჩამოსატვირთი Registration QR code-ით ან ვებსაიტის registration button-ით. ასევე შეამოწმეთ, რა ხდება Registration-ის გამორთვისას ან გახსნისა და დახურვის პერიოდს მიღმა. მკაფიო unavailable მდგომარეობა სჯობს ბმულის გაურკვეველ შეცდომას. QRGATE-ის არჩევითი Event Registration module გთავაზობთ ბრენდირებულ Public Registration Page-ს. Public Registration URL-ის გაზიარება შესაძლებელია პირდაპირ, Registration QR code-ით ან ჩვეულებრივი HTML link/button-ით. Submission თავდაპირველად ინახება Registration ჩანაწერად და ავტომატურად არ ხდება მიღებული Guest ან შესვლის უფლება.
- შეუძლია თუ არა გვერდს ორგანიზატორის ინსტრუქციებისა და პრაქტიკული დეტალების ჩვენება?
- შეუძლია თუ არა ორგანიზატორს Registration opens და Registration closes პარამეტრების დაყენება?
- გამიჯნულია თუ არა Public Registration ticket sales-ისა და payment processing-ისგან?
- რა სტატუსში გადადის submission ფორმის გაგზავნისთანავე?
2. შეაფასეთ Registration Form და მორგებული კითხვები
სამედიცინო კონფერენციის სარეგისტრაციო ფორმას შეიძლება სტანდარტულ საიდენტიფიკაციო ველებზე მეტი დასჭირდეს. შეადარეთ ველების ტიპები, სავალდებულო/არასავალდებულო პარამეტრები, დამხმარე ტექსტი, ჩვენების რიგი და პასუხების შენახვის წესი. მთავარი კითხვა მხოლოდ ის არ არის, აჩვენებს თუ არა პლატფორმა კითხვას, არამედ ისიც, რჩება თუ არა პასუხი სტრუქტურირებული და დაკავშირებული კონკრეტული მონაწილის ჩანაწერთან. დემოზე გამოცადეთ სახელი, ელფოსტა, ტელეფონი, კომპანია, პოზიცია და კომენტარი, შემდეგ კი მორგებული კითხვები: მოკლე ტექსტი, გრძელი ტექსტი, კი/არა, ერთი არჩევანი, რამდენიმე არჩევანი და checkbox. იკითხეთ, როგორ ინიშნება კითხვა active, enabled, required ან optional მდგომარეობაში და როგორ ჩანს პასუხები ექსპორტში. QRGATE-ის Form Builder მხარს უჭერს აღნიშნულ კითხვებისა და ველების ტიპებს. მორგებული პასუხები ინახება სტრუქტურირებულ Registration მონაცემებად და შეიძლება გამოჩნდეს attendee-level სვეტებად დინამიკურ Registration Excel export-ში. ეს ამცირებს თავისუფალ ტექსტურ შენიშვნებზე დამოკიდებულებას, თუმცა არ ადასტურებს სამედიცინო აკრედიტაციას ან სხვა სამედიცინო პროგრამულ შესაძლებლობებს, რომლებიც დოკუმენტირებული არ არის.
- შეიძლება თუ არა კითხვების სავალდებულოდ ან არასავალდებულოდ მონიშვნა?
- ინახება თუ არა არჩევანის ვარიანტები თანმიმდევრულად შემდგომი განხილვისა და ექსპორტისთვის?
- შეუძლია თუ არა ფორმას არასავალდებულო billing information-ის შეგროვება payment processing-ის დაპირების გარეშე?
- მხარდაჭერილია თუ არა სამედიცინო აკრედიტაცია, CME/CPD, სერტიფიკატები ან აბსტრაქტები? თუ ეს დოკუმენტირებული არ არის, მიმართეთ support@qrgate.org-ს.
3. გადაამოწმეთ, როგორ ითვლება მონაწილეთა ტევადობა
ტევადობა ხშირად იწვევს შეცდომაში შემყვან შედარებებს. პლატფორმა შეიძლება აჩვენებდეს რეგისტრაციების რაოდენობას ისე, რომ არ განმარტავდეს, ითვლის ფორმებს, კონტაქტებს, ჯგუფებს თუ ინდივიდუალურ მონაწილეებს. კონფერენციისთვის ეს განსხვავება მნიშვნელოვანია, როდესაც ერთი კოორდინატორი რამდენიმე კოლეგას არეგისტრირებს. სთხოვეთ მომწოდებელს, აჩვენოს, მაგალითად, 300 მონაწილის ტევადობა და ხუთი ადამიანის შემცველი submission. მთავარი კითხვაა: იკავებს თუ არა ეს submission ხუთ ადგილს, თუ ერთს. ასევე შეამოწმეთ, რომელი Registration status მოიხმარს ჩვეულებრივ ტევადობას, რა ხდება ლიმიტის მიღწევისას და არის თუ არა public availability არჩევითი. QRGATE ტევადობას attendee-ის მიხედვით ითვლის და არა Registration Group-ის მიხედვით. დოკუმენტირებული მოდელით, New და Approved attendees ჩვეულებრივ ტევადობას იყენებენ, ხოლო Rejected და Waitlist — არა. ორგანიზატორს შეუძლია დააყენოს მაქსიმალური attendee capacity და სურვილის შემთხვევაში აჩვენოს ხელმისაწვდომობა Public Registration Page-ზე. საბოლოო შემოწმება backend-ზე სრულდება, მათ შორის დარჩენილი ადგილებისთვის კონკურენტული submission-ების დროსაც.
- იზომება ტევადობა მონაწილეებით თუ Registration submission-ებით?
- შესაძლებელია თუ არა ჯგუფური submission-ის ტესტირება ლიმიტთან მიმართებით?
- რომელი სტატუსები ითვლება ჩვეულებრივ ტევადობაში?
- შესაძლებელია თუ არა availability-ის დამალვა ტევადობის კონტროლის შენარჩუნებით?
- არ ივარაუდოთ ავტომატური waitlisting, თუ ის ცალსახად დოკუმენტირებული არ არის.
4. შეამოწმეთ ვერიფიკაცია და eligibility წესები
გაგზავნილი ფორმა ავტომატურად ვერიფიცირებული ან eligible მონაწილე არ არის. ჩეკლისტში ერთმანეთისგან უნდა გაიმიჯნოს submission-ის შენახვა, შესაბამისი ელფოსტის მფლობელობის დადასტურება და პირის Guest List-ში დამტკიცება ან გადატანა. იკითხეთ, რა verification basis-ს აფიქსირებს სისტემა და საჭიროა თუ არა ვერიფიკაცია Registration-ის წინსვლისთვის. გამოცადეთ დაგვიანებული ან მიუწოდებელი verification email-იც. workflow-მა შენახული submission არ უნდა დაკარგოს მხოლოდ იმიტომ, რომ წერილი მოგვიანებით მოვიდა ან spam-ში აღმოჩნდა. QRGATE იყენებს save-first, verify-second მოდელს: Registration ინახება submission-ისას, ხოლო secure verification ან management access ცალკე მუშავდება. Self-registration-ისას მონაწილეს საკუთარი ელფოსტის ვერიფიკაცია შეუძლია. Group submission-ისას verified Registration Contact-ს შეუძლია მის მიერ დამატებული მონაწილეებისთვის დოკუმენტირებული verification basis-ის შექმნა. ეს არ ნიშნავს, რომ ყველა მონაწილის საკუთარი ელფოსტა verified არის. მონაწილეს მოგვიანებით შეუძლია secure self-claim პროცესით საკუთარი მისამართის დადასტურება და პირადი Registration მონაცემების მართვა.
- ჩანს თუ არა verification state ორგანიზატორისთვის?
- არჩევს თუ არა პლატფორმა Self verified, Verified Registration Contact და Pending verification მდგომარეობებს?
- verification resend ქმნის თუ არა დუბლირებულ Registration-ს?
- შეუძლია თუ არა მონაწილეს Registration Contact-ის მიერ შექმნილი ჩანაწერის claim?
- არ ჩათვალოთ contact verification ყველა მონაწილის ელფოსტის დადასტურებად.
5. გამოცადეთ რამდენიმე მონაწილის რეგისტრაცია და ინდივიდუალური ჩანაწერები
კორპორაციულ სამედიცინო გუნდებს, სააგენტოებსა და ასოციაციებს შეიძლება დასჭირდეთ, რომ ერთმა საკონტაქტო პირმა რამდენიმე ადამიანი დაარეგისტრიროს. პლატფორმამ ჯგუფური კავშირი უნდა შეინარჩუნოს ისე, რომ ყველა პირი ერთ ჩანაწერად არ გააერთიანოს. სთხოვეთ მომწოდებელს, აჩვენოს Registration Contact-ის მიერ სამი ან ხუთი მონაწილის დამატება. შეამოწმეთ, აქვს თუ არა თითოეულ პირს საკუთარი Registration record, პასუხები, სტატუსი, price snapshot და conversion state. შემდეგ დაადასტურეთ, რომ თითოეული პირი შეიძლება ცალკე Guest-ად იქცეს საკუთარი Invitation-ით, RSVP-ით, QR Ticket-ითა და Check-in ისტორიით. QRGATE მხარს უჭერს Registration Contact workflow-ს რამდენიმე მონაწილისთვის. თითოეული attendee ცალკე Attendee Registration record-ად რჩება, მაშინაც კი, როდესაც ჯგუფს ერთი verified contact მართავს. პირს მოგვიანებით შეუძლია secure link-ით საკუთარი Registration-ის self-claim. Self-claim-ის შემდეგ Registration Contact ვერ ცვლის მონაწილის პირად Registration მონაცემებს, დოკუმენტირებული workflow-ის ფარგლებში.
- შეუძლია თუ არა ერთ verified contact-ს რამდენიმე მონაწილის რეგისტრაცია?
- იღებს თუ არა თითოეული attendee ცალკე ჩანაწერსა და სტატუსს?
- ინახება თუ არა მორგებული პასუხები თითოეული მონაწილის დონეზე და არა მხოლოდ ჯგუფის დონეზე?
- შეიძლება თუ არა თითოეულ გადატანილ attendee-ს ჰქონდეს ცალკე Guest, Invitation, QR Ticket და Check-in ისტორია?
- როგორ იცავს სისტემა ერთ Event-ში მონაწილის ელფოსტის დუბლირებას?
6. შეაფასეთ approval და Registration-to-Guest transfer
ერთ-ერთი ყველაზე მნიშვნელოვანი საკითხია, რა ხდება Registration-სა და Guest List-ში მოხვედრას შორის. Public submission ავტომატურად არ უნდა აღიწეროს მიღებულ Guest-ად, თუ პლატფორმის წესები ამ გადასვლას ცალსახად არ ითვალისწინებს. ყურადღებით შეადარეთ Manual და Automatic transfer. Manual workflow-ში ორგანიზატორი ამოწმებს eligible Registration-ებს, საჭიროების შემთხვევაში ცვლის სტატუსს და კონტროლირებული მოქმედებით არჩეულ attendees-ს Guest List-ში ამატებს. Automatic workflow-ს შეუძლია რუტინული ადმინისტრირება შეამციროს, თუმცა მანაც უნდა გამოიყენოს verification, eligibility, capacity, uniqueness და authorization წესები. QRGATE-ში Manual Guest List transfer ნაგულისხმევია. ორგანიზატორს შეუძლია eligible Registration records-ის გადახედვა და Add selected to Guest List მოქმედების გამოყენება. Automatic Guest List transfer შეიძლება ჩაირთოს თითოეული Event-ისთვის, eligible Registration-ებზე, თუმცა ის შემთხვევით Public submission-ებს უკონტროლოდ Guests-ად არ აქცევს. Transfer ინარჩუნებს Registration-to-Guest კავშირს, ხელს უშლის განმეორებით conversion-ს და Guest-ის შექმნის შემდეგ კეტავს Public Registration-ის რედაქტირებას. Transfer თავისთავად Invitation-ს არ აგზავნის.
- რა ხდის Registration-ს transfer-ისთვის eligible-ს?
- შეუძლია თუ არა ორგანიზატორს ჩანაწერების ხელით გადახედვა და არჩევა?
- შეიძლება თუ არა Automatic transfer-ის ჩართვა თითოეული Event-ისთვის?
- ინარჩუნებს თუ არა პლატფორმა conversion state-სა და timestamp-ს?
- აგზავნის თუ არა transfer ავტომატურად Invitation-ს? QRGATE-ში — არა.
7. გადახედეთ სტატუსებს, ექსპორტსა და ოპერაციულ გადაბარებას
სარეგისტრაციო პროგრამამ გუნდს უნდა მისცეს გამოსაყენებელი ოპერაციული ხედვა transfer-მდე და მის შემდეგ. მოძებნეთ Registration status, verification state, Registration Contact, Registered by, calculated price, capacity-related state და Guest List conversion state. ექსპორტი განსაკუთრებით მნიშვნელოვანია, როდესაც სხვადასხვა გუნდი ამოწმებს სარეგისტრაციო ინფორმაციას, ამზადებს კომუნიკაციას ან მუშაობს დამტკიცებულ სიებზე. გამოცადეთ, არის თუ არა ექსპორტი attendee-level და გადაიქცევა თუ არა მორგებული კითხვების პასუხები გამოსაყენებელ სვეტებად და არა ერთ დამალულ notes ველად. QRGATE მხარს უჭერს New, Approved, Rejected და Waitlist Registration სტატუსებს, ასევე verification და Guest List conversion state-ს. დინამიკურ Registration Excel export-ში შეიძლება შევიდეს attendee-ისა და ადმინისტრირების სტანდარტული მონაცემები, კონფიგურირებული calculated price, მხარდაჭერილი billing information და მორგებული კითხვების პასუხები. ეს განსხვავდება Guest List export-ისგან და არ უნდა აღიქმებოდეს ზოგად analytics ან CRM შესაძლებლობად.
- ხედავს თუ არა გუნდი, რომელი attendees არიან Not added ან Added to Guest List?
- ინარჩუნებს თუ არა ექსპორტი Registration Contact-სა და ჯგუფურ კავშირს?
- არის თუ არა მორგებული პასუხები ცალკე, ადვილად წასაკითხ სვეტებში?
- გამიჯნულია თუ არა Registration export Guest List export-ისგან?
- რომელი დამატებითი ანგარიშები ან ინტეგრაციებია საჭირო და დოკუმენტირებულია თუ არა ისინი?
8. მიჰყევით სრულ გზას Invitation-მდე და RSVP-მდე
Registration პროგრამა უნდა შეფასდეს იმის მიხედვითაც, რა ხდება მიღების შემდეგ. Registration აფიქსირებს ინტერესსა და ინფორმაციას; ის RSVP არ არის. მას შემდეგ, რაც attendee Guest ხდება, გუნდს შეიძლება დასჭირდეს პერსონალიზებული Invitation-ის გაგზავნა და მონაწილეობის პასუხის მიღება. QRGATE Registration გზას Guest-ის ჩვეულებრივ lifecycle-ს უკავშირებს: Guest, Invitation, არჩევითი RSVP, QR Ticket და Check-in. Invitations არის Event-სა და Guest-ზე მორგებული email კომუნიკაცია და შეიძლება შეიცავდეს Event ინფორმაციას, Guest ინფორმაციას, QR Ticket access-ს, calendar access-სა და RSVP interaction-ს, თუ ის ჩართულია. RSVP მდგომარეობები განასხვავებს Pending / No response yet, Attending და Not attending პასუხებს. ეს გამიჯვნა კონფერენციის workflow-ში მნიშვნელოვანია. მიღებულ Registration-ს შეიძლება ჯერ არ ჰქონდეს RSVP პასუხი, Attending RSVP-ს — დაფიქსირებული მისვლა, ხოლო QR Ticket-ს — ჯერ კიდევ სჭირდებოდეს Check-in validation. არ აირჩიოთ პლატფორმა, რომელიც ამ მდგომარეობებს ერთმანეთში ურევს, თუ თქვენს ოპერაციულ გუნდს ფაქტობრივი მდგომარეობების ცოდნა სჭირდება.
- არჩევს თუ არა პლატფორმა Registration-სა და RSVP-ს?
- ხედავს თუ არა ორგანიზატორი Pending, Attending და Not attending სტატუსებს?
- ქმნის თუ არა Guest List transfer ავტომატურად Invitation-ს?
- რჩება თუ არა Registration-ის ისტორია დაკავშირებული მიღებულ Guest-თან?
- დოკუმენტირებულია თუ არა email delivery channels და reminder ფუნქციები?
9. დაადასტურეთ QR Ticket-ისა და Check-in-ის ქცევა
საბოლოო workflow კრიტერიუმია განსხვავება მონაწილის იდენტიფიცირებასა და მიღებული Event შესვლის დაფიქსირებას შორის. მხოლოდ QR სურათი არ ამტკიცებს, რომ პირს შესვლის უფლება აქვს. სთხოვეთ მომწოდებელს აჩვენოს მიღებული scan, უარყოფილი scan და მოქმედი single ან multiple entry წესები. QRGATE-ში Guest იღებს უნიკალურ QR Ticket-ს Guest workflow-ის ფარგლებში. QR Ticket განსაზღვრავს Event-ისა და Guest/Ticket-ის კონტექსტს, ხოლო Check-in შესვლის მიღებამდე ან უარყოფამდე იყენებს Event-ის ბიზნეს-წესებს. წარმატებული Check-in აფიქსირებს Event-ზე შესვლას. პროცესის დაწყება შეუძლია უფლებამოსილ Entry Staff-ს ან მხარდაჭერილ Self Check-in workflow-ს. ოპერაციული დაგეგმვისას იკითხეთ, აჩვენებს თუ არა სისტემა checked-in და not-yet-checked-in Guests-ს, Check-in-ის დროს ან რეალურ დროში შესვლის ხედვას. QRGATE ასევე დოკუმენტირებს მხარდაჭერილი Check-in ოპერაციების Offline მხარდაჭერას და შემდგომ სინქრონიზაციას. ეს არ ნიშნავს, რომ QRGATE-ის ყველა module offline მუშაობს.
- გამიჯნულია თუ არა Registration QR code Guest QR Ticket-ისგან?
- ანიჭებს თუ არა scan თავისთავად შესვლის უფლებას, თუ სისტემა ბიზნეს-წესებს ამოწმებს?
- შეუძლია თუ არა Entry Staff-ს Check-in-ის დაწყება? ხელმისაწვდომია თუ არა საჭიროების შემთხვევაში Self Check-in?
- აფიქსირებს თუ არა პლატფორმა მიღებულ და უარყოფილ Check-in შედეგებს?
- კავშირის დაკარგვისას რომელი კონკრეტული Check-in ოპერაციები გრძელდება Offline რეჟიმში?
ხშირად დასმული კითხვები
რას უნდა მოიცავდეს სამედიცინო კონფერენციის რეგისტრაციის პროგრამის ჩეკლისტი?
შეაფასეთ სრული workflow: ბრენდირებული Public Registration Page, კონფიგურირებადი კითხვები, attendee-ზე დაფუძნებული ტევადობა, ელფოსტის ვერიფიკაცია, რამდენიმე მონაწილის რეგისტრაცია, approval ან კონტროლირებული Guest List transfer, attendee-level export, Invitations, RSVP, QR Tickets და ვალიდირებული Check-in. ცალკე მიუთითეთ სამედიცინო მოთხოვნები, რომელთა მხარდაჭერაც დამატებით უნდა გადამოწმდეს.
უნდა გახდეს თუ არა საჯარო კონფერენციის Registration submission ავტომატურად Guest?
აუცილებლად არა. Registration და Guest ცალკე ოპერაციული მდგომარეობებია. QRGATE-ში Public submission თავდაპირველად Registration-ად ინახება. ის Guest List-ში შეიძლება გადავიდეს Manual transfer-ით ან ორგანიზატორის მიერ ჩართული Automatic transfer-ით მხოლოდ მაშინ, როდესაც დოკუმენტირებული eligibility და verification წესები სრულდება.
როგორ უნდა დაითვალოს მონაწილეთა ტევადობა, როდესაც ერთი contact რამდენიმე ადამიანს არეგისტრირებს?
თუ თითოეულ პირს ცალკე ადგილი სჭირდება, ტევადობა უნდა შემოწმდეს ინდივიდუალური attendee-ის მიხედვით და არა Registration Group-ის მიხედვით. QRGATE-ში ხუთი მონაწილის რეგისტრაცია ხუთ ადგილს იყენებს. New და Approved attendees ითვლებიან ჩვეულებრივ ტევადობაში, Rejected და Waitlist — არა.
შეუძლია თუ არა ერთ Registration Contact-ს რამდენიმე მონაწილის რეგისტრაცია ინდივიდუალური ჩანაწერების შენარჩუნებით?
დიახ. QRGATE მხარს უჭერს verified Registration Contact-ს, რომელიც ერთ Event-ში რამდენიმე Attendee Registration record-ს მართავს. თითოეული attendee ცალკე რჩება და მოგვიანებით შეიძლება ჰქონდეს ინდივიდუალური Guest, Invitation, RSVP, QR Ticket და Check-in ისტორია. მონაწილეს ასევე შეუძლია საკუთარი Registration-ის self-claim ელფოსტის ვერიფიკაციით.
რა განსხვავებაა Registration-ს, RSVP-ს, QR Ticket-სა და Check-in-ს შორის?
Registration არის intake და eligibility ფენა Guest List-მდე. RSVP აფიქსირებს Guest-ის მონაწილეობის განზრახვას. QR Ticket Event-ის კონტექსტში Guest/Ticket-ის იდენტიფიცირებას ახდენს. Check-in შესვლის მიღებამდე ან უარყოფამდე Event-ის ბიზნეს-წესებს იყენებს. წარმატებული Check-in მიღებულ Event შესვლას აფიქსირებს. ეს მდგომარეობები ავტომატურად ერთმანეთის სინონიმები არ არის.
როგორ უჭერს QRGATE მხარს მორგებულ სარეგისტრაციო კითხვებსა და Registration Excel export-ს?
QRGATE-ის Registration Form Builder მხარს უჭერს Short text, Long text, Yes/No, Single choice, Multiple choice და Checkbox კითხვებს. შესაძლებელია Required სტატუსის, help text-ის, active state-ისა და sort order-ის კონფიგურაცია. მორგებული პასუხები შეიძლება გამოჩნდეს დინამიკურ Registration Excel export-ში attendee-level სვეტებად.
ამუშავებს თუ არა QRGATE სამედიცინო კონფერენციის რეგისტრაციის გადახდებს?
არა. QRGATE-ს შეუძლია ინფორმაციული registration pricing-ის გამოთვლა და ჩვენება base price-ისა და დოკუმენტირებული პასუხის ან option adjustment-ის მიხედვით. მას ასევე შეუძლია კონფიგურაციისას billing information-ის შეგროვება და ორგანიზატორის მიერ განსაზღვრული გარე ინსტრუქციების ჩვენება. QRGATE არ არის payment processor, ticket marketplace ან public ticket sales platform.
რა განსხვავებაა Manual და Automatic Guest List transfer-ს შორის?
Manual transfer QRGATE-ის ნაგულისხმევი რეჟიმია: ორგანიზატორი ამოწმებს eligible Registration-ებს და იყენებს Add selected to Guest List მოქმედებას. Automatic transfer შეიძლება ჩაირთოს თითოეული Event-ისთვის eligible Registration-ებზე და კვლავ იყენებს verification, eligibility, uniqueness და conversion წესებს. არც ერთი რეჟიმი ავტომატურად არ აგზავნის Invitation-ს და თავისთავად არ ანიჭებს შესვლის უფლებას. სამედიცინო აკრედიტაცია, CME/CPD tracking, სერტიფიკატები, აბსტრაქტების მართვა და მსგავსი შესაძლებლობები მიწოდებულ Product Brain-ში დოკუმენტირებული არ არის; პასუხგაუცემელ კითხვებზე მიმართეთ support@qrgate.org-ს.
შეაფასეთ workflow QRGATE-ის დემოთი
თუ თქვენს გუნდს სჭირდება კონტროლირებული attendee intake, რომელიც დაკავშირებულია Guest List transfer-თან, Invitations-თან, QR Tickets-თან და ვალიდირებულ Check-in-თან, შექმენით ანგარიში და სცადეთ QRGATE-ის დემო. ამ ჩეკლისტში არმოცემული მოთხოვნებისთვის — მაგალითად, სამედიცინო აკრედიტაციის ან CME/CPD workflow-ისთვის — ვარაუდის ნაცვლად მიმართეთ support@qrgate.org-ს.
შექმენით ანგარიში და სცადეთ დემო