ConnectWiz + Estesoft Stella

အသုံးပြုနိုင်ပြီးသား ချိတ်ဆက်မှု

Stella သည် သင်၏ CRM အဖြစ် ဆက်ရှိသည်။ ယခုမူ စကားဝိုင်းများက ၎င်းကို သိလာပြီ။

မည်သည့် provider နှင့်မဆို အလုပ်လုပ်နိုင်သော ကျွန်ုပ်တို့၏ CRM port ပေါ်ရှိ ပထမဆုံး provider: စကားဝိုင်းတိုင်းအတွင်း Estesoft Stella မှ တိုက်ရိုက် ဖောက်သည် context၊ Stella ရက်ချိန်းစာအုပ်သို့ ပြန်ရေးသွင်းသော ရက်ချိန်းများ — ထို့အပြင် ဆက်သွယ်ရေး ထုတ်ကုန်တစ်ခုက မည်သည့်အခါမျှ မထိသင့်သည့်အရာများနှင့် ပတ်သက်၍ စာဖြင့် ရေးသားထားသော ရည်ရွယ်ချက်ရှိရှိ ငြင်းဆိုချက်များ။

Identity ဖြင့် ကန့်သတ်ထားသော context ရက်ချိန်းများ ပြန်ရေးသွင်းသည် ဆေးဘက်ဆိုင်ရာ ဒေတာ: မည်သည့်အခါမျှ မဖတ်
Estesoft Stella × ConnectWiz
ဤဖောက်သည်အတွက်သာ ကန့်သတ်ထားသည်
ရက်ချိန်း · ဈေးနှုန်းကမ်းလှမ်းချက် · ပေးရန်ကျန်ငွေ မြင်ရသည်
Chat ရက်ချိန်း → Stella ရက်ချိန်းစာအုပ်
ကုသမှု မှတ်တမ်းများ: မည်သည့်အခါမျှ မဖတ်
10
အမည်ဖြင့် သတ်မှတ်ထားသော ဖတ်ရှုလုပ်ဆောင်ချက်များ — ရက်ချိန်း၊ ဈေးနှုန်းကမ်းလှမ်းချက်၊ အော်ဒါ၊ ပေးရန်ကျန်ငွေ၊ မှတ်စု၊ စာရွက်စာတမ်း၊ ကတ်တလောက်၊ ဝန်ထမ်း၊ တည်နေရာ၊ ဖောက်သည် ရှာဖွေခြင်း
7
သတ်မှတ်ထားသော ရေးသွင်းလုပ်ဆောင်ချက်များ — ၆ ခု ဖွင့်ထားပြီး ၁ ခုကို တိုင်းတာပြီးသည်အထိ ဆိုင်းထားသည်၊ မည်သည့်တစ်ခုဖြစ်ကြောင်းလည်း ဖော်ပြထားသည်
4
ရေးသွင်းမှုတိုင်းရှိ စစ်ဆေးရေးဂိတ်များ — adapter၊ capability၊ လုပ်ဆောင်ချက်အလိုက် switch၊ ဒေတာ ပိုင်ဆိုင်မှု
5
ပြောင်းရွှေ့ခြင်း engine က သယ်ဆောင်ပေးသော မှတ်တမ်းအမျိုးအစားများ — ရက်ချိန်း၊ ဈေးနှုန်းကမ်းလှမ်းချက်၊ အရောင်း၊ ရရန်ငွေ၊ မှတ်စု

CRM

လုပ်ဆောင်ပေးသည့်အရာ — အတိအကျ

တိုက်ရိုက် context — identity ဖြင့် ကန့်သတ်ထားသည်

ဤဖောက်သည်၏ ရက်ချိန်းများ၊ ဈေးနှုန်းကမ်းလှမ်းချက်များ၊ ပေးရန်ကျန်ငွေ၊ မှတ်စုများနှင့် စာရွက်စာတမ်းများသည် စကားဝိုင်းပေါ်တွင် ပေါ်လာသည် — AI ကလည်း ၎င်းတို့ကို ဤဖောက်သည်အတွက်သာ အတိအကျ ဖတ်နိုင်ပြီး ဖောက်သည်ကို ခန့်မှန်းထားသော ID မှ မဟုတ်ဘဲ စကားဝိုင်းကိုယ်တိုင်မှ ဖော်ထုတ်သည်။

ရက်ချိန်းများ ပြန်ရေးသွင်းသည်

Chat တွင် ယူထားသော ရက်ချိန်းသည် Stella ၏ ရက်ချိန်းစာအုပ်ထဲ ရောက်သည် — vendor ၏ API က အသေးစိတ်တစ်ခုကို မသယ်ဆောင်နိုင်သည့်နေရာတွင် sync က ၎င်းကို တိတ်တဆိတ် ချန်ထားခဲ့မည့်အစား ဘာကို ချန်ခဲ့သည်ကို ပြောပြသည်။

AI သည် ဖတ်ရုံသာ၊ မည်သည့်အခါမျှ မရေး

CRM port တစ်ခုလုံးအတွက် အမြဲတမ်း စည်းမျဉ်း: ဖတ်ခြင်းကို identity ဖြင့် ကန့်သတ်ထားပြီး ရေးသွင်းခြင်းကို လူကသာ လုပ်သည် — ပေးရန်ကျန်ငွေကို မှားဖတ်နိုင်သော AI သည် လူနာမှားကို ရက်ချိန်းပေးမိမည့် AI ၏ ကုန်ကျစရိတ်နည်းသော အစမ်းလေ့ကျင့်မှုသာ ဖြစ်သည်။

သင်ရွေးသည့်အချိန်တွင် ပြောင်းရွှေ့ခြင်း

တန်းစီပြီး ရပ်ရာမှ ပြန်ဆက်နိုင်သော engine က ရက်ချိန်းများ၊ ဈေးနှုန်းကမ်းလှမ်းချက်များ၊ အရောင်းများ၊ ရရန်ငွေများနှင့် မှတ်စုများကို ConnectWiz ထဲ import လုပ်သည် — ကျော်သွားသည်များကို အမည်ဖြင့် အစီရင်ခံပြီး ဒေတာ ပိုင်ဆိုင်မှုကို နောက်ဆုံးအဆင့်တွင်သာ ပြောင်းသည်။

ငွေပေးချေမှုနှင့် အော်ဒါများ ပြန်ရေးသွင်းသည်

ConnectWiz တွင် ငွေပေးချေမှု မှတ်တမ်းတင်ခြင်း သို့မဟုတ် အော်ဒါ ဖန်တီးခြင်းကို Stella သို့ ပို့နိုင်သည် — ပိုင်ရှင်၏ ရှင်းလင်းသော ဆုံးဖြတ်ချက်ဖြင့်သာ ဖွင့်ပြီး အခြားအရာအားလုံးကဲ့သို့ပင် စစ်ဆေးရေးဂိတ် ၄ ခုနှင့် rehearse mode နောက်တွင် ထားရှိသည်။

အပြောင်းအလဲကိုသာ ယူသည် — ထပ်တူမိတ္တူ မဟုတ်

Change polling ရှိသည်မှာ လွတ်သွားသော event များကို ဖမ်းရန်သာ ဖြစ်သည် — ဆေးခန်း၏ လယ်ဂျာကို ဒုတိယ မိတ္တူအဖြစ် ထိန်းထားရန် မဟုတ်ပါ။ ထိုခြားနားချက် ပျောက်သွားလျှင် cache တစ်ခုသည် database ဖြစ်လာတတ်သောကြောင့် စာဖြင့် ရေးမှတ်ထားသည်။

နည်းပညာပိုင်း

ရေးသွင်းလမ်းကြောင်း: စစ်ဆေးရေးဂိတ် ၄ ခုနှင့် အစမ်းလေ့ကျင့်မှု တစ်ခု

လုပ်ဆောင်ချက်တိုင်း မူလအားဖြင့် ပိတ်ထားသည်

ရေးသွင်းမှုတိုင်းကို ပိတ်ထားသော အခြေအနေဖြင့် ပေးပို့ပြီး လုပ်ဆောင်ချက် ၇ ခု (မှတ်စု၊ ရက်ချိန်း၊ ဖျက်သိမ်းခြင်း၊ ဖောက်သည်၊ ဈေးနှုန်းကမ်းလှမ်းချက်၊ အော်ဒါ၊ ငွေပေးချေမှု) တစ်ခုစီတွင် ကိုယ်ပိုင် switch ရှိသည်။ ဤနေရာတွင် ဘေးကင်းမှုဆိုသည်မှာ မရှိခြင်း ဖြစ်သည်: ဂိတ်တစ်ခု မအောင်မြင်လျှင် ခေါ်စရာ writer object ပင် မရှိပါ။

ပိုင်ဆိုင်မှုသည် switch ထက် အဆင့်မြင့်သည်

လုပ်ဆောင်ချက်အလိုက် switch များအထက်တွင် ဒေတာ ပိုင်ဆိုင်မှု ရှိသည်: သင့် workspace ပိုင်သော domain သည် switch က ဘာပြောပါစေ Stella သို့ မည်သည့်အခါမျှ ရေးမထုတ်ပါ။ ဂိတ်များ၏ အစီအစဉ်ကို ပုံသေ သတ်မှတ်ပြီး မှတ်တမ်းတင်ထားသည်။

တကယ့် code လမ်းကြောင်းပေါ်တွင် အစမ်းလေ့ကျင့်သည်

Dry-run mode သည် တကယ့် ရေးသွင်းမှုက ပို့မည့် payload အတိအကျကို တည်ဆောက်ပြီး transport အဆင့်တွင်သာ ရပ်သည် — code လမ်းကြောင်း မတူသော အစမ်းလေ့ကျင့်မှုသည် ဘာကိုမျှ သက်သေမပြနိုင်သောကြောင့် ထိုသို့သော လမ်းကြောင်း မရှိပါ။

ရေးသွင်းမှုများက မိမိကိုယ်ကို စစ်ဆေးသည်

ရေးသွင်းမှုတိုင်းပြီးနောက် ချိတ်ဆက်မှုက ၎င်းဖန်တီးခဲ့သည်ကို ပြန်ဖတ်ပြီး နှိုင်းယှဉ်သည်။ မကိုက်ညီမှုကို လူအတွက် သတိပေးချက်အဖြစ် ပြသည် — အလိုအလျောက် ပြင်ဆင်ခြင်း မည်သည့်အခါမျှ မလုပ်ပါ၊ vendor API တွင် ပြင်ဆင်ခြင်းကို ဘေးကင်းစေမည့် idempotency key မရှိသောကြောင့် ဖြစ်သည်။

မှန်ကန်သော အစီအစဉ်ဖြင့် ပြောင်းရွှေ့ခြင်း

ရက်ချိန်းများကို ဦးစွာ import လုပ်သည် — တမင်ပင် ဖြစ်သည်၊ tenant တစ်ခုလုံးရှိ လူများကို ရှာဖွေတွေ့ရှိနိုင်သော တစ်ခုတည်းသော နေရာမှာ ရက်ချိန်းစာအုပ် ဖြစ်သောကြောင့် ဖြစ်သည်။ ကျော်သွားသော row တိုင်းကို အမည်ဖြင့် စာရင်းပြုစုသည်: အချိန်ကာလ မရှိ၊ ပုံစံ မသိ၊ အဆက်အသွယ် မရှိ။

AI ဖတ်ခြင်းကို အဆင့် ၃ ဆင့် သော့ခတ်ထားသည်

AI ၏ CRM tool သည် သင့် workspace တွင် တကယ်ရှိသော action များကိုသာ ဖော်ပြပြီး ခေါ်ချိန်တွင် action ကို ထပ်မံ စစ်ဆေးကာ ဖောက်သည်ကို စကားဝိုင်းကိုယ်တိုင်မှ ဖော်ထုတ်သည် — AI စိတ်ကူးယဉ်ထားသော ရွေးချယ်စရာ သို့မဟုတ် ခန့်မှန်းထားသော ID သည် transport မရောက်မီ ပျက်သွားသည်။

တပ်ဆင်ခြင်း

ချိတ်ဆက်ပုံ

01

Stella ကို ချိတ်ဆက်ပါ

သင့် Stella credential များကို ထည့်ပါ။ မည်သည့်အရာမျှ မသိမ်းမီ connector က လက်တွေ့ API နှင့် စစ်ဆေးအတည်ပြုသည်။

02

Context ဖြင့် အလုပ်လုပ်ပါ

စကားဝိုင်းများတွင် ဖောက်သည်၏ CRM ကတ် ပေါ်သည်။ ဝန်ထမ်းများနှင့် AI သည် မှတ်ဉာဏ်မှ မဟုတ်ဘဲ အချက်အလက်မှန်များမှ ဖြေကြားသည်။

03

လိုမှ၊ လိုသည့်အချိန်မှ ပြောင်းရွှေ့ပါ

မှတ်တမ်းအပြည့်အစုံကို ယူဆောင်လာရန် အကူအညီပါသော ပြောင်းရွှေ့ခြင်းကို run ပါ — ပိုင်ဆိုင်မှုကို သင်ပြောင်းသည်အထိ စနစ်ဟောင်းသည် အဓိကမှတ်တမ်းအဖြစ် ဆက်ရှိနေသည်။

တွဲသုံးလျှင် ပိုကောင်း

တွဲဖက်အလုပ်လုပ်နိုင်သည့် အရာများ

ရက်ချိန်းစနစ်

Chat မှ ယူသော ရက်ချိန်းများသည် Stella ရက်ချိန်းစာအုပ်ထဲ ရောက်သည်။ Stella ရက်ချိန်းများကို အားလပ်ချိန်မှ နုတ်ပေးသည်မှာ ရက်ချိန်းစနစ် ဖြစ်သည် — ရက်ချိန်းစာအုပ်၏ အမှန်မှာ တစ်ခုတည်းသာ ရှိသည်။

Inbox ကတ်

ဖောက်သည်၏ တိုက်ရိုက် CRM context ဖြစ်သော ရက်ချိန်းများ၊ ဈေးနှုန်းကမ်းလှမ်းချက်များနှင့် ပေးရန်ကျန်ငွေကို စကားဝိုင်းဘေးတွင် ဝန်ထမ်းများ မြင်ရသည့်နေရာမှာ မျှဝေသုံး Inbox။

Wiz — ဖတ်ရုံသာ

ConnectWiz ၏ AI agent သည် "ရက်ချိန်းက ဘယ်နေ့လဲ" ကဲ့သို့ မေးခွန်းများကို Stella ရှိ အချက်အလက်များမှ ဖြေသည် — စကားဝိုင်းထဲရှိ လူတစ်ဦးတည်းအတွက်သာ identity ဖြင့် ကန့်သတ်ထားပြီး အမြဲတမ်း စည်းမျဉ်းအရ ရေးသွင်းခွင့် မရှိပါ။

လုံခြုံရေးနှင့် အာမခံချက်များ

ပျင်းစရာကောင်းလောက်အောင် ခိုင်မာသော အာမခံချက်များ

ကျန်းမာရေး ဒေတာ: မည်သည့်အခါမျှ မဖတ်

ကုသမှု မှတ်တမ်းများသည် KVKK အရ အထူးအမျိုးအစား ဒေတာ ဖြစ်သည်။ ၎င်းတို့ကို support မျက်နှာပြင်ထဲ ဖတ်သွင်းပါက ဒေတာကို ကိုင်တွယ်သူများကို ဆေးခန်း၏ ဆရာဝန်များမှ အဖွဲ့တစ်ခုလုံးအထိ ချဲ့ထွင်ရာ ရောက်မည် — ထို့ကြောင့် endpoint များ ရှိသော်လည်း ၎င်းတို့ကို စာဖြင့် ရေးသား၍ ငြင်းဆိုထားသည်။

မမြင်ရသော လက်များ မရှိ

ဆေးခန်း၏ task များကို မည်သည့်အခါမျှ မပိတ်၊ ၎င်း၏ ဖောက်သည် segment များကို မည်သည့်အခါမျှ မပြောင်း၊ ၎င်း၏ စာရင်းကိုင် လယ်ဂျာကို မည်သည့်အခါမျှ မထိပါ — တစ်ခုချင်းစီမှာ မှတ်တမ်းတင်ထားသော ငြင်းဆိုချက် ဖြစ်သည် — အခြားသူ၏ လုပ်ငန်းစဉ်ကို chat မှ အလိုအလျောက် လုပ်ဆောင်ခြင်းသည် ဤထုတ်ကုန်တွင် အကုန်ကျဆုံး အမှားအမျိုးအစား ဖြစ်သောကြောင့် ဖြစ်သည်။

Token များကို URL ထဲ မထည့်

Vendor တွင် credential များကို URL ထဲ ထည့်ရသော token-check endpoint တစ်ခု ရှိသည် — ထိုနေရာတွင် log နှင့် proxy များက ၎င်းတို့ကို မြင်နိုင်သည်။ ကျွန်ုပ်တို့ ၎င်းကို မည်သည့်အခါမျှ မခေါ်ပါ။ Credential ကိုင်တွယ်ပုံကို endpoint တစ်ခုချင်းအလိုက် ရွေးချယ်ထားသည်။

ဖျက်ခြင်း: မပေးပါ

ဖောက်သည်၊ Lead၊ ငွေတောင်းခံလွှာနှင့် ဈေးနှုန်းကမ်းလှမ်းချက်များအတွက် vendor ၏ delete endpoint များကို မသုံးပါ — soft delete လား hard delete လား ဆိုသည့် အပြုအမူကို အတည်မပြုရသေးသလို လူနာမှတ်တမ်းကို ဖျက်ခြင်းသည် ကျွန်ုပ်တို့ တာဝန်ယူလိုသော မည်သည့် user story တွင်မျှ မပါဝင်ပါ။

မဖုံးကွယ်ထားသော အသေးစိတ်များ

ရှင်းလင်းစွာ ဖော်ပြထားသော ကန့်သတ်ချက်များ

ရည်ရွယ်ချက်ရှိရှိ ငြင်းဆိုထားသည်များ

ဆေးကုသမှု မှတ်တမ်းများကို မည်သည့်အခါမျှ မဖတ်၊ မပြသ၊ vendor ၏ lifecycle label များကို မည်သည့်အခါမျှ ထပ်မရေး၊ နှစ်ဘက်သွား mirror အပြည့်အစုံ ရှိသယောင်လည်း ဟန်မဆောင်ပါ — ငြင်းဆိုချက်တိုင်းမှာ လစ်ဟာချက် မဟုတ်ဘဲ မှတ်တမ်းတင်ထားသော ဒီဇိုင်း ဆုံးဖြတ်ချက် ဖြစ်သည်။

အခြား CRM များ

ဤ port ကို မည်သည့် provider နှင့်မဆို အလုပ်လုပ်နိုင်အောင် ဒီဇိုင်းထုတ်ထားသည် — Stella သည် ပထမဆုံး provider သာ ဖြစ်ပြီး နောက်ဆုံး မဟုတ်ပါ။ အခြား CRM သုံးနေပါသလား။ ကျွန်ုပ်တို့ကို ပြောပါ — ၎င်းက တန်းစီစာရင်းကို ပုံဖော်ပေးသည်။

Estesoft Stella FAQ

တိုက်ရိုက်အဖြေများ

နောက်ထပ်အချက်များကို အပြည့်အစုံပါသော FAQ တွင် ဖတ်ပါ၊ သို့မဟုတ် ကျွန်ုပ်တို့ကို တိုက်ရိုက်မေးပါ။

ဖောက်သည်ကိုယ်တိုင်၏ ရက်ချိန်းများ၊ ဈေးနှုန်းကမ်းလှမ်းချက်များ၊ အော်ဒါများ၊ ပေးရန်ကျန်ငွေ၊ မှတ်စုများနှင့် စာရွက်စာတမ်းများကို ၎င်းတို့ စကားပြောနေသော စကားဝိုင်းပေါ်တွင် ပြသည် — ထို့အပြင် AI ဖြေကြားနိုင်ရန် လုပ်ငန်း၏ ကတ်တလောက်၊ ဝန်ထမ်းများနှင့် တည်နေရာများကိုလည်း ပြသည်။ ဖတ်ခြင်းအားလုံးကို စကားဝိုင်းထဲရှိ ဖောက်သည်အတွက်သာ ကန့်သတ်ထားသည်။

စည်းမျဉ်းအရ ဖြစ်သည်: ဤ port တွင် AI သည် ဖတ်ရုံသာ ဖြစ်ပြီး ဖတ်ခြင်းကို identity ဖြင့် ကန့်သတ်ထားသည်။ ဆေးခန်း၏ CRM ထဲ မှားယွင်းစွာ ရေးသွင်းခြင်းသည် လက်တွေ့ဘဝ ဖြစ်ရပ်တစ်ခု ဖြစ်သောကြောင့် ရေးသွင်းခြင်းကို လူကသာ လုပ်ပြီး စစ်ဆေးနိုင်အောင် ထားသည်။

ထားနိုင်ပါသည် — ပြောင်းရွှေ့ခြင်း engine က ရက်ချိန်းများ၊ ဈေးနှုန်းကမ်းလှမ်းချက်များ၊ အရောင်းများ၊ ရရန်ငွေများနှင့် မှတ်စုများကို တန်းစီပြီး ပြန်ဆက်နိုင်သော run တစ်ခုဖြင့် import လုပ်ကာ ကျော်သွားသည်များကို အမည်ဖြင့် အစီရင်ခံသည်။ ပိုင်ဆိုင်မှုကို ရှင်းလင်းသော နောက်ဆုံးအဆင့်အဖြစ်သာ လွှဲပြောင်းသောကြောင့် ဘာမျှ တစ်ဝက်တစ်ပျက် ပြောင်းရွှေ့ခြင်း မရှိပါ။

၆ ခု ဖြစ်သည်: ဖောက်သည် မှတ်စု၊ ရက်ချိန်း (ဖန်တီးခြင်းနှင့် ဖျက်သိမ်းခြင်း)၊ ဖောက်သည်အသစ်၊ ဈေးနှုန်းကမ်းလှမ်းချက်၊ အော်ဒါနှင့် ငွေပေးချေမှု — တစ်ခုစီတွင် ကိုယ်ပိုင် switch ရှိပြီး အားလုံး မူလအားဖြင့် ပိတ်ထားကာ အားလုံး rehearse mode ဖြင့် စတင်သည်။ ဖိုင် upload ကို သတ်မှတ်ထားသော်လည်း vendor endpoint ၏ အပြုအမူကို မတိုင်းတာရသေးသဖြင့် ပိတ်ထားဆဲ ဖြစ်သည် — ၎င်းမှာ ဆုံးဖြတ်ချက် မဟုတ်ဘဲ တိုင်းတာမှု လိုအပ်ချက်သာ ဖြစ်သည်။

ကျော်သွားမှုတိုင်းကို အမည်ဖြင့် စာရင်းပြုစုသည်: ရွေးထားသော အချိန်ကာလ ပြင်ပရှိ row များ၊ engine က ပုံစံကို မသိသော row များ၊ ကိုက်ညီအောင် ရှာမတွေ့သော ဖောက်သည်ကို ဖော်ပြထားသော row များ။ ထိုစာရင်းသည်ပင် အစီရင်ခံစာ ဖြစ်သည် — ပြောင်းရွှေ့ခြင်း ပြီးဆုံးချိန်တွင် ဘာ မပြောင်းရွှေ့ခဲ့သည်နှင့် အဘယ်ကြောင့်ဆိုသည်ကို သင် သိပြီး ဖြစ်မည်။

ရိုးသားစွာ ချိတ်ဆက်ခြင်းသည် ကျယ်လောင်စွာ ကြွေးကြော်ခြင်းထက် သာသည်။

ဤနေရာရှိ ချိတ်ဆက်မှုတိုင်းကို ၎င်းတကယ်လုပ်ဆောင်သည့်အတိုင်း ဖော်ပြထားသည် — ဒေတာသွားရာ ဦးတည်ချက်၊ ပိုင်ဆိုင်မှုနှင့် ကန့်သတ်ချက်များ အပါအဝင်။