Русский
Українська
ქართული
English
Қазақша
Español
Français
Deutsch
Italiano
فارسی
Հոդվածի ֆոկուսը
Սկզբնական խնդիր. չկորցնել հայտի համատեքստը վճարումից հետո
Ծառայությունը սկսվում է Tilda ձևից, սակայն վճարումը և հետագա աշխատանքը պետք է մնան մի CRM deal-ի հետ կապված:
Տիպիկ ծառայության սցենարում մենեջերը Tilda-ից հայտ է ստանում, համաձայնեցնում է ծառայությունը և ուղարկում կանխավճարի հղում: Եթե հղումը ստեղծվում է ձեռքով առանց CRM id-ի, կորում է վճարման, ծառայության և պատասխանատուի կապը:
Այս քեյսում CRM-ը ստեղծում է payment request deal id-ով, ծառայությամբ, գումարով, արժույթով և ժամկետով: Հաճախորդը հղում է ստանում միայն այդ տվյալները ֆիքսելուց հետո:
- CRM deal id-ն պահել payment metadata-ում:
- Նոր հարցման տարբերակի բացակայությամբ գումարը չփոխել:
- Սահմանել ժամկետ և հասկանալի վճարման նպատակ:
- Payment record-ում պահել միայն անհրաժեշտ անձնական տվյալները:
Լուծումը. CRM-ը փուլը փոխում է միայն ստուգված իրադարձությունից հետո
Գործարքի կարգավիճակը կախված չէ սքրինշոթից կամ success page-ի սեղմումից. այն փոխում է backend-ը ստուգված վճարումից հետո:
Webhook կամ server-side status check-ը հասնում է backend, որը ստուգում է նույնացուցիչները, գումարը, արժույթը և ստորագրությունը: Միայն դրանից հետո CRM deal-ը անցնում է հաստատված կանխավճարի փուլ:
Կրկնվող իրադարձությունները անվտանգ անտեսվում են բիզնես գործողության մակարդակում: Failure-ի կամ հղման ժամկետի ավարտի դեպքում հայտը մնում է հստակ փուլում, իսկ մենեջերը կարող է ուղարկել նոր հղում՝ չկորցնելով պատմությունը:
- Frontend ազդանշանով ծառայության հասանելիություն չբացել:
- Webhook-ի անցումը դարձնել idempotent:
- CRM-ում պահել հաստատման ժամը և արտաքին payment id-ն:
- Expired, failed, pending և paid կարգավիճակները մշակել առանձին:
Գործարկումից հետո. ծառայության մատուցում և վերադարձ
Հաստատված վճարմանը պետք է հաջորդի ծառայության հստակ կանոն, ծանուցում և թափանցիկ վերադարձի ուղի:
Հաստատումից հետո հոսքը կարող է ստեղծել խնդիր, բացել հասանելիություն, հաստատել գրանցում կամ ուղարկել ծանուցում: Կոնկրետ գործողությունը պետք է ունենա բիզնես կանոն, ոչ թե կախված լինի մենեջերի մեկնաբանությունից:
Եթե ծառայությունը չեղարկվում է, վերադարձը գրանցվում է որպես առանձին իրադարձություն՝ պատճառաբանությամբ և սկզբնական deal-ի կապով: Սա պահպանում է հստակ պատմություն աջակցության և հաշվառման համար:
- Paid-ից հետո ֆիքսել ծառայության մատուցման կանոնը:
- Մի CRM դաշտում չխառնել կանխավճարը, լրացուցիչ վճարն ու վերադարձը:
- Ձեռքով ուղղման համար պահել աղբյուրը, ամսաթիվը և պատասխանատուին:
- Հաշտեցման մեջ դիտարկել ժամկետանց հղումները և pending վճարումները:
FAQ
Կարելի՞ է Tilda-ից payment link ուղարկել առանց CRM-ի:
Տեխնիկապես հնարավոր է, սակայն վերահսկվող գործընթացի համար ավելի լավ է հղումը ստեղծել CRM-ից կամ backend-ից և կապել այն հայտի, ծառայության ու պատասխանատուի հետ:
Ե՞րբ տեղափոխել deal-ը վճարված փուլ:
Միայն սերվերային ստուգումից կամ ճիշտ մշակված webhook-ից հետո: Success page-ը և սքրինշոթը չեն հաստատում վերջնական կարգավիճակը:
Ինչպե՞ս գրանցել ծառայության չեղարկումը:
Չեղարկումն ու վերադարձը գրանցել որպես առանձին իրադարձություններ՝ կապված սկզբնական deal-ի և վճարման հետ: Կանխավճարի պատմությունը պետք է պահպանվի:
