រំកិលទៅមាតិកា

យល់អំពី Command Center Analytics

ការរៀបចំរហ័ស

សណ្ឋាគារភាគច្រើនពិនិត្យ Completion Rate, Biggest Drop‑Off, និង Issues ក្នុងរយៈពេលក្រោម 3 នាទី។

មគ្គុទ្ទេសក៍នេះពន្យល់ពីរបៀបដែល AVA គណនាតារាង Analytics នីមួយៗនៅក្នុង Command Center។ វាក៏ពន្យល់អំពីកាត coverage check-in បន្ថែមដែលអ្នកអាចឃើញផងដែរ។

ទៅកាន់: Main Menu → Command Center → Analytics

ផ្ទុក Analytics លឿនជាងមុន

AVA ឥឡូវអាន tab នេះពី daily rollups ដើម្បីឱ្យ date range ធំៗផ្ទុកបានលឿនជាងមុន។ បើទិន្នន័យ rollup ខ្វះ ឬការហៅ rollup បរាជ័យ AVA នឹងត្រឡប់ទៅប្រើ live path វិញ។

ពេលផ្ទុកយូរសម្រាប់ date range ធំ

ចន្លោះកាលបរិច្ឆេទធំៗនៅតែអាចចំណាយពេលផ្ទុកយូរ។ អចលនទ្រព្យដែលរវល់ខ្លាំងអាចត្រឡប់ error ទាមទារ date range តូចជាងមុន លឿនជាងការជាប់។ នេះអនុវត្តតែលើ tab Analytics ប៉ុណ្ណោះ។

សម័យសាកល្បង

ការចូលតេស្តនៅតែបង្ហាញក្នុង Status និង reservation details។ វាមិនរាប់ក្នុង total, drop-offs, time analysis, issues, ឬ recent activity របស់ Analytics ទេ។

មិនមានការទាញយក report

តារាង Analytics សំខាន់ៗមិនមានប៊ូតុងទាញយក PDF តាម browser ទេ។ ពេលផ្ទាំង STB EVA submissions បង្ហាញ អ្នកអាចប្រើរូបតំណាងទាញយករបស់វា ដើម្បីនាំចេញជា CSV។ ការនាំចេញនោះប្រើប្រភពកំណត់ហេតុ EVA submission ដូចគ្នានឹង dashboard counts។

ចម្លង MCP config សម្រាប់ Codex ឬ Claude​

ការរៀបចំរហ័ស

វាចំណាយពេលក្រោម 1 នាទី។ token នេះមានអាយុកាលខ្លី ហើយប្រើ browser session បច្ចុប្បន្នរបស់អ្នក។

ប្រើប៊ូតុងទាំងនេះ នៅពេលអ្នកចង់ផ្ញើទិន្នន័យ Analytics ទៅកាន់ AI client មួយ។ សញ្ញាសម្គាល់ token ដែលបានចម្លងក៏រួមបញ្ចូលវិសាលភាព Streamliner MCP ពេញលេញផងដែរ។ អតិថិជនដែលគាំទ្រអាចប្រើ settings tools បន្ទាប់ពីអ្នកចាប់ផ្តើមវាឡើងវិញ។ បន្ទាប់ពីអ្នកចម្លង AVA នឹងបង្ហាញបង្អួច modal ជាក់លាក់តាម client ជាមួយនឹងសេចក្តីណែនាំសម្រាប់បិទភ្ជាប់។

ប៊ូតុងអ្វីដែលវាចម្លងល្អបំផុតសម្រាប់
Copy Codex MCP Configការកំណត់ MCP ជាទម្រង់ TOML ជាមួយ mcp_servers.streamlinerCodex
Copy Claude MCP Configការកំណត់ MCP ជាទម្រង់ JSON ជាមួយ mcpServers.streamlinerClaude Code ឬ Claude Desktop

  1. ទៅកាន់ Main Menu → Command Center → Analytics។

  2. ចុច Copy Codex MCP Config ឬ Copy Claude MCP Config។

  3. រង់ចាំរហូតដល់ប៊ូតុងប្តូរទៅជា Creating MCP token...។

  4. អានសេចក្តីណែនាំក្នុង modal សម្រាប់ client របស់អ្នក។

  5. បិទភ្ជាប់ config ដែលបានចម្លងទៅក្នុងឯកសារ config របស់ AI client របស់អ្នក។

  6. ចាប់ផ្តើម client របស់អ្នកឡើងវិញ ដើម្បីឱ្យវាផ្ទុក MCP server ថ្មី។

    ✓ Claude config ប្រើ JSON។ ✓ Codex config ប្រើ TOML។ ✓ config ទាំងពីររួមបញ្ចូល STREAMLINER_MCP_TOKEN ដែលមានអាយុកាលខ្លី។

token ថ្មីតែប៉ុណ្ណោះ

បើអ្នកបានចម្លង token មុនការផ្លាស់ប្តូរនេះ សូមចម្លង config ថ្មីម្តងទៀត។ សញ្ញាសម្គាល់ token ចាស់ៗនឹងរក្សាវិសាលភាពមុនរបស់វា រហូតដល់អ្នកបន្តអាយុកាលវា។

កន្លែងបិទភ្ជាប់ config នីមួយៗ

Codex ប្រើ ~/.codex/config.toml។

Claude ប្រើ Claude Desktop Developer config ដែលជាទូទៅគឺ claude_desktop_config.json។

អ្វីដែល modal បង្ហាញ​

បង្អួច modal បញ្ជាក់ថាអ្នកបានចម្លង config ដោយជោគជ័យ។ បន្ទាប់មកវាបង្ហាញ file path ទីតាំងបិទភ្ជាប់ និងជំហានចាប់ផ្តើមឡើងវិញសម្រាប់ client នោះ។

បើអ្នកកំពុងប្រើ Codex

  1. បើក ~/.codex/config.toml នៅលើម៉ាស៊ីនដែលអ្នកដំណើរការ Codex។

  2. បិទភ្ជាប់ TOML block ដែលបានចម្លងនៅកម្រិត top-level នៃឯកសារ។

  3. រក្សាទុកឯកសារ បន្ទាប់មកចាប់ផ្តើម Codex ឡើងវិញ។

    ✓ បើ mcp_servers.streamliner មានរួចហើយ សូមជំនួស section នោះ។

បើអ្នកកំពុងប្រើ Claude Desktop

  1. បើក Claude Desktop។

  2. ទៅកាន់ Settings → Developer → Edit Config។

  3. បិទភ្ជាប់ JSON ដែលបានចម្លងទៅក្នុង claude_desktop_config.json។

  4. រក្សាទុកឯកសារ បន្ទាប់មក quit ហើយបើក Claude Desktop ឡើងវិញទាំងស្រុង។

    ✓ លើ macOS ឯកសារនេះជាទូទៅស្ថិតក្រោម ~/Library/Application Support/Claude/។ ✓ បើ mcpServers មានរួចហើយ សូម merge តែ entry streamliner ប៉ុណ្ណោះ។

សេចក្តីយោងរហ័ស​

ទិដ្ឋភាពអ្វីដែលរាប់ជាសម័យច្បាប់បញ្ចប់
Pre‑Arrivalការកក់ណាមួយដែលឈានដល់ជំហាន Pre‑ArrivalPRE_ARRIVAL ជោគជ័យ
Check‑In → Allការកក់ណាមួយដែលមានជំហាន flow នៃ check-in (រួមទាំង early check-in ឬ pre-registration) ដោយមិនរាប់តែ pre-arrival ប៉ុណ្ណោះCHECKIN, KEY_COLLECTION, ឬ GET_DOOR_LOCK_KEY
Check‑In → Early Check‑InEARLY_CHECKIN_ATTEMPT ឬ ROOM_ASSIGNMENT_QUEUEDEARLY_CHECKIN_ATTEMPT ឬ ROOM_ASSIGNMENT_QUEUED ជោគជ័យ
Check‑In → Pre‑Registrationការកក់ណាមួយដែលមានជំហាន Pre‑RegistrationPRE_REGISTRATION ជោគជ័យ
Check‑In → Full Check‑InCHECKIN, KEY_COLLECTION, ឬ GET_DOOR_LOCK_KEYCHECKIN, KEY_COLLECTION, ឬ GET_DOOR_LOCK_KEY ជោគជ័យ
Check‑Outការកក់ណាមួយដែលមានជំហាន checkoutCHECKOUT ឬ COMPLETED_CHECKOUT_PAYMENT ជោគជ័យ

បើក Analytics ហើយជ្រើស view​

Check-In/Out Analytics Dashboard

  1. ទៅកាន់ Main Menu → Command Center។

  2. ជ្រើស tab Analytics។

  3. ជ្រើស Pre‑Arrival, Check‑In, ឬ Check‑Out។

  4. បើអ្នកជ្រើស Check‑In សូមប្រើ sub-tabs: All Check‑Ins, Early Check‑In, Pre‑Registration, ឬ Full Check‑In។

    ✓ តារាងទាំងអស់នឹងអាប់ដេតទៅតាម view និង date range នោះ។

របៀប AVA បង្កើត session​

  • Session មួយ គឺកំណត់ត្រា check-in មួយសម្រាប់ការកក់ មិនមែនសម្រាប់ភ្ញៀវនីមួយៗទេ។
  • Session ត្រូវបានរាប់នៅពេលយ៉ាងហោចណាស់មានមួយជំហានពី view នោះត្រូវបានកត់ត្រា។
  • ជំហានបរាជ័យនៅតែរាប់នៅក្នុងសរុប ដើម្បីឱ្យអ្នកមើលឃើញការធ្លាក់ចុះ និងបញ្ហា។
Pre‑Arrival គឺដាច់ដោយឡែក

សម័យ pre-arrival មិនត្រូវបានរាប់ក្នុង All Check‑Ins ទេ។ សម្រាប់វា សូមប្រើ view Pre‑Arrival។

កាតសង្ខេប (ផ្នែកខាងលើនៃ tab)​

កាតរបៀបគណនា
Total Logsចំនួន session ក្នុង view ដែលបានជ្រើស
Completion Ratesession ដែលបានបញ្ចប់ ÷ total logs
Avg Completion Timeពេលវេលាពីជំហានជោគជ័យដំបូង (ជាទូទៅ Entry) ដល់ការបញ្ចប់
Successful Check‑Ins / Check‑Outsចំនួន session ដែលបានបញ្ចប់សម្រាប់ view នោះ

អ្វីដែលរាប់ជាការបញ្ចប់ អាស្រ័យលើ view មួយៗ (សូមមើលតារាង Quick Reference)។

ប្រើតារាងនេះដើម្បីបញ្ជាក់ថា session ណាខ្លះគួររាប់ជាបញ្ចប់ មុនអ្នកប្រៀបធៀបរវាងរយៈពេល។

ឧទាហរណ៍

បើ Total Logs ស្មើ 40 ហើយ Successful Check‑Ins ស្មើ 28 នោះ completion rate គឺ 70%។

កាត coverage check-in​

ពេល AVA ទទួលទិន្នន័យ coverage ពី PMS របស់អ្នក អ្នកអាចឃើញកាតបន្ថែមពីរបន្ទាប់ពី Completion Rate។ វាដំណើរការសម្រាប់ AVA PMS, Cloudbeds, Opera, Mews, និង eZee។

កាតអ្វីដែលវាបង្ហាញមូលហេតុដែលវាសំខាន់
Eligible Check-In Unitsconfirmation units ឬ sub-reservation units ដាច់ដោយឡែកក្នុងរយៈពេលដែលបានជ្រើសនេះជាខ្នាតគណនាសម្រាប់ coverage
AVA Check-In Shareភាគរយនៃ units ដែលមានសិទ្ធិ ដែល AVA បានដំណើរការយ៉ាងហោចណាស់ម្តងនេះបង្ហាញការទទួលយក AVA សម្រាប់រយៈពេលនោះ
ឯកតា ប្រៀបធៀបនឹងការកក់

កាតទាំងនេះរាប់ units មិនមែន reservations ទាំងមូលទេ។ ការកក់បន្ទប់ច្រើនអាចបន្ថែម eligible unit ច្រើនជាងមួយ។

ការកក់ OPERA

បើ PMS របស់អ្នកគឺ OPERA, AVA នឹងមិនរាប់ PM, PF, និង PX pseudo rooms ក្នុង eligible unit count ទេ។ វាក៏ប្រើ top-level room type fields នៅពេល room rows ស្ដើង ដូច្នេះបន្ទប់ភ្ញៀវពិតប្រាកដនៅតែរាប់បានត្រឹមត្រូវ។

គ្រួសារការកក់ OPERA

AVA ក៏ dedupe linked OPERA reservation families ដោយ parent confirmation ផងដែរ។ វាជួយមិនឱ្យ sibling rows ចុងក្រោយបំប៉ោង Eligible Check-In Units។

session maps ដែលត្រូវបានកាត់ខ្លី

បើ AVA កំណត់ sessionsMapMeta.truncated ជា true វានឹងមិនយក partial map នោះមកប្រើទេ។ បន្ទាប់មកវាប្រើ check-in logs ពេញលេញសម្រាប់ការគណនា share នៅពេលអាចប្រើបាន។ បើ AVA មិនអាចយក logs ពេញលេញបាន កាត coverage នឹងនៅតែត្រូវលាក់។

AVA រាប់ reservation ដែលបានដំណើរការម្តងនីមួយៗ។ វាប្រើ session map នៅពេល map នោះពេញលេញ។ បើ session map ខ្វះ ឬត្រូវកាត់ខ្លី វានឹងប្រើ raw log identities ជំនួសវិញ។ នេះធ្វើឱ្យ AVA Check-In Share ស្របគ្នាជាមួយ reservation coverage។ វាគួរតែនៅតិចជាង ឬស្មើ 100%។

លទ្ធផលថ្មីអាចយឺតបន្តិច

បើអ្នក refresh date range ដដែលម្ដងទៀត AVA អាចប្រើលទ្ធផល coverage ចុងក្រោយមួយរយៈខ្លី។ នេះជួយឱ្យ tab Analytics ដំណើរការលឿននៅពេលពិនិត្យម្ដងហើយម្ដងទៀត។

ភាគរយចែករំលែក check-in មើលទៅមិនត្រឹមត្រូវ​

អ្វីដែលអ្នកឃើញ: AVA Check-In Share ខ្ពស់ជាងការរំពឹងទុក។

វិធីដោះស្រាយ:

  1. Refresh tab Analytics។
  2. បញ្ជាក់ថា date range ស្របគ្នាជាមួយរបាយការណ៍ PMS របស់អ្នក។
  3. ពិនិត្យថា property របស់អ្នកប្រើ PMS ដែលគាំទ្រ។
  4. បើវានៅតែមើលទៅមិនត្រឹមត្រូវ សូមទាក់ទង support ជាមួយ screenshot។

បើអ្នកមិនឃើញកាតទាំងនេះទេ ទិន្នន័យ PMS បច្ចុប្បន្នរបស់អ្នកអាចមិនរួមបញ្ចូល metrics coverage នៃ units ទេ។ អ្នកផ្តល់ PMS ដែលមិនគាំទ្រ នឹងមិនបង្ហាញកាតទាំងនេះឡើយ។

តារាង Funnel (ការធ្លាក់ចុះ និងពេលវេលាជំហាន)​

តារាង funnel បង្ហាញភាគរយនៃ session ដែលឈានដល់ជំហាននីមួយៗ។

  • Drop‑off ប្រៀបធៀបជំហាននីមួយៗទៅនឹងជំហានមុនវា។
  • Avg Stage Duration វាស់ពេលវេលាដែលចំណាយនៅក្នុង stage ចាប់ពី stage ចាប់ផ្តើមដល់ stage ជោគជ័យ។
  • Avg Time to Next Step វាស់ពេលវេលាពីជំហានជោគជ័យមួយទៅជំហានជោគជ័យបន្ទាប់។
  • កាត Slowest Step ប្រើ stage duration ជាមុន។
  • បើ AVA មិនមាន stage timing វានឹងប្តូរទៅប្រើ next-step duration។
  • បើជំហានក្រោយកើតឡើងមុនជំហានមុន នោះ duration ត្រូវបង្ហាញជា 0។

ប្រើកាត Biggest Drop‑Off ដើម្បីជ្រើសជំហានដែលត្រូវ coaching ជាមុនសិន។

ឧទាហរណ៍

បើ Document Upload មាន 60 session ហើយជំហានមុនមាន 100 នោះ drop‑off គឺ 40%។ បើ Document Upload ខ្លួនវាចំណាយ 20 វិនាទី Avg Stage Duration គឺ 20 វិនាទី។ បើ Document Upload បញ្ចប់នៅ 10:05 ហើយ Validation នៅ 10:07 នោះ Avg Time to Next Step គឺ 2 នាទី។

ការវិភាគពេលវេលា (បរិមាណតាមម៉ោង)​

ការវិភាគពេលវេលា ដាក់ session ជាក្រុមតាម ជំហានជោគជ័យដំបូង ក្នុង view ដែលបានជ្រើស។

  • ប្រើ timezone របស់សណ្ឋាគាររបស់អ្នក។
  • Pre‑Arrival ត្រូវការជំហាន PRE_ARRIVAL ដែលជោគជ័យ។
  • បង្ហាញ Peak Hours និង Rush Periods ដើម្បីជួយក្នុងការរៀបចំបុគ្គលិក។

ប្រើ Peak Hours ដើម្បីរៀបចំ coverage សម្រាប់ប្លុកពេលដែលរវល់បំផុតរបស់អ្នក។

ឧទាហរណ៍

សម័យដែលជោគជ័យដំបូងនៅម៉ោង 7:10 តាម local time នឹងរាប់ក្នុងម៉ោង 07:00។

បញ្ហា (កំហុសថ្មីៗ)​

ផ្នែក Issues រាយ session ដែលមានជំហានបរាជ័យថ្មីបំផុត។

  • AVA ពិនិត្យ 10 events ចុងក្រោយសម្រាប់កំហុស។
  • បើគ្មានកំហុសថ្មីៗ វានឹងប្រើកំហុសថ្មីបំផុតដែលបានកត់ត្រាទុក។

ប្រើ View Details ដើម្បីមើលប្រវត្តិជំហានពេញលេញ។

ឧទាហរណ៍

បើការទូទាត់បរាជ័យនៅ 3:12 បន្ទាប់ពីជោគជ័យមុន នោះ issue នឹងបង្ហាញ Payment នៅ 3:12។ បើ 10 events ចុងក្រោយជោគជ័យទាំងអស់ AVA នឹងបង្ហាញកំហុសថ្មីបំផុតដែលបានកត់ត្រាទុក។

សកម្មភាពថ្មីៗ​

សកម្មភាពថ្មីៗ បង្ហាញជំហានសំខាន់ៗដែលបាន ជោគជ័យ ឬបរាជ័យ ដូចជា៖

  • Check‑In, Check‑Out
  • Room Assignment
  • Pre‑Registration
  • Identity Verification
  • Payment

បញ្ជីនេះកំណត់ត្រឹម 30 ធាតុចុងក្រោយប៉ុណ្ណោះ។

ប្រើបញ្ជីនេះ ដើម្បីបញ្ជាក់ថាជំហានណាខ្លះត្រូវបានបញ្ចប់ថ្មីបំផុត។

ឧទាហរណ៍

អ្នកអាចឃើញ “Check‑In completed successfully” ឬសារ​បរាជ័យសម្រាប់ Identity Verification។

ការបែងចែកជំហានចុងក្រោយ (កន្លែងដែល session បញ្ចប់)​

តារាងនេះដាក់ជាក្រុមនូវជំហានចុងក្រោយរបស់ session នីមួយៗទៅតាមប្រភេទ៖

  • Success — ជំហានបញ្ចប់ពេញលេញ
  • Timing — ជំហាន early check-in (រួមទាំង Room Queued)
  • Partial — pre-registration
  • Room — ជំហានចាត់តាំងបន្ទប់ (Room Assignment)
  • Documentation — ការផ្ទៀងផ្ទាត់ឯកសារ ឬអត្តសញ្ញាណ
  • Payment — ជំហានទូទាត់
  • Early — Entry / Fetch steps

បើមានកំហុសកើតឡើង បន្ទាប់ ពីជោគជ័យចុងក្រោយ ជំហានបរាជ័យនោះនឹងក្លាយជាជំហានចុងក្រោយ។

ប្រើតារាងនេះ ដើម្បីមើលចំណុចដែលជាញឹកញាប់បញ្ឈប់ដំណើរការ។

ឧទាហរណ៍

ក្នុងចំណោម 50 session, 20 បញ្ចប់នៅ Check‑In (success), 10 នៅ Early Check‑In (timing), 8 នៅ Document Upload (documentation), និង 12 នៅ Payment (payment)។

បើក session ពីការបែងចែកជំហានចុងក្រោយ​

  1. ជ្រើស bar segment មួយក្នុង Final Step Distribution។

  2. ពិនិត្យបញ្ជី session ដែលបើកឡើង។

    ✓ បញ្ជីបង្ហាញលេខ confirmation, ភ្ញៀវ, បន្ទប់, និង failure ថ្មីបំផុត។

  3. ជ្រើស Open details លើ session ណាមួយ។

    ✓ ផ្ទាំង Reservation Details នឹងបើកសម្រាប់ session នោះ។

បញ្ជី session ប្រៀបធៀបនឹងការកក់

បញ្ជីនេះបង្ហាញ sessions មិនមែន reservations ដែលបានដាក់ជាក្រុមទេ។ ប្រើវាដើម្បីស្វែងរក failure កើតឡើងជាប់ៗយ៉ាងលឿន។

ការវិភាគឧបករណ៍ (ជាជម្រើស)​

ការវិភាគឧបករណ៍ ប្រើព័ត៌មាន device ពី session check‑in/out។

បើភ្ញៀវមិនបានផ្តល់ព័ត៌មាន device តារាងនេះអាចទទេ។

ប្រើទិដ្ឋភាពនេះ ដើម្បីប្រៀបធៀបការប្រើ kiosk និង mobile តាម OS។

ឧទាហរណ៍

បើ session ភាគច្រើនជា iOS អ្នកប្រហែលជាចង់បង្កើនប្រសិទ្ធភាពលំហូរ mobile check-in។

ដែនកំណត់ និងភាពទាន់សម័យនៃទិន្នន័យ​

  • Analytics គ្របដណ្តប់រហូតដល់ 90 days ក្នុងមួយ query។
  • បើមាន event លើស 50,000 ក្នុងចន្លោះនោះ AVA នឹងស្នើឱ្យអ្នកបង្រួមកាលបរិច្ឆេទ។
  • បញ្ជី session ត្រូវបានកំណត់សម្រាប់ប្រសិទ្ធភាព (ប្រហែល 200 per step និង 2,000 total)។

ដោះស្រាយបញ្ហា​

តារាងទាំងអស់បង្ហាញសូន្យ​

អ្វីដែលអ្នកឃើញ: Summary cards បង្ហាញ 0 ហើយតារាងទទេ។

ដំណោះស្រាយ៖

  1. ពង្រីក date range។
  2. បញ្ជាក់ថាមាន logs នៅក្នុង Status។
  3. ពិនិត្យថា plan របស់អ្នករួមបញ្ចូល Analytics។

Completion rate មើលទៅទាបជាងការរំពឹងទុក​

អ្វីដែលអ្នកឃើញ: Completion rate ទាប ទោះបីភ្ញៀវជាច្រើនបាន check in ក៏ដោយ។

ពិនិត្យ៖

  • Demo check-ins ត្រូវបានដកចេញ ដូច្នេះ sessions សាកល្បងមិនធ្វើឱ្យ Total Logs កើនឡើងទេ។
  • Sessions នៅក្នុង Pre‑Arrival មិនរាប់ទៅ All Check‑Ins ទេ។
  • All Check‑Ins រាប់តែជំហាន Full Check‑In ជាអ្វីដែលបានបញ្ចប់។
  • Early Check‑In និង Pre‑Registration ត្រូវបានតាមដាននៅក្នុង sub-tabs ផ្ទាល់ខ្លួន។

កាត coverage បាត់​

អ្វីដែលអ្នកឃើញ: អ្នកឃើញតែកាតសង្ខេបធម្មតា។

ដំណោះស្រាយ៖

  1. ស្នាក់នៅលើ Check-In។

  2. បញ្ជាក់ថាការភ្ជាប់ PMS សកម្ម។

  3. Refresh ទំព័របន្ទាប់ពី sync បញ្ចប់។

  4. បើ date range រវល់ សូម refresh ម្តងទៀតបន្ទាប់ពីពីរបីនាទី។

    ✓ បើ PMS របស់អ្នកគាំទ្រ reservation coverage, Eligible Check-In Units និង AVA Check-In Share នឹងបង្ហាញបន្ទាប់ពី Completion Rate។

កាត coverage នៅតែមិនផ្លាស់ប្តូរ​

អ្វីដែលអ្នកឃើញ: Eligible Check-In Units ឬ AVA Check-In Share នៅតែមើលទៅដូចដើមបន្ទាប់ពី refresh។

ដំណោះស្រាយ៖

  1. រង់ចាំមួយនាទី។
  2. Refresh tab Analytics ម្តងទៀត។
  3. បញ្ជាក់ថា date range ស្របនឹង PMS update ដែលអ្នករំពឹងទុក។
  4. បើនៅតែមិនត្រឹមត្រូវ សូមពិនិត្យថា PMS sync បានបញ្ចប់។

Analytics នៅតែផ្ទុក ឬស្នើឱ្យបង្រួម range​

អ្វីដែលអ្នកឃើញ: tab Analytics បង្វិលយូរ, បង្ហាញ timeout, ឬស្នើឱ្យបង្រួម date range។

ហេតុអ្វីកើតឡើង: ចន្លោះធំៗត្រូវការពេលដំណើរការច្រើនជាងមុន។ អចលនទ្រព្យដែលរវល់ខ្លាំងក៏អាចឈានដល់ request limit លឿនជាងមុន។

ដំណោះស្រាយ៖

  1. រង់ចាំរហូតដល់ 2 នាទីឱ្យសំណើបញ្ចប់។

  2. សាកល្បង date range តូចជាង ប្រសិនបើទំព័រនៅតែ timeout ឬស្នើឱ្យបង្រួម range។

  3. Refresh tab Analytics ហើយសាកល្បងម្តងទៀត។

  4. បើ date range តូចៗនៅតែបរាជ័យ សូមទាក់ទង support ជាមួយកាលបរិច្ឆេទដែលបានជ្រើស។

    ✓ ចន្លោះតូចៗគួរបញ្ចប់លឿនជាងមុន ហើយជួយឱ្យអ្នកដឹងថាបញ្ហាមកពីទំហំ range ឬពីភាពមានទិន្នន័យ។

ការចម្លង MCP config បរាជ័យ​

អ្វីដែលអ្នកឃើញ: ប៊ូតុងបង្ហាញកំហុសបន្ទាប់ពីចុច Copy Codex MCP Config ឬ Copy Claude MCP Config។

ដំណោះស្រាយ៖

  1. ស្នាក់នៅលើ tab Analytics។
  2. សាកល្បងប៊ូតុង copy ម្តងទៀត។
  3. Refresh ទំព័រ ហើយសាកល្បងឡើងវិញ បើ token request អស់ពេល។
  4. បើកំហុសនៅតែមាន សូមទាក់ទង support ជាមួយសារពិតប្រាកដ។

ចម្លង config បាន ប៉ុន្តែ client មិនអាចភ្ជាប់​

អ្វីដែលអ្នកឃើញ: modal បើក ប៉ុន្តែ Codex ឬ Claude មិនផ្ទុក Streamliner server។

ដំណោះស្រាយ៖

  1. ពិនិត្យថាអ្នកបានបិទភ្ជាប់ config ទៅក្នុងឯកសារត្រឹមត្រូវ។
  2. បញ្ជាក់ថាតម្លៃ STREAMLINER_MCP_TOKEN នៅតែមាន។
  3. ចាប់ផ្តើម client ឡើងវិញទាំងស្រុង។
  4. ចម្លង config ថ្មី បើការរៀបចំចំណាយពេលយូរពេក។

ឧបករណ៍ Settings បាត់​

អ្វីដែលអ្នកឃើញ: client ភ្ជាប់បាន ប៉ុន្តែសកម្មភាព settings មិនបង្ហាញ។

ដំណោះស្រាយ៖

  1. ចម្លង config ថ្មីពី Analytics។
  2. ចាប់ផ្តើម client ឡើងវិញទាំងស្រុង។
  3. បញ្ជាក់ថា STREAMLINER_MCP_TOKEN ដែលបិទភ្ជាប់គឺជាថ្មីបំផុត។
  4. ដក Streamliner config block ចាស់ចេញ បើវានៅតែមាន។

ការសរសេរ Settings ផុតពេល​

អ្វីដែលអ្នកឃើញ: ការរក្សាទុក settings មើលទៅជាប់ ហើយត្រឡប់សារផុតពេល ឬ cancel។

ដំណោះស្រាយ៖

  1. ចម្លង config ថ្មីពី Analytics។

  2. ចាប់ផ្តើម client ឡើងវិញទាំងស្រុង។

  3. សាកល្បងការផ្លាស់ប្តូរ settings ម្តងទៀត។

  4. បើបរាជ័យម្តងទៀត សូមពិនិត្យថា token ឬ session អស់សុពលភាពឬអត់។

    ✓ ការអាប់ដេត settings ដែលត្រឹមត្រូវគួរបញ្ចប់ជំនួសឲ្យការជាប់។

ការផ្ទៀងផ្ទាត់បរាជ័យលើការសរសេរ Settings​

អ្វីដែលអ្នកឃើញ: អ្នកទទួលបាន authentication error ពេលរក្សាទុក merchant settings។

ដំណោះស្រាយ៖

  1. ចម្លង config ថ្មីពី Analytics។

  2. ចាប់ផ្តើម client ឡើងវិញទាំងស្រុង។

  3. សាកល្បងការផ្លាស់ប្តូរ settings ក្នុងសណ្ឋាគារដដែល។

  4. បើអ្នកបានប្ដូរសណ្ឋាគារ សូម refresh config បន្ទាប់ពីប្ដូរ។

    ✓ កំហុសថ្មីគួរតែប្រាប់ឲ្យអ្នកបង្កើត MCP config/token ថ្មី។

ប៊ូតុង Download report បាត់​

អ្វីដែលអ្នកឃើញ: អ្នករំពឹងឃើញប៊ូតុង Download report ប៉ុន្តែមិនមាន។

ដំណោះស្រាយ៖

  1. នេះគឺជាអាកប្បកិរិយាដែលរំពឹងទុកនៅក្នុង tab Analytics បច្ចុប្បន្ន។
  2. ប្រើតារាង និងតម្រង date range លើអេក្រង់។
  3. ទាក់ទង support បើអ្នកត្រូវការផ្លូវ export ផ្សេង។

នៅតែជាប់?​

ទាក់ទង success@vouch-technologies.com ប្រសិនបើ៖

  • ❌ Analytics បង្ហាញទិន្នន័យក្នុង Status ប៉ុន្តែ Analytics ទទេ
  • ❌ តារាងមិនអាប់ដេតក្រោយប្ដូរ date range
  • ❌ Issues បង្ហាញពេលវេលាមិនត្រឹមត្រូវ

ព័ត៌មានមានប្រយោជន៍ក្នុងការផ្ដល់៖

  • Date range ដែលអ្នកជ្រើស
  • រូបថតអេក្រង់ tab Analytics
  • លេខបញ្ជាក់នៃ reservation គំរូ