Հոդվածի ֆոկուսը
Վճարման հարցումը պետք է իմանա շրջագայության համատեքստը
Առանց ամսաթվի, երթուղու, մասնակիցների թվի և կառավարչի տեղեկանքի գումարը չի օգնում փոխանցման կամ չեղարկման հարցում:
Շրջագայությունները, էքսկուրսիաները, փոխանցումները և ճանապարհորդական ծառայությունները հաճախ վաճառվում են մենեջերի, ձևաթղթի, մեսենջերի կամ CRM-ի միջոցով: Վճարման հղումը չպետք է լինի գումարի առանձին հղում, այլ վճարման օբյեկտ՝ շրջագայության ամսաթվով, երթուղու/փաթեթի ID-ով, մասնակիցների քանակով, հաճախորդի գրառումով, գումարով, արժույթով և ժամկետի ավարտով:
Հաստատված վճարումից հետո CRM-ը կարող է նշել ավանդի վճարված, լրիվ վճարված կամ ձեռքով վերանայում: Սակայն վերջնական կարգավիճակը չի կարող սահմանվել URL վերադարձով կամ սքրինշոթով, քանի որ վճարման մատակարարը կարող է վերջնական կարգավիճակը ուղարկել ավելի ուշ:
- համակցված վճարման հարցումը տուրերի ամրագրման ID-ի հետ.
- գրանցել շրջագայության ամսաթիվը, փաթեթի ID-ն և մասնակիցների թիվը.
- խանութի մենեջերի հղում և աղբյուրի ալիք;
- առանձին վճարված ավանդ, ամբողջությամբ վճարված, չեղարկված և ձեռքով վերանայում:
Խմբային ամրագրումը և մասնակի վճարումները պահանջում են ժամանակացույց
Խումբը կարող է վճարել ավանդ, մնացորդ, հավելավճար մասնակցի համար կամ մասնակի վերադարձ, ուստի միայն վճարովի կարգավիճակը բավարար չէ:
Ճամփորդության սցենարներում հաճախ կա կանխավճար, գումարի մնացորդ մինչև տուրի ամսաթիվը, մասնակիցների ավելացում, անհատական զեղչեր և մասնակի չեղարկում: Եթե այս ամենը պահվում է որպես մեկ պատվեր, թիմը չի տեսնում, թե ով որքան է վճարել և ինչ է պետք պահանջել:
Ժամանակացույցը պետք է պահպանի ակնկալվող գումարը, վճարված գումարը, ժամկետը, վճարման փորձերը, հիշեցումները և կառավարչի առաջադրանքները: Եթե մատակարարը չի աջակցում ավտոմատ լիցքավորումը, կարիք չկա խոստանալ ավտոմատ լիցքավորում. payment links և վերահսկվող հիշեցումները սովորաբար ավելի անվտանգ են սկսելու համար:
- առանձին ավանդի գումարը և մնացորդը.
- մի ստեղծեք մի քանի ակտիվ հղումներ մեկ վճարման ժամանակահատվածի համար.
- Մասնակից ավելացնելը պետք է ստեղծի ճշգրտման իրադարձություն.
- ձեռքով զեղչը/փոխհատուցումը պետք է ունենա դերակատար և պատճառ:
Չեղարկումը, եղանակը և գումարի վերադարձը պետք է լինեն իրադարձություններ
Եղանակի պատճառով շրջագայությունների տեղափոխումը, մասնակիցների չեղարկումները և գումարի վերադարձը չպետք է ջնջեն վճարումների սկզբնական պատմությունը:
Շրջագայությունները տարբերվում են ըստ ամսաթվի, խմբի, տրանսպորտի, եղանակի և մատակարարների: Փոխանցումը կամ չեղարկումը չպետք է ջնջի վճարումը. նրանք պետք է ստեղծեն առանձին իրադարձություններ՝ պատճառաբանությամբ, դերակատարով, ամսաթվով և գումարի վերադարձման ճանապարհով: Սա կարևոր է աջակցության, հաշվապահական հաշվառման և վեճերի գործարքների համար:
Ամենօրյա հաշտեցումը համեմատում է շրջագայությունների ամրագրումները, ստուգված վճարումները, չվճարված մնացորդները, չեղարկումները, փոխհատուցումները, CRM առաջադրանքները և մատակարարի հաշվետվությունը: Այսպիսով, կառավարիչը տեսնում է, թե որ խմբերն են պատրաստ, որտեղ է անհրաժեշտ հիշեցում և որ գործողությունները պահանջում են ձեռքով վերանայում:
- վերադարձը չպետք է ջնջի բնօրինակ վճարումը.
- Էքսկուրսիա տեղափոխելու համար պահանջվում է հին ամսաթիվ, նոր ամսաթիվ և պատճառ.
- եղանակի չեղարկումը պահվում է որպես առանձին բիզնես իրադարձություն.
- ստուգեք CRM, մատակարարի հաշվետվությունը և հաշվապահական հաշվառման արտահանումը:
FAQ
Հնարավո՞ր է կանխավճար ընդունել payment link շրջագայության համար:
Այո, եթե հղումը կապված է շրջագայության ամրագրման ID-ի, ամսաթվի, մասնակիցների թվի, գումարի և վավերականության ժամկետի հետ, և վճարովի կարգավիճակը տեղադրվում է սերվերի կողմից ստուգումից հետո:
Ինչպե՞ս հաշվի առնել շրջագայությունից առաջ գումարի մնացորդը:
Պահպանեք ժամանակացույցը. ակնկալվող գումարը, վճարված գումարը, ժամկետը, հիշեցումները և ավանդի և մնացորդի համար վճարման առանձին փորձեր:
Ի՞նչ անել, եթե շրջագայությունը հետաձգվի:
Պահպանեք սկզբնական վճարումը և ստեղծեք փոխանցման իրադարձություն հին ամսաթվով, նոր ամսաթվով, պատճառաբանությամբ և դերակատարով: Վճարումների պատմությունը չպետք է անհետանա: