သင်၏ အစီအစဉ်များကို ရေးဆွဲခြင်း

Two people arranging yellow planning notes on a glass wall

သင်ခန်းစာ 05 / 14 · အခမဲ့ စီးပွားရေးသင်တန်း

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

သင်ခန်းစာအဆုံးတွင်: အတိုချုံး plan matrix တစ်ခု ဖန်တီးပါ၊ သင့်လျော်သော upgrade လမ်းကြောင်းတစ်ခုကို ရှင်းပြပါ၊ အရေးကြီးသော ကန့်သတ်ချက်များကို စမ်းသပ်ပါ။ ဤသင်ခန်းစာရှိ ဈေးနှုန်းများသည် ဥပမာအတွက်သာဖြစ်ပြီး၊ သင်ခန်းစာ 9 တွင် ဈေးနှုန်းနှင့် ကုန်ကျစရိတ်များကို လေ့လာမည်ဖြစ်သည်။

မတူညီသော ဖောက်သည်အခြေအနေများဖြင့် စတင်ပါ

မူရင်း FitSite ဥပမာတွင် တစ်ကိုယ်တော် နည်းပြများ၊ တည်ထောင်ပြီးသား gym များနှင့် နေရာအများအပြားရှိသော စီးပွားရေးလုပ်ငန်းများကို ခွဲခြားထားသည်။ လိုအပ်သောအလုပ် ကွဲပြားနိုင်သောကြောင့် ၎င်းတို့သည် အသုံးဝင်သော ယူဆချက်များဖြစ်သည်။ နည်းပြတစ်ဦးသည် ရှင်းလင်းသော ပရော်ဖက်ရှင်နယ်အွန်လိုင်းတည်ရှိမှု လိုအပ်နိုင်ပြီး၊ အလုပ်များသော gym တစ်ခုသည် ပိုမိုပြည့်စုံသည့် အချိန်ဇယားနှင့် booking workflow လိုအပ်နိုင်ကာ၊ ဆိုင်ခွဲတစ်ခုသည် နေရာအလိုက် အချက်အလက်များ လိုအပ်နိုင်သည်။

ဝန်ထမ်းအရေအတွက်က သင့်တော်သော product ကို သတ်မှတ်ပေးသည်ဟု မယူဆပါနှင့်။ တစ်ကိုယ်တော် နည်းပြတစ်ဦးသည် online booking ကို အလွန်အားထားနိုင်သော်လည်း၊ ပိုကြီးသော gym တစ်ခုတွင် ဆက်လက်အသုံးပြုလိုသည့် စနစ်ရှိပြီးသား ဖြစ်နိုင်သည်။ workflow၊ ရှုပ်ထွေးမှု၊ ပံ့ပိုးမှုနှင့် အရွယ်အစားတို့တွင် အဓိပ္ပာယ်ရှိသော ကွာခြားချက်များကို သိရှိရန် အင်တာဗျူးများကို အသုံးပြုပါ။ Plan များသည် ပုံသေယူဆချက်များအစား ထိုကွာခြားချက်များကို ထင်ဟပ်သင့်သည်။

အခြား SaaS စီးပွားရေးလုပ်ငန်းတစ်ခုအတွက်ဆိုလျှင် ခွဲခြားရမည့် အချက်သည် project တစ်ခုနှင့် team workflow တစ်ခု၊ ရံဖန်ရံခါ အသုံးပြုခြင်းနှင့် မကြာခဏ အလုပ်လုပ်ခြင်း၊ သို့မဟုတ် နေရာတစ်ခုနှင့် နေရာအများအပြား ဖြစ်နိုင်သည်။ နားလည်လွယ်သော အခြေအနေအနည်းငယ်ကို ရွေးချယ်ပါ။ ဥပမာများတွင် tier သုံးခုကို အများအားဖြင့် အသုံးပြုကြသော်လည်း၊ ကောင်းမွန်သော offer တစ်ခု သို့မဟုတ် ရှင်းလင်းသော ရွေးချယ်မှုနှစ်ခုဖြင့် စတင်ရန် လုံလောက်နိုင်သည်။

Feature စာရင်းမရေးမီ ကတိကို ရေးပါ

Plan တစ်ခုစီအတွက် ဖောက်သည်ရရှိမည့် အသုံးဝင်သော ရလဒ်ကို ရှင်းပြသည့် စာကြောင်းတစ်ကြောင်း ရေးပါ။ ထို့နောက် ၎င်းကို ပေးအပ်ရန် လိုအပ်သော feature များနှင့် service work များကို စာရင်းပြုစုပါ။ ထိုရလဒ်တွင် feature တစ်ခု၏ အခန်းကဏ္ဍကို မရှင်းပြနိုင်လျှင်၊ ၎င်းကို စတင် offer တွင် ထည့်သင့်မသင့် ပြန်လည်စဉ်းစားပါ။

အခြေခံ plan သည်လည်း ၎င်းကတိပေးထားသော အလုပ်ကို ပြီးမြောက်စေရမည်။ Upgrade လုပ်စေရန်သာ အရေးပါသော feature တစ်ခုကို ဖယ်ရှားခြင်းက entry plan ကို စိတ်ပျက်စရာ ဖြစ်စေနိုင်သည်။ ဖောက်သည်တစ်ဦးက သင့် “booking website” ကို အသုံးပြု၍ booking များကို လက်ခံခြင်း သို့မဟုတ် လမ်းညွှန်ခြင်း မပြုနိုင်လျှင်၊ ကတိကို ပြောင်းလဲပါ သို့မဟုတ် အသုံးပြုနိုင်သော booking လမ်းကြောင်းတစ်ခု ထည့်သွင်းပါ။

ဖောက်သည်များ ဆုံးဖြတ်ရန်လိုအပ်သည့် လုပ်ငန်းဆိုင်ရာအသေးစိတ်များကို ထည့်သွင်းပါ- site သို့မဟုတ် workspace အရေအတွက်၊ သက်ဆိုင်ရာ အသုံးပြုမှုကန့်သတ်ချက်များ၊ custom domain ရရှိနိုင်မှု၊ ပံ့ပိုးသော integration များ၊ support အတိုင်းအတာနှင့် setup service များ။ ကန့်သတ်ချက်များကို ရှင်းလင်းစွာ ဖော်ပြပါ။ Technical quota များသည် ခေါင်းစဉ်ကို လွှမ်းမိုးမနေသင့်သော်လည်း၊ ပေးအပ်မှုအပေါ် သက်ရောက်သောအခါ အရေးကြီးသည်။

FitSite matrix ကို လက်တွေ့အသုံးပြုရန် ဥပမာအဖြစ် သုံးပါ

  • Starter — ဥပမာအတွက် $49/လ: Studio Essential template၊ အဓိက စီးပွားရေးအချက်အလက်များနှင့် ဆက်သွယ်ရန်လမ်းကြောင်း ပါဝင်သော studio website တစ်ခု။ Booking link များနှင့် custom domain များ ပါဝင်ခြင်းရှိမရှိကို ရှင်းလင်းစွာ ဖော်ပြပါ။
  • Growth — ဥပမာအတွက် $99/လ: ဝယ်ယူသူအတွက် သင့်လျော်သည့် ထပ်ဆောင်း template ရွေးချယ်စရာများနှင့် စမ်းသပ်ပြီးသား booking သို့မဟုတ် content workflow ပါဝင်သော website တစ်ခု။ Support နှင့် integration နယ်နိမိတ်များကို ထည့်သွင်းပါ။
  • Pro — ဥပမာအတွက် $199/လ: သက်ဆိုင်ရာ template များနှင့် maintenance အတိုင်းအတာတို့ဖြင့် site ငါးခုအထိကဲ့သို့ သဘောတူထားသော နေရာအများအပြားစီစဉ်မှုအတွက် ပံ့ပိုးမှု။

ဤနံပါတ်များသည် မူရင်းသင်ကြားရေးဥပမာကို ထိန်းသိမ်းထားခြင်းသာဖြစ်ပြီး၊ စျေးကွက်စံနှုန်းများလည်း မဟုတ်၊ ဈေးနှုန်းသတ်မှတ်ရန် အကြံပြုချက်လည်း မဟုတ်ပါ။ သင့်ကုန်ကျစရိတ်နှင့် ဝယ်ယူသူတုံ့ပြန်မှုကို စစ်ဆေးရမည်။ License၊ support နှင့် compatibility က ပေးအပ်နိုင်ကြောင်း အတည်မပြုထားလျှင် “premium plugin အားလုံး” ဟု ကတိမပေးပါနှင့်။ ပိုရှည်သော feature စာရင်းသည် ဖောက်သည်ရလဒ် မတိုးတက်ဘဲ ကုန်ကျစရိတ်ကို မြင့်တက်စေနိုင်သည်။

Allowance များကို တိကျစွာ ဖော်ပြပါ။ Pro တွင် site ငါးခု ပါဝင်ပါက၊ အမှန်တကယ် configuration အရ storage quota သည် site တစ်ခုစီအတွက်လား သို့မဟုတ် membership တစ်ခုလုံးအတွက်လားဆိုသည်ကို ဖော်ပြပါ။ Site တစ်ခုရှိ နေရာအများအပြားစာမျက်နှာသည် သီးခြားလွတ်လပ်သော site ငါးခုနှင့် မတူပါ။ Pricing table နှင့် provision လုပ်ထားသော product တို့က မတူညီသော အရာများကို မဖော်ပြစေပါနှင့်။

Matrix ကို product setting များအဖြစ် ပြောင်းလဲပါ

ရွေးချယ်နိုင်သော WordPress လမ်းကြောင်းတွင် Ultimate Multisite သည် plan များ၊ template များနှင့် ကန့်သတ်ချက်များကို ပံ့ပိုးပေးသည်။ ရည်ရွယ်ထားသော plan တစ်ခုစီအတွက် product တစ်ခု ဖန်တီးပြီး၊ ရရှိနိုင်သော template ရွေးချယ်မှုများ၊ ပံ့ပိုးထားသော plugin နှင့် theme များ၊ site allowance များနှင့် အခြားသက်ဆိုင်ရာ quota များကို configure လုပ်ပါ။ သင့် version တွင် ရရှိနိုင်သော control များအတွက် လက်ရှိ documentation ကို ကြည့်ပါ။

Plugin default များကို ရည်ရွယ်ချက်ရှိရှိ အသုံးပြုပါ။ Contact form တစ်ခုသည် site တိုင်း၏ အစိတ်အပိုင်းဖြစ်နိုင်သော်လည်း၊ အထူးပြု integration တစ်ခုသည် လိုအပ်သောနေရာတွင်သာ ပါဝင်သင့်သည်။ Network-activated plugin များသည် network တစ်လျှောက် load လုပ်သည်။ Plan setting တစ်ခုက ထိုအပြုအမူကို တားဆီးနိုင်မည်ဟု မယူဆပါနှင့်။ Tier တစ်ခုစီအတွက် အမှန်တကယ် ဖောက်သည်အတွေ့အကြုံကို စမ်းသပ်ပြီး၊ ဆက်လက်အသုံးပြုနိုင်နေသော feature ကို ကန့်သတ်ထားသည်ဟု မပြောပါနှင့်။

Permission များကို marketing နှင့် သီးခြားစီ ကိုင်တွယ်ပါ။ ဖောက်သည်များက ၎င်းတို့၏ content ကို ထိန်းသိမ်းရန် လိုအပ်သော access ကို ပေးပြီး platform administration ကို သင့်ထိန်းချုပ်မှုအောက်တွင် ထားပါ။ Network administrator ၏ မြင်ကွင်းမှသာ စစ်ဆေးခြင်းမဟုတ်ဘဲ plan တိုင်းတွင် customer account အသစ်တစ်ခုကို စမ်းသပ်ပါ။

အများပြည်သူမြင်ရသော comparison table နှင့် အတွင်းပိုင်း delivery checklist ကို အတူတကွ ထားပါ။ Feature တစ်ခု ပြောင်းလဲသည့်အခါ revised plan ကို မကမ်းလှမ်းမီ နှစ်ခုလုံးကို update လုပ်ပါ။ ၎င်းက configuration အသစ်ကို provision လုပ်နေစဉ် ကတိဟောင်းကို ရောင်းချမိခြင်းမှ ရှောင်ရှားရန် ကူညီပေးသည်။

မရောင်းချမီ upgrade နှင့် downgrade များကို ဒီဇိုင်းဆွဲပါ

Plan များကြား ရွှေ့ပြောင်းသည့်အခါ ဘာပြောင်းလဲမည်ကို ဖောက်သည်တစ်ဦး နားလည်သင့်သည်။ Ultimate Multisite တွင် ထည့်သွင်းထားသော version အတွက် plan-group နှင့် upgrade/downgrade setting များကို စစ်ဆေးပြီး ခွင့်ပြုထားသော transition များကို စမ်းသပ်ပါ။ Starter၊ Growth၊ Pro ကဲ့သို့သော မြင်သာသည့် အစဉ်သည် အခြေခံ transition အပြုအမူက ၎င်းနှင့်ကိုက်ညီသည့်အခါမှသာ အသုံးဝင်သည်။

Downgrade များကို အထူးဂရုပြုသင့်သည်။ ဖောက်သည်တစ်ဦးတွင် အောက်အဆင့် plan ခွင့်ပြုသည့်ထက် site၊ storage သို့မဟုတ် user ပိုများနေပါက ဘာဖြစ်မည်နည်း။ Custom domain သို့မဟုတ် integration တစ်ခုမှာရော ဘာဖြစ်မည်နည်း။ ဖောက်သည်ဒေတာကို ထိန်းသိမ်းပြီး လိုအပ်သောပြောင်းလဲမှုများကို ဆက်သွယ်ဖော်ပြသည့် လုပ်ငန်းစဉ်ကို သတ်မှတ်ပါ။ ရည်ရွယ်ထားသော billing အပြုအမူကို အတည်မပြုဘဲ အလိုအလျောက်ဖျက်ခြင်း၊ ချက်ချင်း prorate လုပ်ခြင်း သို့မဟုတ် ချက်ချင်းငွေပြန်အမ်းခြင်းကို ကတိမပေးပါနှင့်။

ပံ့ပိုးထားသောနေရာတွင် ထိန်းချုပ်ထားသော payment test environment ဖြင့် plan ပြောင်းလဲမှုများကို စမ်းသပ်ပါ။ သက်တမ်းတိုးရက်စွဲများ၊ ပြသထားသောဈေးနှုန်းများ၊ entitlement များနှင့် ဖောက်သည် email များကို စစ်ဆေးပါ။ ကိုယ်တိုင် support ပေးရန်လိုအပ်သည့်အရာများကို မှတ်တမ်းတင်ထားပြီး ၎င်းကို ရိုးသားစွာ ဈေးနှုန်းသတ်မှတ်ကာ ရှင်းပြနိုင်ပါစေ။

ရွေးချယ်နိုင်သော အပိုပစ္စည်းများကို အနည်းငယ်သာ ထည့်ပါ

အရင်းအမြစ်တွင် storage အပို၊ ဦးစားပေး support နှင့် site အပိုများကို အကြံပြုထားသည်။ ဖောက်သည်များ နားလည်နိုင်ပြီး သင်က ယုံကြည်စိတ်ချစွာ ပေးအပ်နိုင်သည့်အခါ ၎င်းတို့သည် အသုံးဝင်သော add-on များ ဖြစ်နိုင်သည်။ Software က ပံ့ပိုးပေးရုံကြောင့် checkout ရွေးချယ်စရာများ ထည့်မည့်အစား အမှန်တကယ် ထပ်ခါတလဲလဲတောင်းဆိုမှုတစ်ခုဖြင့် စတင်ပါ။

Add-on တစ်ခုစီအတွက် unit၊ ဈေးနှုန်း၊ billing interval၊ cancellation အပြုအမူနှင့် delivery responsibility ကို သတ်မှတ်ပါ။ “Priority support” တွင် တိကျသော အတိုင်းအတာနှင့် တုံ့ပြန်ချိန်မျှော်မှန်းချက် ရှိရမည်၊ အာမခံထားသော ဖြေရှင်းပေးမှုဟု မဆိုလိုသင့်ပါ။ Storage အပိုတွင် တိုင်းတာနိုင်သော allowance နှင့် မျှဝေသုံးစွဲခြင်းရှိမရှိ၏ ရှင်းလင်းသော အဓိပ္ပာယ်ဖွင့်ဆိုချက် လိုအပ်သည်။

Add-on များကို ရွေးချယ်နိုင်သည်ဟု ထင်ရှားစွာထားပြီး ကြိုတင်ရွေးထားသော ကောက်ခံမှုများကို ရှောင်ကြဉ်ပါ။ သင်ခန်းစာ 6 တွင် checkout တွင် offer ကို တင်ပြပုံကို ဖော်ပြထားသည်။ ရိုးရှင်းသော ဝယ်ယူမှုဆုံးဖြတ်ချက်သည် entitlement များထပ်နေသော bundle အများအပြားထက် စမ်းသပ်ရန်နှင့် support ပေးရန် ပိုလွယ်ကူသည်။

သင့်လေ့ကျင့်ခန်း: သင်ခန်းစာကို လက်တွေ့အသုံးချပါ

တစ်မျက်နှာစာ plan matrix နှင့် test checklist တစ်ခု ဖန်တီးပါ:

  • သင့်ပထမဆုံး ဖောက်သည် segment များနှင့် plan တစ်ခုစီက ကတိပေးသည့် ရလဒ်ကို အမည်ပေးပါ။
  • လိုအပ်သော feature များ၊ ကန့်သတ်ချက်များ၊ support အတိုင်းအတာနှင့် ချန်လှပ်ထားသည့်အရာများကို ရိုးရှင်းသောဘာသာစကားဖြင့် စာရင်းပြုစုပါ။
  • “ဥပမာအတွက်သာ—အတည်ပြုရန်လိုအပ်သည်” ဟု အမှတ်အသားပြုထားသော ယာယီဈေးနှုန်းများနှင့် ခန့်မှန်းပေးအပ်မှုကုန်ကျစရိတ်များကို ပူးတွဲပါ။
  • အောက်အဆင့် plan ကန့်သတ်ချက်ထက် ကျော်လွန်သည့်အခါ ဘာဖြစ်မည်အပါအဝင် upgrade scenario တစ်ခုနှင့် downgrade scenario တစ်ခု ရေးပါ။
  • WordPress အသုံးပြုပါက plan တစ်ခုစီအတွက် test account တစ်ခု provision လုပ်ပြီး ပေးအပ်ထားသော အတွေ့အကြုံကို matrix နှင့် နှိုင်းယှဉ်ပါ။

သင့်ပေးအပ်ရမည့်အရာ: ရှင်းလင်းသော နယ်နိမိတ်များနှင့် အတည်ပြုရန်လိုအပ်နေသေးသော setting သို့မဟုတ် billing အပြုအမူများစာရင်းပါဝင်သည့်၊ အတိုချုံးစကားပြောဆိုမှုတစ်ခုတွင် ရှင်းပြနိုင်သော offer တစ်ခု။

ရှေ့ဆက်မသွားမီ

  • Plan များသည် အသုံးဝင်သော ဖောက်သည်အခြေအနေများနှင့် ကိုက်ညီပြီး ပေးအပ်ရန် အဆင်ပြေနိုင်ရမည်။
  • ကုန်ကျစရိတ်နှင့် ဖောက်သည်အထောက်အထားများက မပံ့ပိုးမချင်း ဥပမာဈေးနှုန်းများသည် ယူဆချက်များသာဖြစ်သည်။
  • Pricing table တစ်ခုကိုသာ အားကိုးမည့်အစား ကန့်သတ်ချက်များ၊ plugin ရရှိနိုင်မှု၊ upgrade များနှင့် downgrade များကို စမ်းသပ်ပါ။

ရင်းမြစ်များနှင့် နောက်ထပ်ဖတ်ရှုရန်

မူရင်း website-business သင်ခန်းစာမှ ပြန်လည်ပြင်ဆင်ထားသည်။ Ultimate Multisite: plan များ၊ ကန့်သတ်ချက်များနှင့် plugin control များ

နောက်တစ်ခု: စာရင်းသွင်းခြင်း အတွေ့အကြုံ

ယခင်သင်ခန်းစာ · သင်ခန်းစာ 14 ခုလုံးကို ကြည့်ရှုရန်