ဖောက်သည် feedback portal တည်ဆောက်နည်း: အိုင်ဒီယာများ၊ မဲများနှင့် အခြေအနေ အပ်ဒိတ်များ

ဖောက်သည် feedback portal ဆိုသည်မှာ ဖောက်သည်များက အိုင်ဒီယာများ တင်ပြီး တစ်ဦးနှင့်တစ်ဦး မဲပေးကာ မည်သည့်တောင်းဆိုမှုများ စီစဉ်ထားသလဲ၊ လုပ်ဆောင်နေသလဲ၊ ပို့ပြီးသလဲ ကြည့်နိုင်သည့် အများပြည်သူ board တစ်ခု ဖြစ်သည်။ တည်ဆောက်ရန်အတွက် အခြေအနေများပါသော post များ၊ လူတစ်ဦးနှင့် ချိတ်ထားသော မဲများ၊ comment များ၊ ထပ်နေသည်များကို ပေါင်းရန် နည်းလမ်း၊ triage အတွက် admin view နှင့် တစ်ခုခု ပို့သောအခါ မဲပေးသူများကို အသိပေးနိုင်ရန် နည်းလမ်း လိုအပ်သည်။ တည်ဆောက်ခြင်းကိုယ်တိုင်က ရိုးရှင်းသည်။ portal ကို အကျိုးရှိစေမည်လားဆိုတာကို ဆုံးဖြတ်သည်မှာ သင်ဘယ်လို လည်ပတ်သလဲ ဖြစ်သည်- မြန်ဆန်သော triage၊ သစ္စာရှိသော အခြေအနေများနှင့် loop ကို ပိတ်ခြင်း။

အဖွဲ့များ portal တည်ဆောက်ရသည့် အကြောင်းရင်း

Feedback များသည် များသောအားဖြင့် နေရာအနှံ့ တစ်ပြိုင်နက် ရောက်လာသည်- support အီးမေးလ်များ၊ sales ခေါ်ဆိုမှုများ၊ chat၊ social post များ။ portal က ၎င်းကို နေရာတစ်ခုတည်းတွင် စုစည်းပေးပြီး မဲပေးခြင်းက လူများစွာ မျှဝေသော တောင်းဆိုချက်များကို ပြသသည်။ post များ တကယ်ရွေ့လျားနေသရွေ့ ဖောက်သည်များကို တစ်စုံတစ်ယောက် နားထောင်နေကြောင်းလည်း ပြသသည်။ တစ်နှစ်လုံး "Under review" တွင် ပိတ်မိနေသော အိုင်ဒီယာများဖြင့် ပြည့်နေသော board သည် board မရှိသည်ထက် ပိုဆိုးသည်။

တည်ဆောက်မီ portal ၏ ရည်ရွယ်ချက်ကို ဆုံးဖြတ်ပါ-

အိုင်ဒီယာနှင့် bug များ စုဆောင်းခြင်း သို့မဟုတ် အိုင်ဒီယာသာလား။ bug report များ ရောနှော်ခြင်းက portal ကို support queue ဒုတိယတစ်ခု ဖြစ်စေတတ်သည်။
Public သို့မဟုတ် private လား။ public board များက ပါဝင်မှုကို ပိုဖိတ်ခေါ်သည်။ private (sign-in ပြီးမှ ဖောက်သည်သာ) များက အထိခိုက်မခံသော တောင်းဆိုချက်ရှိသော B2B ထုတ်ကုန်များနှင့် သင့်တော်သည်။
Public roadmap ရှိသလား။ "Planned" နှင့် "In progress" ပြခြင်းက မျှော်လင့်ချက် သတ်မှတ်ပေးသည်၊ ထို့ကြောင့် တာဝန်ယူနိုင်သည်များကိုသာ ပြပါ။

Portal တွင် လိုအပ်သည်များ

ဒေတာ

Table	အဓိက fields
Posts	ခေါင်းစဉ်၊ ဖော်ပြချက်၊ ရေးသူ၊ board သို့မဟုတ် အမျိုးအစား၊ အခြေအနေ၊ မဲအရေအတွက်၊ ဖန်တီးသည့်အချိန်၊ ပေါင်းထည့်ထားသည့်နေရာ (ရွေးချယ်စရာ)
Votes	Post၊ user၊ ဖန်တီးသည့်အချိန် (post တစ်ခုလျှင် user တစ်ဦး မဲတစ်ခု)
Comments	Post၊ ရေးသူ၊ စာသား၊ တရားဝင် ပြန်စာ ဟုတ်/မဟုတ်
Users	အမည်၊ အီးမေးလ်၊ အတည်ပြုပြီးလား၊ ကုမ္ပဏီ (B2B အတွက်)၊ admin ဟုတ်/မဟုတ်
Categories	အမည် (ဥပမာ Reporting၊ Integrations၊ Mobile)
Status changes	Post၊ အဟောင်း အခြေအနေ၊ အသစ် အခြေအနေ၊ မှတ်စု၊ ပြောင်းလဲသူ၊ ရက်စွဲ

မှတ်စုတိုတိုပါသော အခြေအနေပြောင်းလဲမှု မှတ်တမ်း ကို ထိန်းသိမ်းပါ။ ၎င်းက အသိပေးအီးမေးလ်များကို ပါဝင်ကူညီပြီး ဖောက်သည်များအား အရာများ တိုးတက်ပုံကို ပြသသည်။

စာမျက်နှာများ

Board: မဲခလုတ်များပါသော post စာရင်း၊ အမျိုးအစားနှင့် အခြေအနေဖြင့် filter၊ အထက်ဆုံး၊ အသစ်ဆုံးနှင့် ခေတ်စားဆုံး အလိုက် sort။
Post စာမျက်နှာ: ဖော်ပြချက်၊ မဲများ၊ comment များ၊ အမှန်တကယ် ပြန်စာများ မီးမောင်းထိုးပြထားခြင်း၊ အခြေအနေ မှတ်တမ်း။
Post အသစ် ဖောင်: ရေးနေသူ၏ စာသားအလိုက် တိုက်ရိုက်ပြသော "ဆင်တူ post များ" စာရင်းပါ။
Roadmap: Planned၊ In progress၊ Shipped ကော်လံများ။
Admin: triage လုပ်ရန် post အသစ်များ၊ ထပ်နေသည်များ ပေါင်းခြင်း၊ မှတ်စုဖြင့် အခြေအနေပြောင်းခြင်း၊ spam ဖုံးခြင်း။

ခွင့်ပြုချက်များ

လူတိုင်း ဖတ်နိုင်သည် (public ဖြစ်လျှင်)။ sign-in ပြုလုပ်ထားသော အသုံးပြုသူများက post၊ မဲနှင့် comment ပေးနိုင်သည်။ admin များက အခြေအနေပြောင်း၊ ပေါင်း၊ တရားဝင် ပြန်စာများ ပင်ထိုး၊ moderate လုပ်သည်။ B2B အတွက် မဲပေးသူ၏ ကုမ္ပဏီကို admin များက မြင်စေပြီး အခြားဖောက်သည်များထံ ဖုံးထားလိုနိုင်သည်။

ဆုံးဖြတ်ချက်များနှင့် ရွေးချယ်မှုများ

အမည်မဲ့ မဲပေးခြင်းက မဲလိမ်လည်ခြင်းကို ဖိတ်ခေါ်ပြီး ပြန်ဖြေနိုင်ရန် နည်းလမ်း မရှိပါ။ password အကောင့်အပြည့်အစုံက ပွတ်တိုက်မှု ထပ်တိုးစေသည်။ အလယ်အလတ် နည်းလမ်းတစ်ခုမှာ အီးမေးလ် လင့်ခ်ဖြင့် sign-in ဖြစ်သည်- အီးမေးလ်ရိုက်၊ လင့်ခ်နှိပ်၊ ဝင်ပြီ။ သင့်ထုတ်ကုန်တွင် အကောင့်ရှိပြီးသားဆိုလျှင် ဖောက်သည်များကို တူညီသော login ဖြင့် ဝင်စေပါ၊ ထိုအခါ ၎င်းတို့ကို မှန်ကန်စွာ သိရမည်။ အက်ပ်သို့ login ထည့်ခြင်း ကို ကြည့်ပါ။

အခြေအနေများ

စာရင်းကို တိုတိုရှင်းရှင်း ထားပါ- Under review၊ Planned၊ In progress၊ Shipped၊ Not planned။ "Not planned" ကို အကြောင်းရင်းတိုတိုဖြင့် ထားခြင်းက post ကို ဆိုင်းငံ့ထားခြင်းထက် ပိုလေးစားမှုရှိသည်။

မဲများနှင့် အလေးချိန်ပါသော ဝယ်လိုအား

လူတစ်ဦးလျှင် မဲတစ်ခုက ရိုးရှင်းပြီး ရှင်းပြရလွယ်သည်။ B2B အဖွဲ့အချို့က ဖောက်သည်အရွယ်အစား သို့မဟုတ် plan ဖြင့် အလေးချိန်ပေးသော မဲများကို မြင်လိုကြသည်။ ၎င်းကို admin view တွင်သာ ထားပါ၊ public မဲအရေအတွက်သည် လူတစ်ဦး၊ မဲတစ်ခုအဖြစ် ဆက်ရှိနေရမည်။

Loop ကို ပိတ်ခြင်း

အဖိုးတန်ဆုံး feature မှာ "သင်မဲပေးခဲ့သည့်အရာ ပို့ပြီးပါပြီ" ဟု ပြောသော အီးမေးလ်ဖြစ်သည်။ ထို့အတွက် ပို့ပေးသော provider (အက်ပ်မှ အီးမေးလ်ပို့နည်း ကို ကြည့်ပါ) နှင့် ရှင်းလင်းသော opt-out လိုအပ်သည်။ portal ကို changelog စာမျက်နှာ နှင့် တွဲပြီး ပို့ပြီးသော post တစ်ခုစီကို ၎င်း၏ changelog entry သို့ ချိတ်ပါ။

အလုပ်ဖြစ်သော ပထမ prompt

Slotly ခေါ်သော scheduling အက်ပ်အတွက် ဖောက်သည် feedback portal တည်ဆောက်ပါ။ ဖောက်သည်များသည် အီးမေးလ်ဖြင့် ပို့ထားသော magic link ဖြင့် sign in လုပ်သည်။ အိုင်ဒီယာတစ်ခု တင်နိုင်သည် (ခေါင်းစဉ်၊ ဖော်ပြချက်၊ အမျိုးအစား- Calendar၊ Payments၊ Notifications၊ Other)၊ post တစ်ခုလျှင် မဲတစ်ခုသာ ပေးနိုင်ပြီး comment ရေးနိုင်သည်။ post အသစ် ရိုက်နေချိန်တွင် ဆင်တူသော ရှိပြီးသား post အများဆုံး ငါးခု ပြပါ။ Board သည် Top၊ New သို့မဟုတ် Trending အလိုက် စီပြီး အမျိုးအစားနှင့် အခြေအနေဖြင့် filter လုပ်နိုင်သည်။ အခြေအနေများ- Under review၊ Planned၊ In progress၊ Shipped၊ Not planned။ Planned၊ In progress နှင့် Shipped ကော်လံများပါသော Roadmap စာမျက်နှာ ထည့်ပါ။ Admin များအတွက် အသစ် post များ triage စာမျက်နှာ၊ မှတ်စုတိုဖြင့် အခြေအနေပြောင်းခြင်း၊ ထပ်နေသော post ကို အခြား post သို့ ပေါင်းခြင်း (မဲနှင့် comment များ ရွှေ့ခြင်း)၊ comment တစ်ခုကို တရားဝင် ပြန်စာအဖြစ် မှတ်ခြင်းနှင့် spam ဖုံးခြင်း။ အရာအားလုံးကို database တွင် သိမ်းပြီး အခြေအနေပြောင်းလဲမှု တိုင်းကို မှတ်တမ်းတင်ပါ။ ဖော်ရွေသော၊ ရှင်းလင်းသော ဒီဇိုင်း၊ ဖုန်းတွင်လည်း အလုပ်လုပ်ရမည်။

တည်ဆောက်ရန် အဆင့်များ

Post များ၊ မဲများနှင့် comment များ ရိုးရှင်းသော sign-in ဖြင့်။ လူတစ်ဦး နှစ်ကြိမ် မဲမပေးနိုင်ကြောင်း စစ်ပါ၊ tab နှစ်ခုမှ ဖြစ်စေ။
Board စီခြင်းနှင့် filter များ။ Top၊ New၊ Trending၊ အမျိုးအစားနှင့် အခြေအနေ filter များ။
Admin triage။ မှတ်စုဖြင့် အခြေအနေပြောင်းခြင်း၊ ဖုံးခြင်း၊ တရားဝင် ပြန်စာများ။
ထပ်နေမှု ကိုင်တွယ်ခြင်း။ ဆင်တူ post အကြံပြုချက်များနှင့် merge လုပ်ဆောင်ချက်။
Roadmap စာမျက်နှာ။
အသိပေးချက်များ။ အခြေအနေပြောင်းတိုင်း မဲပေးသူများကို အီးမေးလ်ပို့ပြီး unsubscribe လင့်ခ်ပါစေ။
သင့်ထုတ်ကုန်မှ လင့်ခ်။ အက်ပ်မီနူးတွင် "Feedback" လင့်ခ်ထားပြီး ဖြစ်နိုင်လျှင် လူများကို တိုက်ရိုက် sign in ပေးပါ။
ရှိပြီးသား တောင်းဆိုချက်များဖြင့် seed လုပ်ပါ၊ ပထမဆုံး ဝင်ကြည့်သူက ဗလာ board မတွေ့စေရန်။

အဖြစ်များသော အမှားများ

ထည့်ပြီး ထားခဲ့ခြင်း။ အပတ်စဉ် triage လုပ်ရန်နှင့် အခြေအနေများ အပ်ဒိတ်လုပ်ရန် အချိန်သတ်မှတ်ပါ။
မဲများကို roadmap အဖြစ် သဘောထားခြင်း။ မဲများက portal ကို ဝင်သူများ ဘယ်လောက် စိတ်ဝင်စားသလဲကို တိုင်းသည်၊ ထုတ်ကုန်အတွက် အကောင်းဆုံးကို မဟုတ်ပါ။ ဖောက်သည်များနှင့်လည်း စကားပြောပါ၊ ဖောက်သည် အင်တာဗျူးလုပ်နည်း ကို ကြည့်ပါ။
ပေါင်းသည့် လုပ်ဆောင်ချက် မရှိခြင်း။ တောင်းဆိုချက်တူတူ ငါးခုက မဲများကို ခွဲပြီး စစ်မှန်သော လိုအပ်ချက်ကို ဖုံးထားသည်။
အမည်မဲ့ မဲများ။ လိမ်လည်ရန် လွယ်ပြီး နောက်ဆက်တွဲ လုပ်ဆောင်ရန် မဖြစ်နိုင်ပါ။
Roadmap တွင် ရက်စွဲ ကတိပေးခြင်း။ သေချာမှသာ ရက်ကန့်သတ်ချက်များအစား Planned နှင့် In progress ကို သုံးပါ။
Support desk ဖြစ်သွားခြင်း။ bug report များကို သင့် support channel သို့ ညွှန်ပြပြီး form ပေါ်တွင် ထိုသို့ ပြောပါ။

Hosted feedback ကိရိယာ ပိုကောင်းသည့်အချိန်

ယနေ့ အလုပ်ဖြစ်စေလိုလျှင် dedicated feedback ထုတ်ကုန်များ ရှိပြီး ကြည့်ရှုသင့်သည်။ ၎င်းတို့တွင် အက်ပ်အတွက် widget များ၊ issue tracker နှင့် CRM များနှင့် integration များ၊ သင့်ထုတ်ကုန်နှင့် single sign-on နှင့် ဘယ်သူက ဘာတောင်းနေသလဲ analytics များ ပါလေ့ရှိသည်။ support သို့မဟုတ် CRM ကိရိယာ ရှိပြီးသားဆိုလျှင် တည်ဆောက်မီ feedback သို့မဟုတ် ideas module ပါ၊ မပါစစ်ပါ။

ကိုယ်ပိုင်တည်ဆောက်ခြင်းသည် portal ကို သင့်ထုတ်ကုန်နှင့် တိကျစွာ ကိုက်ညီစေလိုသောအခါ၊ integration tier အတွက် မပေးဘဲ သင့် ဖောက်သည် ဒေတာ (plan၊ အသုံးပြုမှု၊ အကောင့်အရွယ်အစား) နှင့် ချိတ်ထားသော feedback လိုအပ်သောအခါ၊ စည်းမျဉ်းများ ထူးခြားသောအခါ (ဖောက်သည်တစ်ဦးချင်းအတွက် private board၊ အတွင်းပိုင်သာ အမျိုးအစားများ) သို့မဟုတ် hosted ရွေးချယ်မှုများက လက္ခဏာကို တန်ဖိုးထက် ကုန်ကျစရိတ်ပိုများသောအခါတွင် သင့်တော်သည်။

Mythex ဖြင့် တည်ဆောက်ခြင်း

Mythex တွင် portal ကို chat တွင် ဖော်ပြပါ၊ agent က live preview တွင် တည်ဆောက်ပေးသည်။ post များနှင့် မဲများ သိမ်းရန် လိုအပ်သောအခါ သီးသန့် Postgres database ကို ထည့်ပေးသည် (တောင်းဆိုပါ သို့မဟုတ် /database ဟု ရိုက်ပါ)။ Mythex က သင်တည်ဆောက်သော အက်ပ်များအတွက် built-in sign-in သို့မဟုတ် အီးမေးလ်ပို့ခြင်း မပေးပါ- သင့် provider နှင့် key များကို ကိုယ်တိုင် ယူဆောင်ပြီး project secret အဖြစ် သိမ်းရသည်။ docs တွင် login ထည့်ခြင်း နှင့် အီးမေးလ်ပို့ခြင်း အတွက် recipe များ ရှိသည်။

အဓိကစီးဆင်းမှု အလုပ်လုပ်ပြီးသည်နှင့် /test က agent ကို preview တွင် နှိပ်ကြည့်စေပြီး (အိုင်ဒီယာတင်၊ မဲပေး၊ admin အဖြစ် အခြေအနေ ပြောင်း) ဘာ ပျက်သလဲ အစီရင်ခံစေသည်။ ကောင်းမွန်သော စတင်နေရာမှာ feature request board template ဖြစ်ပြီး upvote နှင့် new မှ shipped အထိ အခြေအနေများ ပါသည်။

မေးခွန်းများ

ဖောက်သည် feedback portal က ဘာလုပ်သလဲ။

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

လူများ မဲပေးရန် အကောင့် လိုအပ်သလား။

များသောအားဖြင့် လိုအပ်သည်၊ အနည်းဆုံး အတည်ပြုထားသော အီးမေးလ်တစ်ခု လိုသည်။ အမည်မဲ့ မဲပေးခြင်းကို လိမ်လည်ရန် လွယ်ပြီး တောင်းဆိုချက် ပို့ပြီးသည့်အခါ လူများကို အကြောင်းကြား၍ မရနိုင်ပါ။ အီးမေးလ် လင့်ခ်ဖြင့် ပေါ့ပါးသော sign-in က အလယ်အလတ် ရွေးချယ်မှု ဖြစ်သည်။

အမြင့်ဆုံးမဲရသော feature များကို အရင်တည်ဆောက်သင့်သလား။

အလိုအလျောက်တော့ မဟုတ်ပါ။ မဲများသည် portal ကို တွေ့ခဲ့သော လူများ၏ လိုအပ်ချက်ကိုသာ ပြသပြီး ဖောက်သည် အားလုံးကို မဟုတ်ပါ။ ၎င်းကို ဝင်ငွေ၊ ဗျူဟာနှင့် ဖောက်သည် စကားဝိုင်းများမှ ကြားရသည့်အရာများ ဘေးတွင် အချက်အလက်တစ်ခုအဖြစ် သုံးပါ။

ထပ်နေသော တောင်းဆိုချက်များကို ဘယ်လို ကိုင်တွယ်သလဲ။

တစ်စုံတစ်ယောက်က post အသစ် ရိုက်နေချိန်တွင် ဆင်တူသော ရှိပြီးသား post များကို ပြပါ၊ admin အတွက် မူရင်း post သို့ မဲနှင့် comment များကို ရွှေ့ပြီး မဲပေးသူများကို အသိပေးသည့် merge လုပ်ဆောင်ချက် ပေးပါ။