Okto CRM Portal — დანერგვის საკითხების სია

დოკუმენტი მუშავდება შემოწმებისთვის: ქვემოთ ჩამოთვლილია ყველა საკითხი, რომელიც ინტერაქტიულ checkpoint-დოკუმენტში მოხვდება. დათანხმების შემდეგ ვაშენებთ სრულფასოვან გვერდს — სტატუსების მართვით, ავტორიზაციული კომენტარებით, ცვლილებების KV-ში ავტომატური შენახვით.

ჯამური სექცია: 19 ჯამური საკითხი: 134 აქედან განსახილველი: 83 აქედან „შესრულებული“ ნაგულისხმევად: 51
კლიენტის მიერ მოწოდებული — Okto-ს მოთხოვნა / ფაილში მითითებული
Dinowio-ს მიერ დამატებული — სქემიდან გამოვლენილი საკითხები
ნაგულისხმევი სტატუსი „შესრულებული“
შენიშვნა სტრუქტურის შესახებ: სექციები 1–12 სამუშაო თემებია (განსახილველი) — შენ მიერ მოწოდებული მოთხოვნა „ლიდის შექმნისას მისი განაწილების ავტომატური ლოგიკა, წყაროები, ვინ მიიღოს, ბიზნეს პროცესი, ხედვის უფლება“ — დაიშალა მრავალდონიან საკითხებად ხუთ ერთეულზე (ლიდი, კონტაქტი, კომპანია, გარიგება, შეთავაზება), პლუს დანერგვის ფარგლებში გასარკვევი ცალკეული ნაწილები (ბიზნეს პროცესების შაბლონები, ტრიგერები, როლები, ფორმები, მიგრაცია). სექციები 13–19 — შენი მოწოდებული „შესრულებული“ ჩამონათვალი (ატვირთვა, ჩაშენებული მოდულები, შაბლონები, დოკუმენტები, ბიზნეს პროცესები). სექცია 20 — შენი მოწოდებული „სხვა საკითხები“ ცარიელი ფანჯარა, ცოცხალი დამატებისთვის.
▸ ჯგუფი A: სამუშაო თემები — განსახილველი (12 სექცია, 83 საკითხი)
1
ლიდების მართვა
ლიდის შემოსვლის, განაწილების, რეაგირების და კონვერსიის ლოგიკა. წყაროების მიხედვით — ვინ მიიღოს, რა ვადაში, რა შეხსენებით.
კლიენტის მოთხოვნა — ლიდის განაწილების ლოგიკის დაშლა · 10 საკითხი
1.1
ლიდის ავტომატური განაწილების ლოგიკა წყაროების მიხედვით
თითოეული წყაროსთვის (Facebook, ვებ-ფორმა, ზარი, ელექტრონული ფოსტა, რეკომენდაცია, პარტნიორი, აპლიკაცია) — რომელ ჯგუფს ან ცვლას გადაეცემა; round-robin, ჩატვირთვით თუ ხელით; რომელი წყაროდან მოსული ლიდი იღებს მაღალ პრიორიტეტს.
1.2
პასუხის გაცემის დროის ნორმატივი (SLA)
ლიდის შემოსვლიდან რამდენ წუთში ან საათში უნდა მოხდეს პირველი რეაგირება; რა ხდება ვადის გადაცილებისას — ესკალაცია უფროს მენეჯერთან, ჯგუფის გადანაცვლება, ავტომატური დაბრუნება queue-ში.
1.3
შეხსენების მექანიზმი და ფორმატი
სმს, push შეტყობინება, ელექტრონული ფოსტა, Bitrix24-ის შიდა შეტყობინება — რომელი არხებით; როდის ხდება ხელახალი შეხსენება და რამდენჯერ; რა ფორმულირებით.
1.4
ხედვის უფლება ლიდზე
გაყიდვების მენეჯერი ხედავს მხოლოდ თავის ლიდებს, ჯგუფის ლიდებს თუ ყველას; უფროსი მენეჯერი და ხელმძღვანელი ხედავენ რას; ფინანსურმა და მარკეტინგმა — რა მოცულობით.
1.5
რედაქტირების და მოქმედებების უფლება
ვის შეუძლია ლიდის სტადიის შეცვლა, კონვერსია კონტაქტში და გარიგებაში, წაშლა, სხვა მენეჯერისთვის გადაცემა, შერწყმა.
1.6
დუბლიკატების კონტროლი
რა მონაცემზე ხდება დუბლიკატის შემოწმება — ტელეფონის ნომერი, ელექტრონული ფოსტა, პირადი ნომერი; რა ხდება დუბლიკატის აღმოჩენისას — ავტომატური მიერთება, შეტყობინება მენეჯერთან, შესვლის შეზღუდვა.
1.7
ლიდის სტადიების ჩამონათვალის გადახედვა
არსებული 25 სტატუსი (NEW, IN_PROCESS, PROCESSED, CONVERTED, JUNK და მორგებული) — გადახედვა, რომელია ნამდვილად საჭირო, რომელი წავიდეს, რა ახალი დაემატოს.
1.8
ლიდის კონვერსიის სტრატეგია
ლიდი → კონტაქტი + გარიგება ერთდროულად, თუ ფაზურად; რომელ pipeline-ში გადადის გარიგება ავტომატურად; ნაგულისხმევი სტადია; რომელი ველი გადაიწერება ლიდიდან გარიგებაში.
1.9
დაკარგული ლიდის რეტარგეტინგი
JUNK ან წაგებული სტატუსში გადასული ლიდი დაუბრუნდება მუშაობას რა ვადით; ვის გადაეცემა; რა მოტივირებით.
1.10
76 მორგებული ველის გადახედვა
Lead-ზე არსებული 76 მორგებული ველი — გადახედვა, რომელია გამოყენებული, რომელია ისტორიული; სავალდებულობა; ხედვის უფლება როლების მიხედვით.
2
კონტაქტების მართვა
კონტაქტის ბარათის სტრუქტურა, ტიპები, ფინანსური და უძრავი ქონების ინფორმაცია, ხედვის უფლება და დუბლიკატების კონტროლი.
Dinowio-ს მიერ დამატებული — სქემიდან გამოვლენილი · 7 საკითხი
2.1
კონტაქტის ტიპები
არსებული 6 ტიპი (Client, Supplier, Partner, Other, „3“) — გადახედვა; რომელია გამოყენებული; რომელი დაემატოს (მაგალითად — Tenant, Co-Borrower, Guarantor).
2.2
სექცია „ბინის შესახებ“ — 19 ველი
კონტაქტის ბარათში „ბინის შესახებ“ სექციის 19 ველი — სად გამოიყენება (კონტრაქტი, ინვოისი, რეესტრი); რომელია სავალდებულო კონტრაქტამდე; ეს ცხოვრობს კონტაქტში თუ გარიგებაში.
2.3
სექცია „ხელშეკრულების შესახებ“ — 6 ველი
კონტრაქტის ნომერი, თარიღი, ვადა, ხელმოწერის სტატუსი — ეს ცხოვრობს კონტაქტში, თუ ცალკე გარიგების ერთეულში; რა ხდება მრავალ კონტრაქტიან კონტაქტთან.
2.4
სექცია „ფინანსები“ — 4 ველი
ანგარიში, ლიმიტი, ვალუტა, ბალანსი — გადახედვა; რომელია ცოცხალი გათვლით, რომელია ხელით; ბანკთან კავშირი.
2.5
ხედვის უფლება კონტაქტზე
გაყიდვების მენეჯერი ხედავს მხოლოდ თავის კონტაქტებს, თუ ყველას; ფინანსურმა და მარკეტინგმა — რა მოცულობით.
2.6
დუბლიკატების კონტროლი კონტაქტებზე
პირადი ნომერი, ტელეფონი, ფოსტა — რომელია უნიკალური ბაზაში; რა ხდება შერწყმისას — რომელი ველი გადარჩება.
2.7
115 მორგებული ველის გადახედვა
Contact-ზე არსებული 115 მორგებული ველი — გადახედვა, ცარიელი ველების ამოღება, სავალდებულობის გადახედვა.
3
კომპანიების მართვა
კომპანიის ერთეული — როდის გამოიყენება (B2B თუ B2C), ტიპები, ინდუსტრიები და კონტაქტ-კომპანია კავშირი.
Dinowio-ს მიერ დამატებული — სქემიდან გამოვლენილი · 5 საკითხი
3.1
კომპანიის ერთეულის როლი Okto-ში
Okto მუშაობს ფიზიკურ პირებთან (კონტრაქტი ბინაზე), თუ ხშირია იურიდიული პირები; თუ B2B იშვიათია — კომპანიის ერთეული გავამარტივოთ თუ მთლიანად ამოვიღოთ.
3.2
კომპანიის ტიპები
5 ტიპი (Customer, Supplier, Competitor, Partner, Other) — გადახედვა; Okto-სთვის რომელია რელევანტური.
3.3
ინდუსტრიების სია — 11 ჩამონათვალი
IT, Telecom, Manufacturing, Banking, Consulting და სხვა — გადახედვა; უძრავი ქონების ბიზნესისთვის რომელია გამოყენებადი.
3.4
კონტაქტი ↔ კომპანია კავშირი
ერთი კონტაქტი → მრავალი კომპანია (M:N), თუ მხოლოდ ერთი (1:1); პრიმარული კომპანიის გამოყოფა; ერთი კომპანიის შიგნით როლები (CEO, აქციონერი, კონტაქტი).
3.5
74 მორგებული ველის გადახედვა
Company-ზე არსებული 74 მორგებული ველი — ნამდვილად საჭიროა B2C-ცენტრალური ბიზნესისთვის.
4
გარიგებების მართვა — გაყიდვის ციკლი
5 pipeline (C0, C1, C3, C5, C7), 66 სტადია, 495 მორგებული ველი, განვადების გრაფიკი. ყველაზე რთული და ფასისეული ნაწილი — სრულად განხილვა.
კლიენტის მოთხოვნა — გაყიდვის პროცესი, კონტრაქტი, გრაფიკი · 11 საკითხი
4.1
Pipeline C0 (ნაგულისხმევი) — 12 სტადია
NEW, WON, LOSE, APOLOGY, UC_AJQKMK და სხვა — რა მიზნით გამოიყენება, რომელი დეპარტამენტი მუშაობს ამ pipeline-ში; გადახედვა — საჭიროა ეს pipeline ცალკე.
4.2
Pipeline C1 — 7 სტადია
NEW, PREPARATION, EXECUTING, WON, LOSE — დანიშნულება და ფუნქცია; რომელი ბიზნეს პროცესია მიბმული.
4.3
Pipeline C3 — 31 სტადია (ყველაზე რთული)
31 სტადია ერთ pipeline-ში — ეს ბევრია; შესაძლოა გასაერთიანებელია, გასაყოფია ან გასამარტივებელია; ფერების სქემა; გადასვლის წესები; ბიზნეს პროცესების მიბმა.
4.4
Pipeline C5 — 10 სტადია (ფინანსები)
PREPARATION, PREPAYMENT_INVOICE, EXECUTING, FINAL_INVOICE — ფინანსური ეტაპები; ბევრი ბიზნეს პროცესია მიბმული.
4.5
Pipeline C7 — 6 სტადია
NEW, PREPARATION, PREPAYMENT_INVOICE, EXECUTING, WON — დანიშნულება; რომელი დეპარტამენტი მართავს.
4.6
პროდუქტის რიგების მართვა გარიგებაში
Product Rows ერთი გარიგების შიგნით — როდის და ვინ ამატებს; საფასოები; ფასდაკლება; ვალუტა; ვინ ხედავს და რედაქტირებს.
4.7
სექცია „განვადების გრაფიკი“ — 73–81 ველი
გარიგების ბარათში „განვადების გრაფიკი“ სექცია (DEALC: 73 ველი, DEALC_3: 81 ველი) — ეს მართლა გარიგების ბარათშია, თუ ცალკე ცხრილში ჯობია; ჩვენების ლოგიკა.
4.8
სექცია „განვადების შესახებ“ — 72–80 ველი
DEALC: 72 ველი, DEALC_3: 80 ველი — გრაფიკის ცალკეული ხაზის ინფორმაცია; სად ცხოვრობს — გარიგების ერთეულში თუ ცალკე სმარტ პროცესში.
4.9
ხელშეკრულების ინფორმაცია — სად ცხოვრობს
კონტრაქტის ნომერი, თარიღი, ვადა — კონტაქტში თუ გარიგებაში; რა ხდება, თუ ერთ კონტაქტს რამდენიმე კონტრაქტი აქვს (ბინა 1, ბინა 2); გადახედვა.
4.10
43 CRM-binding ველი Deal-ზე
DEAL ერთეულის 43 ცალი UF_CRM_* ველი, რომელიც სხვა CRM ერთეულს მიუთითებს — გადახედვა; რომელია გამოყენებული; რომელია არასწორი ან მოძველებული.
4.11
495 მორგებული ველის გადახედვა და ოპტიმიზაცია
Deal-ზე 495 მორგებული ველი — ბევრია; გადახედვა, რომელია გამოყენებული, რომელია მოძველებული; სიჩქარისა და ხერხემელის გასაუმჯობესებლად — გასარჩევია.
5
შეთავაზებები (Quotes)
შეთავაზების ერთეული — 248 მორგებული ველი, 5 სტატუსი, PDF გენერაცია, Deal-ის კავშირი.
Dinowio-ს მიერ დამატებული — სქემიდან გამოვლენილი · 6 საკითხი
5.1
შეთავაზების სტატუსები — 5 ცალი
DRAFT, SENT, APPROVED, DECLINED, APOLOGY — გადახედვა; დამატებითი სტატუსების საჭიროება (მაგალითად — IN_REVIEW, NEGOTIATING).
5.2
248 მორგებული ველის გადახედვა
Quote-ზე 248 მორგებული ველი — გადახედვა; ნაგულისხმევი მნიშვნელობების კონფიგურაცია.
5.3
39 CRM-binding ველი (Quote → Deal კავშირი)
Quote-ის 39 ცალი UF_CRM_* ველი, რომელიც Deal-ს უკავშირდება — გადახედვა; ლოგიკის სიწმინდე.
5.4
PDF-ის გენერაცია, შაბლონი, ხელმოწერა
შეთავაზების PDF-ის ფორმატი; ლოგო, ფონი, შტამპი, ფაქსიმილე; ხელმოწერის ლოგიკა — ლოკალური მოდიფიკაცია.
5.5
შეთავაზების ვადა (validity)
ვადის ავტომატური გათვლა; ვადის გასვლის შემდეგ რა ხდება; ხელახალი გენერაცია.
5.6
ხელახალი გენერაცია და ვერსიონირება
შეთავაზების ცვლილების შემთხვევაში — ვერსიონირება, ისტორიის შენახვა, წინა ვერსიის ხელმისაწვდომობა.
6
სმარტ პროცესი — დუბლიკატები (1036)
Dynamic ერთეული entityTypeId=1036 „Dublicate“ — დუბლიკატების მართვის სამუშაო პროცესი.
Dinowio-ს მიერ დამატებული — სქემიდან გამოვლენილი · 5 საკითხი
6.1
სმარტ პროცესის დანიშნულება და ლოგიკა
1036 entity — დუბლიკატების მართვის ცალკე process; რა შემთხვევაში იქმნება ჩანაწერი; ვინ ამუშავებს.
6.2
სტადიები — NEW, SUCCESS, FAIL
DT1036_11:NEW → SUCCESS ან FAIL — გადაწყვეტის ლოგიკა; ვინ აღნიშნავს; რა ხდება SUCCESS-ის შემდეგ (merge ან წაშლა).
6.3
ჩანაწერის შექმნა — ავტომატური თუ ხელით
დუბლიკატის აღმოჩენისას ჩანაწერი ავტომატურად იქმნება, თუ მენეჯერი ხელით ქმნის; რა ტრიგერი მუშაობს.
6.4
უფლებები — 9 როლის წვდომა (90 უფლება)
DYNAMIC_1036_C11-ზე 9 როლს 90 უფლება აქვს — გადახედვა; რომელია ნამდვილად საჭირო.
6.5
ბიზნეს პროცესის შაბლონები DYNAMIC_1036-ისთვის
4 შაბლონია — გადახედვა; რა ლოგიკას ასრულებენ.
7
მორგებული ველები — ჯამური აუდიტი
ჯამში 1,008+ მორგებული ველი ხუთ ერთეულზე. გადახედვა, კონსოლიდაცია, ხედვისა და სავალდებულობის წესების მიმოხილვა.
Dinowio-ს მიერ დამატებული — სქემიდან გამოვლენილი · 7 საკითხი
7.1
ჯამური რაოდენობა — 1,008+ ველი
Deal: 495, Quote: 248, Contact: 115, Lead: 76, Company: 74 — ეს მართლა ნორმაშია? რა ხდება გვერდის ჩატვირთვის სიჩქარესთან.
7.2
enumeration ველი — 165 ცალი ჯამში
Deal 65 + Quote 55 + Contact 18 + Lead 10 + Company 9 + Dynamic 1036 — სიების ზომის გადახედვა; რომელია მოძველებული.
7.3
file ველი — 10 ცალი
ფაილის ტიპის ველი — სად ცხოვრობს ფაილები (Bitrix24-ის Disk-ი თუ გარე); დაცვის და გადახედვის უფლება.
7.4
CRM-binding ველი — 84+ ცალი
Deal 43 + Quote 39 + Contact 1 + Lead 1 + Company 1 — გადახედვა; რომელია ნამდვილად გამოყენებული.
7.5
employee ველი — 2 ცალი (Deal, Quote)
მომხმარებლის ტიპის ველი — გადახედვა; ცარიელია თუ გამოყენებული; მიგრაცია USER-ის mapping-ით.
7.6
PREFIX_TO_ENTITY mapping — UF_CRM_* ველებში
L=Lead, C=Contact, CO=Company, D=Deal — ეს პრეფიქსები Okto-ს Bitrix24-ის ვერსიის სტანდარტს ემთხვევა; მიგრაციის toolkit-ში field_map.py-ში გადასამოწმებელია.
7.7
ცარიელი / გამოუყენებელი ველი
ველი, რომელშიც არცერთი ჩანაწერი არ წერია — აუდიტი; მონაცემთა გადატანამდე გარკვევა, წავიდეს თუ დარჩეს.
8
ბიზნეს პროცესების შაბლონები — 229 ცალი
Deal-ისთვის 162, Lead-ისთვის 54, Contact-ისთვის 5, SmartInvoice-ისთვის 4, Dynamic 1036-ისთვის 4. გადახედვა, აუდიტი, ოპტიმიზაცია.
Dinowio-ს მიერ დამატებული — სქემიდან გამოვლენილი · 7 საკითხი
8.1
Deal-ის შაბლონები — 162 ცალი
DEAL-ის ბიზნეს პროცესის შაბლონები — auto_execute რეჟიმის გადახედვა; რომელია გამოყენებული; მოძველებულების ამოღება; გადახედვა pipeline-ის მიხედვით.
8.2
Lead-ის შაბლონები — 54 ცალი
LEAD-ის ბიზნეს პროცესის შაბლონები — გადახედვა; ლიდის სტადიის ცვლილებაზე რა იწყება.
8.3
Contact-ის შაბლონები — 5 ცალი
CONTACT-ის ბიზნეს პროცესის შაბლონები — გადახედვა; რა ფუნქციას ასრულებენ.
8.4
SmartInvoice-ის შაბლონები — 4 ცალი
SmartInvoice (DT31_3:N/S/P/D) — ინვოისების სამუშაო პროცესი; გადახედვა.
8.5
Dynamic 1036-ის შაბლონები — 4 ცალი
დუბლიკატების სმარტ პროცესის შაბლონები — გადახედვა.
8.6
მიგრაციის შემდეგ აქტიური workflow-ები
Cloud-ში ამჟამად გაშვებული ბიზნეს პროცესების instance-ები (in-flight) — მიგრაციით არ გადადის; სტრატეგია — მოვიცადოთ დასრულებამდე, თუ ცალკე გადავიტანოთ.
8.7
შაბლონების აუდიტი — მოძველებული თუ აქტუალური
229 შაბლონიდან რომელია ხშირად გამოყენებული, რომელია ისტორიული; გაწმენდის სტრატეგია.
9
ტრიგერები და ავტომატიზაცია
12 ტრიგერი — ძირითადად B2E ხელმოწერის პროცესისთვის; ერთი FIELD_CHANGED ტრიგერი DEAL C1:FINAL_INVOICE-ზე.
Dinowio-ს მიერ დამატებული — სქემიდან გამოვლენილი · 4 საკითხი
9.1
12 ტრიგერი — გადახედვა
B2E_COORDINATION, B2E_FILLING, B2E_SIGNING, B2E_COMPLETED — ძირითადად დოკუმენტის ხელმოწერის პროცესია; რა მიზნით; რომელია გამოყენებული.
9.2
FIELD_CHANGED ტრიგერი — Deal C1:FINAL_INVOICE
ერთადერთი არა-B2E ტრიგერი — ველის ცვლილების ტრეკინგი; რა ცვლილებას ადევნებს თვალს; რა იწყება.
9.3
ახალი ტრიგერების საჭიროება
Okto-ს ბიზნეს ლოგიკის გათვალისწინებით — რა ახალი ტრიგერი იქნება საჭირო (გადახდის ვადის გასვლა, კონტრაქტის გაუქმება, ბროკერის შეცვლა).
9.4
ტრიგერი vs ბიზნეს პროცესი — როდის რომელი
ცალკეული ცვლილებისთვის — ტრიგერი vs სრულფასოვანი workflow; რომელია უპირატესი რომელ შემთხვევაში.
10
როლები და უფლებები — 19 როლი
19 როლი, თითოეულზე უფლებების მთელი მატრიცა. DEAL_C3 — 39 უფლება, DYNAMIC_1036_C11 — 90 უფლება. გადახედვა და კონსოლიდაცია.
კლიენტის მოთხოვნა — უფლებების ლოგიკა, ავტორიზაცია · 6 საკითხი
10.1
19 როლი — ნამდვილად საჭიროა ეს ყველაფერი
Bitrix24-ის Role ID-ები: 5, 7, 9, 13, 15, 17, 19, 25, 27, 29, 31, 33, 35, 39, 41, 43, 51, 57, 59 — ბევრია; კონსოლიდაცია; როლების მინიმუმამდე დაყვანა.
10.2
DEAL_C3 — 39 უფლება, 10 როლი
DEAL_C3-ზე ყველაზე რთული უფლების მატრიცაა — 39 ცალკეული უფლება, 10 როლი ეხება; გადახედვა, გამარტივება.
10.3
DYNAMIC_1036_C11 — 90 უფლება, 9 როლი
სმარტ პროცესის უფლების ცხრილი ყველაზე გადატვირთულია (90 უფლება); გადახედვა — რომელია ნამდვილად საჭირო.
10.4
თითო მომხმარებლისთვის როლის მინიჭება
მიგრაციის შემდეგ — როლის ID-ები არ ემთხვევა target-ს; ხელით reassign; ვინ რა როლს ღებულობს.
10.5
ჯგუფების მართვა (department vs role)
Bitrix24-ში დეპარტამენტი ცალკეა, როლი ცალკეა; როგორ უნდა იყოს დაკავშირებული; ცვლების გადანაცვლების ლოგიკა.
10.6
ხედვის უფლება — own / department / all
სტანდარტული Bitrix24-ის სამი დონე — own (მხოლოდ თავის), department (ჯგუფის), all (ყველა); Okto-ში რომელია ძირითადი მოდელი.
11
CRM ფორმები — 60 ცალი
60 CRM ფორმა — ვებსაიტის callback, Facebook, პარტნიორის ფორმები. გადახედვა, აქტიური vs არააქტიური, ველების mapping.
Dinowio-ს მიერ დამატებული — სქემიდან გამოვლენილი · 5 საკითხი
11.1
60 ფორმა — აქტიური vs არააქტიური
შემოწმება — რომელია ნამდვილად აქტიური, რომელია ისტორიული; გაწმენდის ლისტი.
11.2
Facebook ფორმები — ველების mapping
Facebook Lead Ads-დან მოსული ფორმის ველი → Bitrix24-ის ლიდის ველი; ვინ აკონფიგურირებს; რა საჭიროებს ცვლილებას მარდიდან გადატანის შემდეგ.
11.3
ვებსაიტის callback ფორმა
Callback / „დაგვირეკეთ“ ფორმა — სად დარჩა; ვერსიონირება; A/B ტესტირება.
11.4
პარტნიორის ფორმა
„Partners Form Int“ — შიდა გამოყენებისთვის; რა მიზნით.
11.5
ფორმის შედეგი → ლიდი თუ კონტაქტი
ფორმის შევსების შემდეგ ავტომატურად რა იქმნება — ლიდი, კონტაქტი, თუ გარიგება; რა pipeline-ში; რა სტადიაზე.
12
მონაცემთა მიგრაცია
Bitrix24 Cloud-დან Self-Hosted-ზე გადატანა. 15,000 კონტაქტი, 7,000 ლიდი, 17,187 გარიგება, 85,000 აქტივობა, 25,000 საუბარი.
Dinowio-ს მიერ დამატებული — სქემიდან გამოვლენილი · 10 საკითხი
12.1
მიგრაციის ფანჯრის შერჩევა — კვირაგასვლა
რეკომენდირებული: პარასკევი 18:00 — ორშაბათი 09:00. Cloud-ზე read-only რეჟიმი; ან catch-up ფაზის ლოგიკა მიგრაციის ბოლოს.
12.2
15,000 კონტაქტი — გადატანის ფაზა
Contact-ის მიგრაცია toolkit-ით; ID mapping ცხრილში დარეგისტრება.
12.3
7,000 ლიდი + 17,187 გარიგება
Lead და Deal-ის მიგრაცია; product rows; UF_CRM_* binding ველების resolve; ID mapping.
12.4
85,000 აქტივობა — ყველაზე გრძელი ფაზა
Activity-ის მიგრაცია — დიდი მოცულობა, rate limit-ით შეზღუდული; resume from checkpoint ლოგიკა.
12.5
25,000 საუბარი — გადასაწყვეტი ბუნება
Open Channel (Live Chat / IMOPENLINES) — REST-ით პრაქტიკულად შეუძლებელია გადატანა. CRM Activity-ში არსებული საუბრები ისედაც აქტივობების ფაზაში გადადის. დაზუსტება — რომელია 25,000.
12.6
ფაილების მიგრაცია — ~12 GB
Deal-ის და სხვა ერთეულების მიბმული ფაილები; REST-ით (base64) თუ ფაილ-სისტემით; რომელი არჩევანი.
12.7
მომხმარებლების შეხამება
Toolkit აშენებს ფოსტით mapping-ს, არ ქმნის მომხმარებლებს. ხელით შექმნა target-ზე; ლიცენზიის გადახედვა.
12.8
პაროლები არ გადადის — წინასწარი შეტყობინება
Bitrix24 REST პაროლს არ აბრუნებს. მომხმარებლები ხელახლა შექმენიან პაროლს self-hosted-ზე — წინასწარი შეტყობინება.
12.9
catch-up ფანჯრის ლოგიკა
მიგრაციის დროს Cloud-ზე მონაცემი თუ იცვლება — DATE_MODIFY > cutoff ფილტრით ცვლილებების ხელახალი ჩამოწერა მიგრაციის ბოლოს.
12.10
39 მარკეტპლეისის აპლიკაცია — გადახედვა
alaio.bic_* — 25 ცალი BI რეპორტი (cloud-only). სხვა აპები — რომელია ნამდვილად საჭირო self-hosted-ზე; რომელი მოვითხოვოთ self-hosted compatibility-ით; რომელი ჩავანაცვლოთ.
▸ ჯგუფი B: შესრულებული — ბაზური სამუშაო (6 სექცია, 50 საკითხი, ნაგულისხმევი სტატუსი „შესრულებული“)
13
ატვირთული მონაცემები
CRM-ში ატვირთული ბაზური ცხრილები — კომპანიის მონაცემები, ლიდები, გარიგებები, გადახდები.
ნაგულისხმევი: შესრულებული — შენ მიერ მოწოდებული · 12 საკითხი
13.1
My Company
13.2
ბანკები
13.3
პროექტები
13.4
პროდუქტები
13.5
რემონტის კონფიგურაცია
13.6
კონტაქტები
13.7
ბროკერები
13.8
ლიდები
13.9
დილები (გარიგებები)
13.10
გაყიდვები
13.11
გრაფიკები
13.12
გადახდები
14
დასაკონფიგურირებელი / გადმოსატანი
CRM-ის სიების და დამატებითი ველების კონფიგურაცია, ფორმების გადატანა.
ნაგულისხმევი: შესრულებული — შენ მიერ მოწოდებული · 5 საკითხი
14.1
წყაროების სია
14.2
მომხმარებლის ტიპების სია
14.3
დამატებითი ველები CRM ფორმებისთვის
14.4
CRM ფორმები უკუკავშირისთვის
14.5
CRM ფორმები Facebook კავშირისთვის (ველები)
15
ჩაშენებული მოდულები
CRM-ში ინტეგრირებული გარე სერვისები და ფუნქციური მოდულები.
ნაგულისხმევი: შესრულებული — შენ მიერ მოწოდებული · 11 საკითხი
15.1
მარკეტინგის მოდული, Facebook ჩვენების მოდიფიკაცია
მარდიდან გადატანა.
15.2
ვალუტის კურსები, NBG
მარდის კრონი არასრულია.
15.3
WhatsApp (WAIO)
15.4
სმს (Ubill + Twilio)
15.5
გადახდების ატვირთვა — ღილაკი და პროცესი
15.6
კალკულატორი — გაყიდვა / რესტრუქტურიზაცია
ღილაკი და პროცესი.
15.7
ხელმოწერა — ლოკალური მოდიფიკაცია
15.8
ვიზუალური პაკეტები
ლოგო, ფონი, შტამპი, ფაქსიმილე — პროექტების მიხედვით.
15.9
Flatris ინტეგრაცია
15.10
პასპორტის რიდერი / წამკითხველი
15.11
აფტერსეილის დაშბორდი
დავალიანებების ვიზუალიზაცია და ინტერაქტიული ღილაკები.
16
შაბლონები — ქართული, რუსული, ინგლისური
ელექტრონული ფოსტის და სმს-ის შაბლონები სამ ენაზე.
ნაგულისხმევი: შესრულებული — შენ მიერ მოწოდებული · 4 საკითხი
16.1
ელექტრონული ფოსტა და სმს — დავალიანება
16.2
ელექტრონული ფოსტა და სმს — დოკუმენტის ხელმოწერა
16.3
ელექტრონული ფოსტა და სმს — ინვოისის გაგზავნა
16.4
ელექტრონული ფოსტა და სმს — გადახდის დადასტურება
17
დოკუმენტები
CRM-ში ჩასმული დოკუმენტური შაბლონები — კონტრაქტი, რესტრუქტურიზაცია, ინვოისი, ბროკერი.
ნაგულისხმევი: შესრულებული — შენ მიერ მოწოდებული · 11 საკითხი
17.1
წინარე ნასყიდობა (რემონტით / რემონტის გარეშე)
17.2
რესტრუქტურიზაცია
17.3
მხარის ჩანაცვლება
17.4
კონტრაქტის გაუქმება (ორმხრივი შეთანხმება)
17.5
კონტრაქტის გაუქმება (ცალმხრივი ინფორმირება)
17.6
რემონტის დამატება
17.7
ინვოისი კონტრაქტის აქტივაციისთვის
17.8
ინვოისი სტანდარტული გადახდისთვის
17.9
გრაფიკის შეთავაზება, კალკულატორიდან
17.10
საბროკერო ხელშეკრულება
17.11
ბროკერის მიღება-ჩაბარება
18
ბიზნეს პროცესების ნაკრები
CRM-ში ჩაშენებული ბიზნეს პროცესების ნაკრები — ნასყიდობა, რესტრუქტურიზაცია, ინვოისები, რეგისტრაცია.
ნაგულისხმევი: შესრულებული — შენ მიერ მოწოდებული · 7 საკითხი
18.1
ნასყიდობის გაფორმება
18.2
რესტრუქტურიზაცია
18.3
ინვოისის ამოღება
18.4
ფინანსური რეპორტის ამოღება
18.5
მხარის ჩანაცვლება
18.6
კონტრაქტის გაუქმება
18.7
რეესტრში რეგისტრაცია (წინარე ნასყიდობა)
19
ენის გადართვა
ინტერფეისის ენის გადართვა მომხმარებლის დონეზე.
ნაგულისხმევი: შესრულებული — შენ მიერ მოწოდებული · 1 საკითხი
19.1
ინტერფეისის ენის გადართვა მომხმარებლის დონეზე
დასამატებელია, რომ მომხმარებელს შეეძლოს ენის ცვლილება.
▸ ჯგუფი C: დამატებითი (1 სექცია, საკითხების ცოცხალი დამატება)
20
სხვა საკითხები
ცარიელი სექცია — განხილვის დროს წამოჭრილი ან გადასახედი საკითხების ცოცხალი დამატებისთვის. ფინალურ ფაილში — ღილაკი „+ ახალი საკითხის დამატება“ + სტატუსი + კომენტარები.
კლიენტის მოთხოვნა — დამატების შესაძლებლობა · საკითხების რაოდენობა ცოცხალი