Whisperr მარტივი ახსნა

ერთ გვერდზე · მარტივად · ნაბიჯ-ნაბიჯ

Whisperr — რა არის, როგორ მუშაობს და რა გავაკეთოთ

Whisperr ეხმარება ბიზნესს, შეინარჩუნოს მომხმარებლები — ავტომატურად შეამჩნიოს ვინ აპირებს წასვლას და დროულად „ჩასჩურჩულოს" სწორი შეტყობინება.

ბიზნესი უგზავნის Whisperr-ს მონაცემს, თუ რას აკეთებენ მისი მომხმარებლები. Whisperr ხვდება ვინ არის „გასაფრენად" მზად, წყვეტს გაუგზავნოს თუ არა შემახსენებელი/შემოთავაზება, ქმნის ტექსტს, აგზავნის და ზომავს — გამოვიდა თუ არა.

დევიზი: ერთი მოვლენა → ერთი გადაწყვეტილება → ერთი ინტერვენცია

1. მთავარი Flow — ნაბიჯ-ნაბიჯ

ეს არის მთელი გზა, დასაწყისიდან ბოლომდე. თითო ნაბიჯს აწერია სტატუსი: მზადაა ნაწილობრივ აკლია

1

მოზიდვა და კვალიფიკაცია მზადაა

Landing (whisperr.net) — სარეკლამო საიტი: churn-კალკულატორები, ხმოვანი „აგენტი", waitlist. აქ პოტენციური კლიენტი ერთვება.

2

რეგისტრაცია მზადაა

App — კლიენტი ქმნის ანგარიშს (Organization → App). შენიშვნა: საიტიდან აპლიკაციაში გადასვლა „ცივია" — შეგროვებული ინფო არ გადააქვს (გასაუმჯობესებელი).

3

Onboarding — AI საუბარი მზადაა

App + BFF — AI ესაუბრება კლიენტს, იგებს ბიზნესს, ირჩევს რომელ მოვლენებს ადევნოს თვალი და რომელი ინტერვენციები გამოიყენოს. 3 ეტაპი: გაცნობა → მოვლენების არჩევა → წონების გამოთვლა.

4

გადატანა + კონფიგურაციის აწყობა მზადაა

Runtime (Go ბირთვი) — დასრულებული onboarding გადადის ბირთვში; AI აწყობს მოვლენების „სამყაროს" და გადაწყვეტილების წესებს (policy). გაშვებამდე სავალდებულოა სიმულაცია (უსაფრთხოებისთვის).

5

კოდში ჩაშენება თითქმის მზადაა

Wizard (npx) — AI ინსტრუმენტი შედის კლიენტის კოდში და თავად ამატებს event-ების გაგზავნას სწორ ადგილებში. SDK-ები (web/next/react) გამოქვეყნებულია; ზოგი პლატფორმა ჯერ დასაშენებელია.

6

მოვლენების მიღება მზადაა

Runtime — კლიენტის მომხმარებლების ქმედებები (events) შემოდის (თითო ან ჯგუფურად). ინახება უცვლელად, დუბლების გარეშე.

7

გადაწყვეტილება მზადაა

Runtime (engine) — ყოველ მოვლენაზე ხელახლა ითვლება ქულა (LLM-ის გარეშე, სწრაფად). შემდეგ: უნდა გავიდეს თუ არა → რომელი ინტერვენცია მოიგებს → რომელი არხი. აქვს „მოსვენების" წესები (ზედმეტად ხშირად არ აწუხებს).

8

ტექსტის გენერაცია მზადაა

Runtime (AI) — იქმნება შეტყობინების ტექსტი. აქვს დამტკიცების რეჟიმი: ან ადამიანი ამტკიცებს (manual), ან ავტომატურად იგზავნება (autonomous).

9

მიწოდება ნაწილობრივ

Runtime → პროვაიდერებიEmail (Postmark) და Push (FCM/OneSignal) მუშაობს. SMS, in-app და voice ჯერ არ არის.

10

შედეგის გაზომვა და სწავლა ნაწილობრივ

Runtime — ვზომავთ გაიხსნა/დააჭირა თუ არა და მიაღწია თუ არა მიზანს; სისტემა სწავლობს რომელი არხი მუშაობს. დღეს მხოლოდ email-ისთვის; push-ს უკუკავშირი აკლია.

11

ზედამხედველობა მზადაა

Dashboard (კლიენტი) + Backoffice (ოპერატორი) — კლიენტი ხედავს სტატისტიკას; ოპერატორი მართავს მთელ ციკლს, ამტკიცებს, არეგულირებს წესებს.

2. რა მუშაობს დღეს და რა აკლია

გულწრფელი სურათი — კოდიდან შემოწმებული.

მუშაობს

  • სარეკლამო საიტი + waitlist
  • AI onboarding (სრული)
  • კონფიგურაცია + policy (სიმულაციით დაცული)
  • Event-ების მიღება + გადაწყვეტილება
  • ტექსტის გენერაცია + დამტკიცება
  • Email მიწოდება (უკუკავშირით)
  • Push მიწოდება
  • Dashboard + Backoffice

აკლია / სუსტია

  • ROI / „დაბრუნებული შემოსავალი" — მთავარი გასაყიდი ციფრი (არ არსებობს)
  • აგრეგირებული ანალიტიკა
  • SMS, in-app, voice არხები
  • Push-ის უკუკავშირი
  • გადახდა/ტარიფები (billing) — საერთოდ არ არის
  • მონაცემის წაშლა (GDPR) — არ არის
  • App-ის ნამდვილი auth (ახლა mock)
  • ერთიანი API კონტრაქტი, ტესტები
💡 მთავარი აზრი: სისტემის „ხერხემალი" (onboarding → გადაწყვეტილება → email/push მიწოდება → სწავლა) მაგარია და მუშაობს. გადაწერა არ სჭირდება. საჭიროა ციკლის დახურვა ყველა არხზე, უსაფრთხოების გამაგრება და შედეგის დამტკიცება ციფრებით.

3. ჩემი რეკომენდებული გადაწყვეტილებები

ღია საკითხები — და ჩემი მკაფიო რჩევა თითოზე.

ავტომატური თუ ხელით დამტკიცება ახალი კლიენტისთვის?

ხელით დამტკიცება (manual) ნაგულისხმევად. ნდობა და უსაფრთხოება ჯერ; მერე თითო კლიენტს ჩავურთოთ ავტომატური, როცა შედეგი დაგვარწმუნებს.

SMS არხი ავაშენოთ თუ ვიყიდოთ?

ვიყიდოთ (Twilio). ტელეკომი თვითონ არ ავაშენოთ — უკვე არსებობს კანონისმიერი „ჩუმი საათების" წესი კოდში, პროვაიდერის ჩართვა რჩება.

Deploy — Azure თუ droplet?

ერთი აირჩიე: Azure Container Apps. ორი პარალელური pipeline რისკია; droplet ჩამოხსენი (Azure-ს უკვე აქვს migration-ით დაცული deploy).

გადახდა/ტარიფები (billing)?

Stripe + entitlement სერვისი. ლიმიტები (MAU/events) დააწესე event-ების მიღებაზე, ხოლო ჩვენება — dashboard-ზე. ტარიფები იყიდება, მაგრამ კოდში არ არსებობს — პრიორიტეტია.

მომხმარებლის მონაცემის წაშლა (GDPR)?

აუცილებელია ახლავე. გავაკეთოთ „anonymize-in-place" — PII წაიშალოს/დაანონიმდეს, სტატისტიკა კი დარჩეს. კანონის მოთხოვნაა.

ML (ჭკვიანი პროგნოზი) და Voice?

მოგვიანებით. ML ჩავრთოთ „ჩრდილში" (shadow mode) — ჯერ ვადარებთ, მერე ვანდობთ. Voice/Recall ახლა demo-დ დავტოვოთ. ორივე M5-ზე.

4. რითი დავიწყოთ — თანმიმდევრობა

დამოკიდებულებების მიხედვით დალაგებული. ჯერ იაფი და გამხსნელი, მერე ღირებულების დამამტკიცებელი.

M0
საფუძვლებიგავასწოროთ mock/ნამდვილის აღრევა, ერთიანი API კონტრაქტი, „თბილი" handoff საიტიდან, ერთი deploy pipeline. იაფია, ბევრს ხსნის.
M1
უსაფრთხოებაApp-ის ნამდვილი auth, გასაღებების დონეები (scoped keys), backoffice RBAC, tenant-იზოლაციის ტესტი.
M2
დავამტკიცოთ ღირებულებაattribution + ანალიტიკა → „დაბრუნებული შემოსავალი". Push-ის უკუკავშირი. ეს ხსნის მთავარ გასაყიდ არგუმენტს + Billing.
M3
დავასრულოთ არხებიSMS (Twilio), in-app, კონტენტის fact-provenance (რომ არ „მოიგონოს" ციფრები).
M4
თვით-მომსახურებაwizard-ის მთელი გზა production-ზე დავამოწმოთ + დარჩენილი SDK-ები.
M5
ინტელექტიML „ჩრდილში" + Voice/Recall როგორც ნამდვილი არხი.
M6
მასშტაბი და კანონიმონაცემის შენახვის ვადები, ყველა ფონური სამუშაო რიგში (queue), წარმადობა.