Русский
Українська
ქართული
English
Қазақша
Español
Français
Deutsch
Italiano
فارسی
Հոդվածի ֆոկուսը
CRM-ը չպետք է լինի վճարման մատակարար
Bitrix24, amoCRM կամ Kommo-ն հարմար են մենեջերների համար, սակայն վճարման վերջնական կարգավիճակը պետք է ստացվի սերվերի կողմից հաստատումից:
Ընդհանուր սխալն այն է, որ ենթադրենք, որ CRM ինքնին կարող է ճշմարտության աղբյուր լինել վճարումների վերաբերյալ: Կառավարիչը ստեղծեց գործարք, ուղարկեց հղում, հաճախորդը սկսեց վճարել, բայց վերջնական կարգավիճակը պետք է հաստատվի backend-ի կողմից՝ ստուգված webhook-ի, մատակարարի տեղեկանքի և կարգավիճակի վերստուգման միջոցով:
CRM-ն այս սցենարում պահպանում է բիզնեսի համատեքստը՝ գործարք, հաշիվ, հաճախորդ, կառավարիչ, մեկնաբանություններ և առաջադրանքներ: Վճարման շերտը պահպանում է վճարման փորձը, կարգավիճակը, գումարը, արժույթը, ժամանակը, հարցման ID-ն և տեխնիկական պատմությունը: Այսպիսով, աջակցությունը տեսնում է ամբողջ պատկերը, և հաշվապահությունը ստանում է համապատասխան տվյալներ հաշտեցման համար:
- մի թարմացրեք գործարքը միայն redirect հաճախորդի կողմից;
- խանութի մատակարարի տեղեկանք CRM ապրանքագրի/գործարքի ID-ի կողքին;
- առանձին ստեղծված, pending, վճարված, ձախողված, ժամկետանց և վերադարձված;
- Մատյան վերաուղարկվում է payment link մենեջերի կողմից:
Ինչպես ձևավորել գործարքների և հաշվի կարգավիճակները
CRM կարգավիճակները պետք է օգնեն մենեջերին և չկրկնեն մատակարարի բոլոր տեխնիկական կարգավիճակները մեկ առ մեկ:
CRM-ի համար ավելի օգտակար է կարգավիճակների նորմալացված փաթեթը. վճարման սպասում, վճարված, վճարման սխալ, վերջնաժամկետը սպառվել է, անհրաժեշտ է ձեռքով վերանայել, մասնակի վերադարձ, գումարի ամբողջական վերադարձ: Backend-ը կարող է ներքին ավելի շատ տեխնիկական մանրամասներ պահել, սակայն կառավարչին անհրաժեշտ է գործողությունների կարճ ցուցակ:
Առանձին-առանձին անհրաժեշտ է նկարագրել անցումային կանոնները: Օրինակ, ձախողումը չպետք է ընդմիշտ փակի հաշիվը, եթե հաճախորդը կարողանա նորից փորձել: Սպասող ապրանքը կամ ծառայությունը չպետք է առաքվի: Վերադարձված գումարը չպետք է հեռացնի վճարման պատմությունը գործարքից:
- կապել վճարման փորձը որոշակի հաշվի կամ գործարքի հետ.
- ստեղծել առաջադրանք մենեջերի համար միայն բացառությունների համար.
- մի շփեք պատահական հին webhook-ով վճարված;
- ցույց տալ վճարվածը, գումարը, արժույթը և մատակարարի տեղեկանքը:
Ինչ հաշվի առնել webhooks-ում և նորից փորձել
CRM API-ն կարող է արձագանքել ուշացումներով և սահմանափակումներով, ուստի վճարումների համաժամացումը պետք է լինի անիմաստ և կրկնվող:
Վճարման մատակարարի վեբ-կապը կարող է նորից հայտնվել, հասնել redirect-ից առաջ կամ հասնել այն ժամանակ, երբ CRM API-ը ժամանակավորապես անհասանելի է: Հետևաբար, մշակողը պետք է ստուգի ստորագրությունը, պահի իրադարձությունը, կիրառի idempotency բանալին և թարմացնի CRM վերահսկվող հերթի միջոցով:
Եթե CRM թարմացումը ձախողվի, վճարումը չի կարող կորցնել: Ձեզ անհրաժեշտ է թողնել ներքին վճարովի կարգավիճակը, գրանցել համաժամացման սխալ, կրկնել գործողությունը և բացառությունը ցույց տալ օպերատորին միայն մի քանի անհաջող փորձից հետո:
- ստուգեք մատակարարի ստորագրությունը կամ սերվերի կարգավիճակը.
- դարձնել CRM թարմացումը անիմաստ;
- կրկնել ժամանակավոր սխալները API;
- պահել աուդիտի հետք՝ ձեռքով ուղղումների համար:
FAQ
Հնարավո՞ր է արդյոք գործարքը թարմացնել CRM-ում հաճախորդի հաջողության էջ մտնելուց անմիջապես հետո:
Ոչ: Հաջողության էջը օգտակար է հաճախորդի համար, բայց ավելի լավ է թարմացնել CRM վճարումը սերվերի կողմից կամ վստահված webhook ստուգումից հետո: Վերահղումը կարող է փակվել, նորից փորձել կամ բացվել առանց վերջնական կարգավիճակի:
Ի՞նչ պետք է անեմ, եթե CRM API հասանելի չէ վճարման ժամանակ:
Վճարման ֆոնդը պետք է պահպանի վերջնական կարգավիճակը, սահմանի CRM համաժամացումը, որպեսզի նորից փորձի և բացառություն ցույց տա օպերատորին, եթե կրկնվող փորձերը ձախողվեն:
Արդյո՞ք կառավարիչը պետք է տեսնի մատակարարի բոլոր տեխնիկական կարգավիճակները:
Սովորաբար ոչ: Կառավարիչին անհրաժեշտ է նորմալացված կարգավիճակ և հստակ գործողություն: Ավելի լավ է տեխնիկական մանրամասները պահել աուդիտի հետքերում և վճարային քարտում:
