Azri

white-label უკუკავშირის სერვისი, რომელსაც ადამიანები SMS-ით აღწევენ. ფილიალში ვიზიტის, ზარის ან ავტოსერვისის შემდეგ ბიზნესი მომხმარებელს SMS-ით უგზავნის პერსონალურ ბმულს; ის ხსნის მობილურზე მორგებულ გვერდს, რომელიც ამოწმებს ტოკენს, აჩვენებს კამპანიას და მის კითხვებს, რომლებიც ერთიდან ხუთამდე ვარსკვლავით ფასდება, იღებს არასავალდებულო კომენტარს, პასუხს ერთხელ აგზავნის და მადლობას ეუბნება. თითოეულ ბიზნესს თავისი მონოგრამა, ფერები, გამგზავნის ID და საავტორო უფლებების სტრიქონი აქვს, ხოლო უცნობი, გამოყენებული ან ვადაგასული ბმული საკუთარ დასკვნით ეკრანს იღებს. ჩვენ ავაგეთ კითხვარის ფრონტენდი და მის გარშემო მსუბუქი პროქსი, თემატიზაცია და მიწოდება CRM-ისთვის, რომელსაც კამპანიები, ტოკენები და შეტყობინებები ეკუთვნოდა.

წელი: 2026 · კატეგორია: მომხმარებელთა უკუკავშირი

ჩვენი როლი

ფრონტენდი და მიწოდება. რესპონდენტის მიკროსაიტი და მისი მდგომარეობათა მანქანა, პროქსი-ფენა CRM-ის API-სთან, თითოეული კლიენტის white-label მორგება და კონტეინერული აწყობა, რომლითაც ეს გაიშვა.

პრობლემა

ბიზნესები, რომლებიც ხალხს პირისპირ ემსახურებიან, მაგალითად ბანკები, ტელეკომები, კლინიკები და ავტოსერვისები, ცდილობენ გაიგონ, როგორ ჩაიარა ვიზიტმა. ვებგვერდზე განთავსებულ ფორმას არავინ ხსნის, ზარით გამოკითხვა ადამიანის დროს ხარჯავს, გრძელ კითხვარს კი პირველივე ეკრანზე ტოვებენ. რასაც ხსნიან, SMS-ია, რასაც პასუხობენ — ტელეფონზე რამდენიმე ვარსკვლავი.

შეზღუდვები აქედან გამომდინარეობს. ბმული პერსონალური და ერთჯერადი უნდა იყოს, თორემ ერთი და იგივე პასუხი ორჯერ გაიგზავნება, გადაგზავნილი ბმული კი უცხო ადამიანის სახელით უპასუხებს. მას იმდენი კონტექსტი უნდა ჰქონდეს, რომ გვერდმა თქვას, ვისი ვიზიტია. და ის ერთდროულად რამდენიმე ბიზნესისთვის უნდა მუშაობდეს, რომელთაგან თითოეული ელის, რომ გვერდი მის საკუთარ პროდუქტს დაემსგავსოს.

მიდგომა

კითხვარის ფრონტენდი განზრახ პატარა დავტოვეთ და ყველაფერი, რაც გვერდი არ არის, CRM-ს მივანდეთ. კამპანიები, კითხვები, ტოკენების გაცემა, ვადის წესები, SMS-ის გაგზავნა და შედეგების შენახვა ზედა ფენაშია; მიკროსაიტი მხოლოდ ამოწმებს ტოკენს, იღებს კითხვებს, აგზავნის პასუხებს და ოთხი შედეგიდან ერთს ხატავს. მდგომარეობა უბრალო კომპონენტის მდგომარეობაა, რადგან ბიბლიოთეკის ღირსი მდგომარეობა აქ არ არის.

სამი მარშრუტის დამმუშავებელი JSON-ს CRM-ს გადაუგზავნის და სტატუსსა და პასუხის სხეულს უცვლელად აბრუნებს, რამაც ბრაუზერის cross-origin პრობლემა მეორე API-ს გამოგონების გარეშე მოხსნა. თითოეული კლიენტი კონფიგურაციაა (სახელი, ენდფოინთები, ლოგო, ძირითადი ფერი) და არა ფორკი. დემო ამ იდეას ერთი ნაბიჯით წინ მიიყვანს: ბიზნესის იერი ვალიდაციის პასუხში მოდის, ამიტომ ერთ ბანდლს ხუთი ბიზნესის ჩვენება შეუძლია.

მთავარი მომენტები

რესპონდენტის იდენტობა თავად ბმულია: ექვსნიშნა ტოკენი ანბანიდან, სადაც ერთმანეთის მსგავსი სიმბოლოები არ არის, მოწმდება ყოველ გამოძახებაზე, პირველივე გაგზავნისას იხარჯება, ხოლო უცნობი, გამოყენებული ან ვადაგასული ბმულისთვის ცალკე დასკვნითი ეკრანი ჩნდება.
white-label პიქსელამდე: ბიზნესის მონოგრამა, ფერები, გამგზავნის ID და საავტორო უფლებების სტრიქონი ვალიდაციის პასუხთან ერთად მოდის, ამიტომ ერთი კომპონენტების ხე ხუთ განსხვავებულ ბრენდს ატარებს.
კითხვარი ორიგინალის თავისებურებებს განზრახ ინარჩუნებს: წარუმატებლობები HTTP 200 კონვერტებად, შეფასებები, რომელთა გაზრდაც შეიძლება და გასუფთავება — არა, შეუფასებელი კითხვები `null`-ად და ერთი გაგზავნა ერთ ბმულზე.
კითხვარის გარშემო სიმულირებული CRM-ხედია: ექვსი პერსონის შემომავალი ყუთი, კონსოლი KPI-ებით, ტრენდით, განაწილებითა და კითხვების მიხედვით საშუალო შეფასებებით, ბუნდოვანი ძიებით აღჭურვილი პასუხების ლენტა, კამპანიების გვერდები და SMS-ების გაგზავნის ჟურნალი, რომლის ზედა ზოლიც სიმულაციას გამოკვეთილად აღნიშნავს.
API საცდელი გარემო, აგებული ორიგინალის პატარა დეველოპერული სატესტო გვერდიდან: სამი გამოძახება რედაქტირებადი JSON-ით, პასუხი, სტატუსი და დაყოვნება, და დემო-საათი, რომელიც ვადის გასვლას აჩქარებს.
აგენტის ანგარიშებს სერვერი ზღუდავს და არა ინტერფეისი: რა ფილიალი ან სახელიც არ უნდა ახლდეს ფილიალის თანამშრომლის მოთხოვნას, SMS-ის გაგზავნა მაინც მის საკუთარ ფილიალსა და სახელზეა დაბმული.
ორენოვანი ბოლო სტრიქონამდე: ინგლისური და ქართული ორივე სრულია, 725 ინტერფეისის სტრიქონით, ხოლო საწყისი მონაცემების ტექსტები, კითხვარის კითხვები და SMS-ების ტექსტები ორივე ენაზე არსებობს.

არქიტექტურა

SMS: ბიზნესის CRM აგზავნის შეტყობინებას პერსონალური ერთჯერადი ბმულით, სახით `https://<host>/?id=<token>`. გაგზავნა, ტოკენების გაცემა, ვადის წესები და შედეგების შენახვა სწორედ იქაა.
მიკროსაიტი: Next.js 15 (App Router) React 19-ზე, Tailwind CSS 3.4 და DaisyUI 4 ერთი საკუთარი თემით, Noto Sans Georgian კი `next/font`-ით. ყველა გვერდი კლიენტის კომპონენტია, მდგომარეობა — უბრალო `useState`: არც მდგომარეობის მართვის ბიბლიოთეკა, არც i18n ბიბლიოთეკა. დაახლოებით 700 სტრიქონი 24 ფაილში.
პროქსი-ფენა: სამი მარშრუტის დამმუშავებელი JSON-ს CRM-ის REST API-ს გადაუგზავნის (ვალიდაცია, გაგზავნა, კითხვების მიღება), სტატუსსა და სხეულს უცვლელად აბრუნებს, ქეშირებას თიშავს და ორივე მხარეს ლოგავს. ისინი ბრაუზერის CORS-ის ასარიდებლად დაემატა, რადგან პირველი ვერსია CRM-ს პირდაპირ ბრაუზერიდან იძახებდა.
ზედა ფენა: CRM-ის REST API, თითო ქვედომენი თითო კლიენტზე. მას ეკუთვნის კამპანიები, კითხვები და კითხვარის მდგომარეობა, და სწორედ ის აგზავნის შეტყობინებებს.
გაშვება: ჯერ სტატიკური ექსპორტი მრავალეტაპიან Docker აწყობაში (Node 20, შემდეგ nginx), მიმაგრებული TLS სერტიფიკატებით, SPA fallback-ით, gzip-ით, უსაფრთხოების სათაურებითა და სტატიკური რესურსების ერთწლიანი უცვლელი ქეშით. მარშრუტის დამმუშავებლები სტატიკურ ექსპორტში ვერ მუშაობს, ამიტომ მეორე ვერსია Next-ს სერვერულ რეჟიმში უშვებს nginx reverse proxy-ს უკან docker-compose-ით.
მრავალი კლიენტი: ერთი ინსტალაცია თითო კლიენტზე: კონფიგურაციის მოდული კომპანიის სახელით, API-ის საბაზო მისამართითა და ენდფოინთების გზებით, შეცვლილი ლოგოთი და ხატულათი და თემის ძირითადი ფერით.
დემო: იგივე ნაკადი, როგორც Vite + React ერთგვერდიანი აპლიკაცია (SPA), კითხვარის API-ის ბრაუზერისეულ სიმულაციაზე: ბანდლში ჩაშენებული საწყისი JSON, მეხსიერებისეული საცავი, როუტერი, რომელიც იმავე კონვერტებით პასუხობს, და თემა, რომელიც ტოკენის ბიზნესიდან იკითხება და არა თითო კლიენტის ცალკე ინსტალაციიდან.

ციფრებში

როლი: 3 · ეკრანი: 15 · სიმულირებული API მარშრუტი: 24 · ენა: 2 · ინტერფეისის სტრიქონი თითო ენაზე: 725 · საწყისი გამოკითხვის ბმული: 286 · TypeScript-ის სტრიქონი: 12k

შედეგები

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

რა გამოვიყენეთ

მიკროსაიტი: Next.js 15 (App Router), React 19, Tailwind CSS 3.4, DaisyUI 4 (ერთი საკუთარი თემა), Noto Sans Georgian, ჩატვირთული next/font-ით, კომპონენტის უბრალო მდგომარეობა, მდგომარეობის მართვისა და i18n ბიბლიოთეკების გარეშე
სერვერის მხარე: Next.js route handler-ები მსუბუქი პროქსის როლში, JSON CRM-ის REST API-ით, CRM-ის ერთი ქვედომენი თითო კლიენტზე
გაშვება და მიწოდება: Docker-ის მრავალეტაპიანი აწყობა (Node 20, შემდეგ nginx), nginx: SPA fallback, gzip და უსაფრთხოების სათაურები, docker-compose და reverse proxy, მიმაგრებული TLS სერტიფიკატები
დემოს აწყობა: Vite 6, React 18, TypeScript (strict), React Router 6, TanStack Query 5, Tailwind CSS 4, Radix UI, Framer Motion, Recharts 2, react-hook-form + zod, Fuse.js, i18next (EN / KA), date-fns, @portfolio/demo-kit (ბრაუზერში მომუშავე სიმულირებული API)

დემო

რეალური პროდუქტის გამოგონილი ბრენდით გადაკეთებული ვერსია, რომელიც Boulder-მა ააწყო და რომელიც ბექენდის გარეშე მუშაობს. Azri, მისი ხუთი ბიზნესი და ყველა მისამართი თუ ტელეფონის ნომერი გამოგონილია. კითხვარი რეალური პროდუქტის ნაკადია; შემომავალი ყუთი, კონსოლი და API საცდელი გარემო ჩვენი სიმულირებული CRM-ხედია მის გარშემო და ასე არის აღნიშნული, რადგან რეალური კამპანიები, ტოკენები და შედეგები სისტემაში იყო, რომლის ჩვენების უფლებაც ჩვენ არ გვაქვს. ყველაფერს ბრაუზერში მომუშავე სიმულაცია პასუხობს, საწყისი მონაცემები ბანდლშია ჩაშენებული, ამიტომ მონაცემები მეხსიერებაში ინახება, გადატვირთვა კი პირვანდელ საწყის მონაცემებს აბრუნებს. ქსელში არაფერი იგზავნება და SMS არასოდეს მიიტანება.

[ პროექტის ნახვა ↗ ]