Публічная рэгістрацыя карысная, калі трэба сабраць даныя ўдзельнікаў ад людзей, якіх яшчэ няма ў спісе, што кіруецца арганізатарам. Але рэгістрацыя і даданне ў спіс гасцей — гэта розныя аперацыйныя этапы. Калі кожная адпраўленая форма адразу лічыцца прынятай, каманда можа страціць магчымасць праверыць адпаведнасць патрабаванням, адрозніць няпоўныя або непадыходныя заяўкі і захоўваць выразны запіс перанесеных даных. QRGATE захоўвае ўзровень Public Registration асобна ад спісу гасцей мерапрыемства: ручны перанос з’яўляецца стандартным, а аўтаматычны даступны толькі для падыходных рэгістрацый, калі арганізатар яго ўключыў.
Аперацыйная праблема: адпраўленая заяўка — гэта яшчэ не прыняты госць
Публічная старонка рэгістрацыі стварае запіс Attendee Registration пасля адпраўкі формы. Госць не ствараецца адразу, і сама рэгістрацыя не дае права ўваходу на мерапрыемства. Гэта важна для канферэнцый, карпаратыўных мерапрыемстваў, кліенцкіх мерапрыемстваў агенцтваў, асацыяцый і пляцовак, дзе арганізатару патрэбны кантраляваны спіс гасцей. Без вызначанага працэсу ўхвалення каманда можа зблытаць статус New з прынятым удзельнікам, палічыць неправераны запіс гатовым да запрашэння або памылкова прыняць рэгістрацыю за дазвол на ўваход.
- Публічная заяўка можа яшчэ патрабаваць праверкі або разгляду арганізатарам.
- Статусы New, Approved, Rejected і Waitlist апісваюць працэс рэгістрацыі, а не аплату, выдачу білета або гарантаваны допуск.
- Перад пераносам у спіс гасцей рэгістрацыя павінна мець задакументаваную падставу для праверкі.
- Даданне рэгістрацыі ў спіс гасцей не адпраўляе запрашэнне аўтаматычна і не завяршае праверку Check-in.
Што адбываецца, калі працэс незразумелы
Для патэнцыйных удзельнікаў незразумелы працэс стварае няўпэўненасць: форма можа выглядаць як пацвярджэнне ўдзелу, хоць арганізатар яшчэ не прыняў чалавека. Інфармацыя таксама можа быць супярэчлівай, калі адзін супрацоўнік лічыць заяўніка госцем, а іншы працягвае весці яго ў табліцы на праверку. Гэта асабліва важна для групавых рэгістрацый: адзін Registration Contact можа дадаць некалькі чалавек, але кожны ўдзельнік усё роўна мае асобны запіс Attendee Registration і ў далейшым асобны жыццёвы цыкл госця.
- Удзельнік можа не ведаць, ці яго заяўка правяраецца, прынятая або змешчана ў Waitlist.
- Камандзе можа быць цяжка аддзяліць даныя рэгістрацыі ад даных госця і наступных адказаў RSVP.
- Капіраванне імёнаў і адказаў у другі спіс павялічвае рызыку дубляў і незразумелай гісторыі пераносу.
- Супрацоўнікі на ўваходзе могуць атрымаць даныя заяўніка да таго, як ён пройдзе стандартны працэс Guest, Invitation, QR Ticket і праверанага Check-in.
Чаму звычайныя ручныя абыходныя рашэнні не заўсёды працуюць
Табліца можа быць карыснай для простай чаргі праверкі, а QRGATE падтрымлівае спісы гасцей, якімі кіруе арганізатар, і падтрыманыя працэсы Excel. Аднак асобная табліца сама па сабе не забяспечвае сувязь паміж Event Registration і створаным госцем. Камандзе даводзіцца ўручную капіраваць імёны, правяраць электронную пошту, адзначаць ухвалу ў адным месцы і абнаўляць спіс гасцей у іншым. Так цяжэй зразумець, хто ўжо перанесены і ці павінна публічнае рэдагаванне заставацца даступным.
- Пазнака «ўхвалена» ў радку сама па сабе не стварае правільны запіс госця для канкрэтнага мерапрыемства.
- Ручное капіраванне можа ўскладніць выяўленне дубляванага пераносу або аднолькавай асобы.
- Статус у табліцы можа не адрозніваць праверку рэгістрацыі ад стану пераносу ў спіс гасцей.
- Змешванне RSVP або плацежнай інфармацыі з ухваленнем размывае розныя аперацыйныя рашэнні.
Як QRGATE падзяляе праверку, ухваленне і перанос у спіс гасцей
Неабавязковы модуль Event Registration у QRGATE дае публічную старонку рэгістрацыі, наладжвальную форму і адміністрацыйны ўзровень рэгістрацый перад спісам гасцей. У Manual-рэжыме, які з’яўляецца стандартным, арганізатар правярае запісы, абнаўляе падтрыманы статус і выбірае падыходных удзельнікаў для пераносу. Дзеянне Add selected to Guest List запускае задакументаваныя серверныя праверкі перад стварэннем запісу Guest.
- Для рэгістрацый даступныя статусы New, Approved, Rejected і Waitlist.
- Спіс рэгістрацый можа паказваць даныя ўдзельніка, Registration Contact, Registered by, стан праверкі, дату і час, бягучы статус, разлічаную цану і стан пераносу ў спіс гасцей.
- Для кожнага ўдзельніка бачны стан пераносу, напрыклад Not added або Added to Guest List.
- QRGATE захоўвае сувязь паміж зыходнай рэгістрацыяй і створаным госцем і не дазваляе перанесці адну рэгістрацыю двойчы.
- Пасля пераносу рэдагаванне публічнай рэгістрацыі блакуецца, а Guest становіцца аперацыйным аб’ектам наступнага этапу.
Падстава праверкі для падыходнай рэгістрацыі
Ухваленне трэба разглядаць разам з адпаведнасцю патрабаванням, а не замест яе. Пры самарэгістрацыі ўдзельнік павінен пацвердзіць уласны адрас электроннай пошты. Калі ўдзельніка дадае Registration Contact у групавой рэгістрацыі, падтрымаймая падстава — правераны Registration Contact, які меў права дадаваць удзельніка. Гэта не азначае, што электронная пошта кожнага ўдзельніка ўжо пацверджана. Пазней удзельнік можа выкарыстаць бяспечны працэс self-claim, каб пацвердзіць свой адрас і ўзяць пад кантроль асабістыя даныя рэгістрацыі да пераносу ў спіс гасцей.
- Self verified азначае, што ўдзельнік пацвердзіў уласны адрас электроннай пошты.
- Verified Registration Contact азначае, што групавая заяўка паступіла ад праверанага і ўпаўнаважанага кантакту.
- Праверка Registration Contact не роўная праверцы асабістай электроннай пошты кожнага ўдзельніка.
- Pending verification павінен выразна адрознівацца ад пацверджанай падставы падчас праверкі арганізатарам.
Як узаемадзейнічаюць модулі QRGATE
Працэс пабудаваны вакол аднаго кантэксту Event. Event Registration збірае і захоўвае заяўку. Запісы Registration Contact і Attendee Registration захоўваюць групавыя і індывідуальныя сувязі. Спіс гасцей атрымлівае толькі тых удзельнікаў, якія адпавядаюць абранай палітыцы пераносу. Пасля пераносу запіс Guest падтрымлівае стандартны жыццёвы цыкл Invitation, неабавязковага RSVP, QR Ticket і праверанага Check-in. Зыходная рэгістрацыя застаецца гістарычнай і рэляцыйнай крыніцай, а Guest становіцца аперацыйным запісам.
- Event і Registration Settings вызначаюць, ці ўключана рэгістрацыя, яе тэрміны, ліміт і рэжым пераносу.
- Registration Form Builder збірае стандартныя палі і падтрыманыя ўласныя пытанні.
- Стан рэгістрацыі і пераносу ў спіс гасцей паказвае, што адбылося з кожным удзельнікам.
- Invitation застаецца асобным працэсам арганізатара пасля пераносу.
- RSVP фіксуе намер удзельнічаць, а Check-in — правераны вынік уваходу на Event.
Практычны працэс ухвалення рэгістрацый на мерапрыемства
Напрыклад, для карпаратыўнай канферэнцыі арганізатар можа апублікаваць брэндаваную старонку рэгістрацыі і збіраць даныя супрацоўнікаў, партнёраў або кліентаў. Наступная паслядоўнасць выразна аддзяляе праверку ад пераносу.
- 1. Уключыце Event Registration для Event і наладзьце даты адкрыцця і закрыцця рэгістрацыі, максімальную колькасць удзельнікаў і, пры неабходнасці, публічны паказ даступнасці.
- 2. Наладзьце Registration Form са стандартнымі палямі і патрэбнымі ўласнымі пытаннямі, напрыклад пра кампанію, ролю або патрабаванні да ўдзелу.
- 3. Атрымлівайце заяўкі на ўзроўні Registration. Яны захоўваюцца да завяршэння праверкі электроннай пошты, таму затрымка ліста не выдаляе запіс.
- 4. Праверце ўдзельніка, Registration Contact, Registered by і стан праверкі. У групавой заяўцы разглядайце кожнага ўдзельніка як асобны запіс.
- 5. Усталюйце статус New, Approved, Rejected або Waitlist. Не прымайце статус за пацвярджэнне аплаты, выдачу білета або дазвол на ўваход.
- 6. У Manual-рэжыме выберыце Approved і падыходных удзельнікаў і націсніце Add selected to Guest List. QRGATE праверыць Event, паўнамоцтвы, статус, падставу праверкі, дублікаты і стан пераносу.
- 7. Пацвердзіце стан Added to Guest List і працягвайце стандартны працэс Guest. Запрашэнні адпраўляюцца асобна; затым пры неабходнасці выкарыстоўваюцца RSVP, QR Ticket і правераны Check-in.
Калі можа падысці аўтаматычны перанос і якія ў яго межы
Ручны перанос дае арганізатару выразны момант для разгляду. QRGATE таксама падтрымлівае рэжым Automatic Guest List transfer, які арганізатар можа ўключыць для падыходных рэгістрацый. У гэтым рэжыме палітыка задаецца загадзя, а сістэма можа перавесці падыходную рэгістрацыю ў Approved і ў спіс гасцей на падставе задакументаванай праверкі. Аўтаматычны рэжым усё роўна пачынаецца з запісу Registration і не дазваляе адвольнай неправеранай публічнай заяўцы адразу стаць Guest.
- Аўтаматычны перанос неабавязковы; Manual застаецца стандартным рэжымам.
- У Automatic-рэжыме таксама дзейнічаюць праверкі адпаведнасці і сервернай цэласнасці.
- Аўтаматычны перанос не адпраўляе запрашэнні.
- Ён не дае права ўваходу, не замяняе праверку QR Ticket і не абыходзіць стандартны Check-in.
- Аўтаматычны Waitlist і аўтаматычныя кампаніі запрашэнняў не з’яўляюцца задакументаванымі магчымасцямі QRGATE.
Аперацыйныя перавагі без празмерных абяцанняў
Кантраляваны працэс ухвалення дапамагае размежаваць адпраўку, праверку, ухваленне і перанос у спіс гасцей. Захаваная сувязь Registration з Guest у QRGATE таксама памяншае неабходнасць аднаўляць, як удзельнік трапіў у працэс Event. Гэтыя перавагі вынікаюць з захавання даных і пераходаў у адным кантэксце Event, але не з’яўляюцца гарантыяй пэўнага працэнтнага паляпшэння і не замяняюць палітыку допуску арганізатара.
- Правяраючыя могуць працаваць са спісам Registration, а не лічыць кожную публічную заяўку госцем.
- Стан пераносу дапамагае знаходзіць удзельнікаў з Not added і тых, хто ўжо мае Added to Guest List.
- Абарона ад паўторнага пераносу дапамагае не ствараць некалькі Guest для адной Registration.
- Спіс гасцей застаецца сумяшчальным з уручную створанымі і імпартаванымі праз падтрыманы Excel запісамі.
- Працэс захоўвае Registration, Invitation, RSVP, QR Ticket і Check-in як асобныя этапы.
Перадумовы і абмежаванні перад запускам
Перад публікацыяй старонкі рэгістрацыі вызначце, ці будзе Event выкарыстоўваць Manual або Automatic transfer, і якая падстава праверкі прымальная для вашых груп удзельнікаў. Праверце тэрміны рэгістрацыі, ліміт удзельнікаў, пытанні формы і інфармацыю арганізатара. Памятайце: цэнаўтварэнне ў Registration носіць інфармацыйны характар. QRGATE можа разлічыць базавую цану з падтрыманыя карэкціроўкамі адказаў або опцый, але не з’яўляецца плацежным працэсарам або публічнай платформай продажу білетаў.
- Registration павінна належаць правільнаму Event і прайсці адпаведныя правілы праверкі і адпаведнасці.
- Ёмістасць вымяраецца колькасцю ўдзельнікаў, а не колькасцю Registration Group.
- QR-код Registration вядзе на Public Registration Page; гэта не QR Ticket і не ўліковыя даныя для ўваходу.
- Пасля пераносу рэдагаванне публічнай Registration блакуецца, таму загадзя ўзгадніце час праверкі і адказных асоб.
- Калі вам патрэбна паводзіна прадукту, якая тут не задакументавана, звярніцеся на support@qrgate.org, а не рабіце здагадкі.
Часта задаваныя пытанні
Ці становіцца кожная публічная рэгістрацыя на мерапрыемства адразу госцем?
Не. Публічная заяўка спачатку захоўваецца як Attendee Registration. У стандартным Manual-рэжыме арганізатар правярае запіс і пераносіць падыходнага ўдзельніка праз Add selected to Guest List. Automatic з’яўляецца неабавязковай палітыкай для падыходных рэгістрацый і не дазваляе бескантрольна ствараць гасцей.
Як працуе ручны перанос у спіс гасцей QRGATE?
Арганізатар правярае запісы Registration, пры неабходнасці абнаўляе іх статусы, выбірае Approved і падыходных удзельнікаў і націскае Add selected to Guest List. QRGATE правярае Event, паўнамоцтвы, статус, падставу праверкі, правілы дубляў і папярэдні стан пераносу перад стварэннем звязанага Guest.
Якія статусы Registration можна выкарыстоўваць да пераносу?
QRGATE дакументуе чатыры статусы: New, Approved, Rejected і Waitlist. Яны падтрымліваюць працэс праверкі Registration і не павінны апісвацца як ухваленне аплаты, выдача білета або гарантаваны допуск.
Што робіць рэгістрацыю падыходнай для пераносу ў спіс гасцей?
Патрэбна задакументаваная падстава праверкі. Пры самарэгістрацыі ўдзельнік пацвярджае ўласную электронную пошту. Калі ўдзельніка дадаў Registration Contact, падставай можа быць правераны і ўпаўнаважаны Registration Contact. Праверка кантакту не пацвярджае аўтаматычна асабістую пошту кожнага ўдзельніка.
Ці можа QRGATE аўтаматычна пераносіць падыходныя рэгістрацыі ў спіс гасцей?
Так, калі арганізатар уключыць Automatic Guest List transfer для Event. Сістэма спачатку стварае Registration і прымяняе правілы праверкі, адпаведнасці, абароны ад дубляў і сервернай цэласнасці. Manual застаецца стандартным рэжымам.
Ці адпраўляецца Invitation аўтаматычна пасля дадання Registration у спіс гасцей?
Не. Перанос стварае Guest і захоўвае сувязь з Registration, але не адпраўляе Invitation аўтаматычна. Арганізатар працягвае асобны працэс Invitation.
Ці дае ўхваленне Registration права ўваходу на Event?
Не. Registration і перанос у спіс гасцей самі па сабе не даюць права ўваходу. Пасля стварэння Guest дзейнічае стандартны працэс Invitation, неабавязковага RSVP, QR Ticket і праверанага Check-in. QR-код Registration вядзе на старонку рэгістрацыі, а не служыць для ўваходу.
Што адбываецца з Registration пасля дадання ўдзельніка ў спіс гасцей?
Registration захоўваецца як гістарычная і рэляцыйная крыніца. QRGATE запісвае сувязь з Guest і стан пераносу, паказвае Added to Guest List і блакуе публічнае рэдагаванне Registration. Guest становіцца аперацыйным запісам для наступных Invitation, RSVP, QR Ticket і Check-in.
Стварыце кантраляваны працэс ухвалення рэгістрацый
Захоўвайце публічныя заяўкі асобна ад прынятага спісу гасцей, выразна правярайце адпаведнасць і пераносіце ўхваленых удзельнікаў у працэс Event праз асобны крок. Стварыце ўліковы запіс QRGATE і пратэстуйце дэма для наступнага Event.
Стварыць уліковы запіс і пратэставаць дэма QRGATE