预订引擎、渠道管理系统与PMS的差异｜小型旅宿如何选择

研究如何让旅宿接受线上预订时，会看到「预订引擎」「渠道管理系统」「PMS」等词。各服务的名称与功能范围不同，一项产品也可能具有多个角色，因此不能只看名称选择。

先整理主要角色如下。

预订引擎：在旅宿官方网站等地方接受预订
渠道管理系统：同步多个销售管道的房量、房价与预订信息
PMS：管理预订后的房间分配、入住、清洁、会计、顾客信息等

本文以小型民宿、日式旅馆、Pension为对象，说明如何从目前预订管道与日常作业判断需要哪些系统。

先用一张图思考预订流程
预订引擎：官方网站接受预订的入口
1. 与预订表单的差异
2. 可能只需要预订引擎的旅宿
渠道管理系统：连接多个销售管道
1. 减少重复预订的机制
2. 较容易需要渠道管理系统的旅宿
PMS：管理预订后的住宿作业
1. PMS不是预订网站
2. 较容易需要PMS的旅宿
比较三者差异
决定「哪个是权威原始记录」
小型旅宿如何选择
比较前向服务商询问的事项
示范时重现实际的一天
常见的选择失误
导入前检查清单
请AI协助比较的提示词
总结
参考资料

先用一张图思考预订流程

旅客
├── 旅宿官方网站 → 预订引擎
├── OTA A
├── OTA B
└── 电话与电子邮件
↓
渠道管理系统
↓
PMS
├── 房间分配
├── 入住
├── 清洁与餐饮指示
└── 会计与顾客管理

这是协助理解角色的一般示意图。实际上，也有预订引擎与渠道管理系统合一、包含PMS的整合型产品，以及将电话预订直接输入PMS的流程。

并不是「一定要分别签约购买三种产品」。

预订引擎：官方网站接受预订的入口

预订引擎也称自家预订系统、Web预订系统、Booking Engine等。它是在旅宿官方网站设置「查询空房」「预订」按钮，让旅客选择日期、人数、房间、方案后申请的地方。

主要功能范例如下。

依日期与人数查询空房
显示客房、住宿方案、房价
输入预订者信息
受理预订与确认电子邮件
受理取消
优惠券与会员房价
线上付款
多语言显示
显示预订规约与取消条件

与预订表单的差异

一般联系表单也能发送「希望住宿日期」，但不一定具有确定空房的机制。如果直到旅宿回复才成立预订，就比较接近受理预订请求的流程。

预订引擎通常会参照房量与房价，当场确定预订。但服务与设施设置也可能采「请求预订」，因此要在使用规约与确认电子邮件中说明成立时间。

可能只需要预订引擎的旅宿

客房数少
销售以官方网站为主
不使用OTA，或只使用一个
目前台账足以管理房间分配与清洁
每天有人可以确认预订信息

但请确认，同一负责人能否立即更新电话与线上预订的房量。

渠道管理系统：连接多个销售管道

OTA指线上旅行社或住宿预订网站。在多个OTA与官方网站销售相同客房，就需要在各处录入房量、房价，并在每次预订或取消时更新。

渠道管理系统具有集中管理多个销售管道，整合房量、房价、方案、预订信息等的角色。英语服务有时称为Channel Manager。

减少重复预订的机制

最后一间房在OTA A被预订后，若能迅速关闭OTA B与官方网站的房量，就能减少将同一房间卖给两人的风险。

但导入渠道管理系统，不代表绝对不会重复预订。

整合有时间差
有不支持的方案或销售管道
忘记输入电话预订
房型对应错误
发生通讯故障或维护
OTA与设施使用的房量单位不同

导入时要确认哪些销售管道与哪些项目即时整合。只标示「可以整合」，不代表房量、房价、预订、取消、方案、付款信息全部都双向运作。

较容易需要渠道管理系统的旅宿

在多个OTA销售相同客房
希望官方网站与OTA共用预订房量
希望将房价或停售批次反映到多个网站
预订通知的转抄作业成为负担
房量更新延迟与输入错误增加

PMS：管理预订后的住宿作业

PMS是Property Management System的缩写。日本观光厅也称为顾客预订管理系统，是支持住宿预订与馆内作业的核心系统。

功能范围依产品与设施规模差异很大，范例如下。

预订台账
客房分配
入住与退房
住客信息与顾客历史
清洁状况与客房状态
餐饮、过敏、接送等指示
营收、开账单、入账、收据
入住率与营收报表
住客名簿相关作业
与电子锁、POS、付款、会计等整合

PMS不是预订网站

PMS即使有预订台账，也不一定能让旅客从官方网站预订。可能另外需要从预订引擎或OTA接收资料的整合。

反过来，若预订引擎附有简易顾客管理或入住功能，小型设施也可能不需要独立PMS。

较容易需要PMS的旅宿

客房与员工增加，纸本或电子表格难以共享
希望连动预订后的房间分配、餐饮、清洁、会计
希望集中电话、OTA与自家预订信息
多位员工或多个设施同时确认
希望将顾客历史、营收、入住率用于改善运营

比较三者差异

观点	预订引擎	渠道管理系统	PMS
主要使用者	预订旅客与预订负责人	销售与预订负责人	柜台、清洁、会计、经营者等
主要角色	官方网站接受预订	同步多个销售管道的房量、房价、预订	管理预订后的住宿作业
主要对象	日期、人数、方案、预订者输入	OTA与官方预订的房量及销售信息	房间分配、住客、客房状态、会计等
即使只有一个OTA也需要吗	接受自家预订时可列入候选	人工作业足够时也可能不需要	依馆内作业复杂度判断
重复预订对策	可管理自家房量	以同步多个销售管道为主	集中已整合预订与电话预订
产品形式	独立或整合型	独立或整合型	独立或整合型

此表呈现一般角色。即使产品名称写PMS，也可能包含渠道管理系统或预订引擎。比较时应确认需要的作业包含到哪里，而非只看产品分类。

决定「哪个是权威原始记录」

整合多个系统时，如果同一预订或房量的修改位置不明确，资料就会不一致。

例如，导入前先决定以下事项。

在哪里建立客房与房型
在哪里输入基本房量
房价与方案以哪里为权威原始记录
电话预订最先录入到哪里
在哪里受理取消，自动反映到哪些范围
在哪里更正住客信息
在哪里确认已付款与未付款
各系统数字不同时，以哪个为准

即使说明「全部连接」，修改方向与反映时间也不一定相同。应向服务商确认整合图与运营步骤。

小型旅宿如何选择

阶段1：列出目前预订管道

以过去一个月或旺季为例，记录以下件数与作业。

电话预订
电子邮件与联系表单
官方网站预订
各OTA预订
熟客与旅行社预订
当天预订与直接到店

也要记录每次预订、变更、取消时，由谁更新哪个台账、更新几次。

阶段2：选一个困扰的作业

目的不同，最先需要的系统也不同。

主要困扰	最先考虑的角色
只能接电话，错过营业时间外预订	预订引擎
各OTA房量更新负担大，担心重复预订	渠道管理系统
预订后房间分配、清洁、会计共享繁琐	PMS
三者都分散，需要大量转抄	可整合的组合或整合型

目的应具体到「减少每天发生的一项转抄」，而非只是「导入高功能系统」。

阶段3：从最低必要配置开始

客房少，以官方预订为主

预订引擎加上立即反映电话预订房量的流程，可能已足够。若高功能PMS只会增加输入作业，就不适合。

在多个OTA与官方网站销售

渠道管理系统的优先度提高。确认使用中的全部OTA与预订引擎都受支持，并可正确对应房型、方案。

多位员工共享馆内作业

可考虑以PMS为中心，集中渠道管理系统与预订引擎的预订。也要确认不只柜台，清洁与餐饮负责人也能在必要范围内查看必要信息。

一人或家族经营

比起功能数，更重视代为设置、电话支持、故障时替代流程，以及账单是否容易理解。避免只有一人了解设置的状态。

比较前向服务商询问的事项

整合

能否与目前使用的OTA、预订引擎、PMS整合
房量、房价、预订、变更、取消哪些属于整合范围
单向还是双向
一般反映时间与故障时行为
能否处理房型、含餐方案、连住、儿童房价
日后能否更换整合对象

预订流程

预订成立时间
超额预订时的责任分工与处理窗口
电话预订、休馆日、包场、封房的录入方式
如何处理取消费与退款
预订变更如何传达各销售管道

付款

能否同时处理现场与线上付款
付款代办公司与合同主体
付款手续费、退款手续费、入账周期
是否采旅宿不保存卡片信息的配置
取消与未通知而未入住时的收款步骤

预订系统与付款系统角色不同。即使预订引擎有付款功能，也应另外确认合同、手续费、入账、退款、本人验证的条件。

资料与权限

住客信息保存在哪里，由谁查看
能否按员工区分权限
是否保留操作历史
能否撤销离职者或网站制作公司的访问
资料保存期限与删除方式
合同结束时，能否导出预订、顾客、营收资料
导出格式与是否提供移转支持

故障与支持

故障时能否受理预订
房量同步停止时如何通知
夜间与假日的联系方式
恢复后如何比对预订重复或缺漏
初始设置、资料移转、员工训练由谁负责
说明手册是否让不熟悉IT的人也能理解

示范时重现实际的一天

不只看功能清单，也用虚构预订进行以下操作。不要在示范中输入真实住客信息。

从官方网站预订一间房
确认其他销售管道剩余房数是否变更
新增电话预订
变更日期、人数、餐饮、房间
取消一件预订
确认退款或现场结算状态
共享房间分配与清洁状态
导出预订清单与营收
变更员工权限
询问无法通讯时的替代步骤

除了日常操作，也试做变更、取消、故障等例外，才能了解实际负担。

常见的选择失误

只依月费选择

比较包含初始费用、预订手续费、付款手续费、追加整合、支持、资料移转、装置费用的总额。即使价格便宜，只要仍需转抄，就会持续付出人力时间与错误成本。

认为功能越多越安心

未使用功能多，初始设置、教育、权限管理、故障位置也会增加。应区分目前作业与一年后需要的作业。

只看支持OTA的数量

重要的是能否以所需方案与房量单位，正确整合旅宿实际使用的OTA。

运营图漏掉电话预订

即使线上房量同步，没人输入电话预订，也无法防止重复预订。熟客、团体、旅行社、包场都要包含。

不确认合同结束时的情况

避免转换服务时无法导出顾客、预订资料，无法查看过去报表，或域名、付款合同是服务商名义等问题。签约前确认旅宿要持续管理的资产与解约步骤。

导入前检查清单

已列出目前预订管道与件数
已掌握预订、变更、取消时的转抄作业
已选定最先解决的一个困扰
已区分预订引擎、渠道管理系统、PMS的必要角色
已决定房量、房价、预订的权威原始系统
已确认全部销售管道的整合项目与方向
已决定电话预订与包场录入方式
已确认线上付款合同、手续费、退款条件
已确认员工权限、操作历史、个人信息保存位置
已准备故障联系窗口与纸本、电子表格等替代步骤
已在示范中试做预订、变更、取消、退款
已确认解约时的资料导出与移转条件
已比较总费用，而非只看月费

请AI协助比较的提示词

服务费用与整合对象会变更，应记录官方页面与报价单的确认日期。不要将管理后台密码或真实预订者信息交给AI。

请协助小型旅宿选择预订系统。

首先请提问并整理以下项目。
- 客房数与房型
- 电话、官方网站、使用中各OTA的预订件数
- 目前使用的预订台账、付款、会计系统
- 预订、变更、取消时困扰的作业
- 员工数与必要权限
- 必要的多语言、付款、清洁、餐饮、报表功能
- 不只月费，也含初始费用与手续费的预算

接着请将必要角色分为
「预订引擎」「渠道管理系统」「PMS」「付款」。

不要一律推荐同一产品，请将官方信息确认的功能、未确认事项、
报价时应提问的内容整理成表格。
不要处理真实住客信息、密码或卡片信息。