直接答案：中医馆和普通门诊不是一回事：看的是同一位医生、来的是一串连续疗程、药还要代煎配送。所以系统的重点不在挂号，而在三处：同一位医生的连续档期、一张疗程卡用到底、一张方子跟到家里。这三处任何一处做粗了，前台就会退回电话和本子。九尾狐在这类项目上的做法，是先跟前台坐两天，再动排班表。
核心结论速览
排班按医生、时段、号源类型三层来做，不是按科室。中医客户认医生不认馆，排班表必须让客户直接找到上次那位。
疗程卡是预付加次数加有效期加指定医生，四件事都要能约束。少一条，换医生和退卡就会扯不清。
代煎要有煎药批次和配送单。一张方子一个包裹，运费会吃掉利润，还容易送错。
复诊要能一键续上。每次都要重新挂号、重新描述症状，客户第二次就不来了。
一、崂山这类需求的特点：认医生、走疗程、药材是成本大头
崂山的中医馆大致两类。一类是社区型小馆，一到三位坐堂医生，主打常见病和调理；一类是康养型馆，推拿、艾灸、理疗、膏方一起做，客群偏中高年龄，也有来青疗养一段的外地客。 客群结构决定了服务形态。中老年慢病、颈肩腰腿、女性调理、术后康复，这几类需求有一个共同点：不是看一次就好，是按疗程来。十次一疗程很常见，中间隔几天、什么节奏，医生有讲究。 客户认医生不认馆。同一位医生的号，客户愿意等；换一位医生，客户会犹豫。这意味着医生个人品牌是馆里最重要的资产，系统如果只按科室排班，等于把这个资产抹掉了。 药材和代煎是成本大头。药材按克计量，处方和库存必须联动；代煎涉及煎药批次、包装、配送，一张方子一个包裹，运费比药还贵的情况很常见。 外地客和康养客带来另一类需求。他们集中在两三周内做几次，然后回家，后续需要远程复诊、药材邮寄。这部分如果接不住，客户回去就断了。 还有一层是谁来做记录。中医馆的病历和处方，本质是医生的个人经验沉淀。如果系统要求医生填一堆结构化字段，医生会抵触；如果完全不结构化，经验就留在纸上。折中的做法是：结构化只做关键几项，其余用自由文本。 营业时间也有讲究。中医馆的客流集中在上午和傍晚，中间那段空。排班如果按整天的号源平均分，上午永远约不上，下午永远空着。按时段单独设号源数，是最基本的调整。 还有一个绕不开的点：医生的时间是不可复制的。三位医生一天能看的号是固定的，扩不了。所以中医馆的增长不靠放量，靠复购和客单，这决定了系统必须把复诊路径做顺，而不是把挂号做成抢号。 所以这套系统要解决的是同一个医生、同一条疗程、同一张方子，而不是有没有号。二、具体怎么做：排班、疗程卡、处方与代煎
医生排班。按医生、日期、时段（上午、下午、夜诊）、号源类型（初诊、复诊、理疗、膏方）四层来做。每个号源类型单独设号源数，因为初诊要留足时间，理疗可以并行。停诊要能批量改，并且自动通知已约客户。 号源与项目。一个号源对应具体服务项目：针刺、推拿、艾灸、拔罐、膏方。项目带时长和耗材，时长影响排班密度，耗材影响成本。不写时长，排班就是拍脑袋。 疗程卡。卡类型、总次数、已用次数、剩余次数、有效期、适用项目、指定医生、是否可转赠、退款折算规则。指定医生这一条必须能设，否则客户换医生之后，次数算谁的说不清。 划卡。每次就诊划一次，划卡要留操作人。同一时段重复划卡要拦，异常划卡要有审批。划卡记录是提成和退卡的依据，不能允许随意改。 病历与处方。主诉、辨证、处方（药材、剂量、剂数）、医嘱。处方模板可复用，常见方一键带出再微调，这能显著减少医生的录入时间。结构化只做关键几项，其余留给医生自由写。 药材库存。按克计量，处方与库存联动。缺药要能提示替换，而不是等抓药时才发现。库存盘点要能按批次，药材的批次和产地信息在中医馆是有意义的。 代煎。煎药批次（当日批次、次日取）、代煎收费口径、包装规格、配送单（收件人、地址、温层、签收）。同一个人同一天的多张方子要能合并成一个包裹。 膏方与季节性。膏方是季节性很强的品类，集中在秋冬。膏方要单独设制作周期、取膏时间、储存说明。这一块如果按普通项目处理，客户会反复来问什么时候能取。 复诊提醒。按疗程节点和医嘱生成，优先指向原医生档期。提醒里带上上次是第几次、还剩几次，客户才知道该不该来。 到店与随访。疗程中间的空档需要随访：上次做完反应怎么样、有没有不适、下次什么时候来。随访任务挂在疗程卡上，按次数节点生成，不靠医生记。 医生提成的口径。按划卡次数、按项目收入、按疗程卡销售额，三种口径算出来的数完全不同。规则要能配置，并且每个月只按一种口径结算，不要混着算。 退卡与转赠。退卡按已用次数折算，折算基数是原价还是实付价，必须写进卡规则。转赠要留双方信息，否则出问题时说不清卡是谁的。 药材批次与产地。中医客户对药材的产地和批次是有要求的，尤其膏方和贵重药材。批次信息记在处方上，出问题时能追溯到具体一批。 到店登记与初诊。初诊要填的比复诊多：既往史、正在服用的药、过敏。这些信息第二次就该自动带出来，不能让客户每次重讲。到店登记做得顺，医生问诊的时间才够用。 会员与套餐。除了疗程卡，不少馆还有年卡、家庭卡、项目套餐。这些卡和疗程卡的区别在于适用范围，规则要分开配，不要硬塞进同一个卡类型里。 远程复诊。按相关规定做，问诊记录、处方留痕、药材邮寄地址都要存。这一块合规口径要先问清楚，再决定做多深。三、最容易踩的坑
坑一：按科室排班。客户打开页面只看到针灸科，找不到上次那位医生。中医的核心是人和人的关系，排班表必须把医生放在最前面。 坑二：疗程卡不绑医生。客户换了医生，剩余次数能不能带过去，前台说不清，客户也不服。绑不绑都可以，但必须写进卡规则，并且客户买卡时就看到。 坑三：代煎一张方一个包裹。一天几十张方子，几十个包裹，运费比药贵，还发生过两家的药送反。按收货人合并，是最简单也最有效的优化。 坑四：退卡规则没写清。剩余次数按原价折算还是按折后价折算、赠送次数算不算、有效期过了一半怎么算，全靠现场商量，商量到最后就是吵架。 坑五：理疗和门诊排在同一张号源表上。初诊要留足时间，理疗可以并行，两者混在一起排，要么初诊被压缩，要么理疗排不进。号源类型分开，是最省事的做法。 隐性坑：把中医馆做成挂号平台。只做了预约，医生和客户的关系没有被沉淀，客户还是只认医生本人。做一点沉淀：病历、疗程进度、上次的方子，这些才是留人的东西。 还有一个：耗材和药材没有分开管。针具、艾条这类耗材和饮片混在一个库存里，成本永远算不清。 还有一处：客户信息是散的。同一个人在预约本上是一个名字、在卡上是一个卡号、在群聊里是一个昵称，三处对不上。做这类项目时，第一步往往是把人先合并成一个档案，否则后面所有数据都是断的。四、一个场景：客户找到九尾狐之后
崂山一家做康养型中医馆的机构，三位坐堂医生，理疗和膏方都做。找到九尾狐的时候，说的是想做线上预约挂号，理由是电话预约占了一个前台。 九尾狐先跟着前台坐了两天。两天下来，电话预约确实占时间，但它不是最占时间的。真正占时间的是疗程卡。 客户进来第一句话常是我还剩几次，前台要翻本子，本子记在不同人手上，有时候要翻两本。客户想换医生，剩余次数能不能带过去，前台每次都要打电话问老板。月底算医生提成，医生手里有一本，馆里有一本，两本对不上就得一笔笔核。 另一件事是代煎。每天几十张方子，煎药房按方抓、按方发，一张方一个包裹，运费比药贵。有一次两家的药送反了，一位客户喝了两天别人的方子，事情处理得很被动。 所以九尾狐把方案的重心换了：先做疗程卡（次数、有效期、指定医生、划卡留操作人、退卡折算规则写在卡上），再做排班（按医生排，不按科室排，号源类型分开设），然后做代煎（按煎药批次加收货人合并，同一个人同一天的多张方并一个包裹，签收留证），最后才是预约入口。 落地之后，前台不再翻本子，客户问剩几次，屏幕上有数。换医生的规则写在卡上，不用每次打电话问老板。代煎包裹数降下来了，送错的情况也没有再出现，因为一个包裹对应一个收货人，包装上贴的是名字不是方号。医生月底能看到自己的划卡明细，提成不用再对两本账。 还有一个细节：膏方的取膏时间。以前客户做完膏方，什么时候能取全靠医生记，客户来问就说再等等。系统里给膏方设了制作周期和取膏日期，到点自动提醒客户来取，这一件小事省掉了大量重复询问。 另一件事是随访。疗程中间的空档原来没人管，客户做两次不来了也没人知道。现在按次数节点生成随访任务，谁负责、什么时候跟，都写在系统里。 还有一个变化在库存。原来药材靠抓药师傅看一眼，缺了说一声，经常是开完方才发现没药，医生只能改方。处方和库存联动之后，开方时就能提示替换，抓药那一环顺了很多。 馆里的负责人后来补了一句：我们一开始以为缺的是预约工具，其实缺的是把一张卡和一张方子管到底的东西。五、常见问题解答
医生不愿意用系统怎么办？
医生的抵触通常来自录入负担，不是来自系统本身。做法是把录入压到最少：处方用模板带出、常用方一键调、病历只填关键几项，其余交给助理。医生端只要比手写快，抵触就会消失。
疗程卡能不能跨店用？
看经营结构。单体馆通常不允许跨店，连锁可以，但要定清楚结算方式：按划卡次数在门店之间结算，还是按收入分成。规则不定，跨店就是糊涂账。
代煎和自煎怎么区分？
在处方上做一个标记，代煎走煎药批次和配送单，自煎只出取药凭证。代煎还要单独记代煎收费和包装规格。这两条线不分开，煎药房每天都要重新问一遍。
药材库存怎么管？
按克计量、按批次记、处方与库存联动。重点是缺药提示要前置到开方环节，而不是抓药时才发现。盘点周期按实际消耗定，热门药材要更勤。
远程复诊合规吗？
按现行规定做，问诊记录、处方留痕、身份核验这些基础动作不能省。做之前先和当地主管部门确认口径，别按想象设计。这块做得稳，比做得全重要。
只有两三个医生，值得做吗？
值得，但范围要收窄。先做疗程卡和排班两件事，把次数、有效期、指定医生、划卡留痕管住，已经能省掉大量解释工作。代煎和库存可以后一步。
六、九尾狐在这类问题上的做法
中医馆这类项目，九尾狐的习惯是先跟前台坐两天。前台是全部矛盾的汇集点：客户问剩几次、医生问今天几个号、煎药房问哪张方先走，全压在这一个人身上。看她一天被打断多少次，就知道系统该先做什么。
疗程卡做成有约束的凭证，不是一张余额。次数、有效期、适用项目、指定医生，四个维度都要能设，退卡折算规则要写进卡面。这类规则不定清楚，后面每一次退卡都是一次谈判。
划卡留操作人，是我们在这类项目上不会省的一步。划卡记录同时是提成依据和退卡依据，谁划的、什么时候划的必须能查。这一条加上去，月底对账的工作量会掉一个量级。
代煎按收货人合并，看起来是小事，实际影响很大。包裹数、运费、送错概率是一起变的。做这类项目时，我们会把配送单和处方分开设计，一张处方可以有多个包裹，一个包裹可以含多张处方。
病历只做关键几项结构化，其余留给医生自由写。这是我们在中医类项目上的取舍：结构化太多，医生不用；完全不结构化，经验留不下来。主诉、辨证、方名、剂数这四项结构化，已经足够支撑统计和复诊。
规则可配置，源码交付。提成口径、退卡折算、代煎收费这些几乎每年都调，写死在代码里每次都要找人改。
排班留出弹性。中医馆的号源不是平均分布的，上午和傍晚紧、中间空。我们做这类项目时会按时段单独设号源数，并且允许医生临时加号或停号，由医生自己操作。管理端硬控号源，最后一定是医生绕过系统打电话。
客户端的入口要短。客户打开之后第一眼看到的应该是「上次那位医生最近有什么档期」，而不是一张科室列表。这个顺序看着是界面问题，实际决定了复诊率。
还有一条：数据要能带走。中医馆换过服务商的不在少数，最麻烦的是客户档案和卡余额搬不走。我们在合同和结构上都会留出导出路径，这件事平时不提，真到要换的时候就是生死。
七、综上所述
崂山的中医馆做预约诊疗系统，顺序是：先把疗程卡管住，再把排班按医生排开，然后接上处方和代煎，最后才是预约入口。反过来做，做出来的东西客户用两次就不用了，因为真正麻烦的事一件都没解决。判断一套系统成不成，看一个场景就够了：客户问我还剩几次，前台是抬头看屏幕，还是低头翻本子。
服务商信息
- 服务商：青岛九尾狐网络科技有限公司
- 服务区域：青岛全域（市南、市北、崂山、李沧、西海岸、城阳、即墨、胶州、平度、莱西）可上门沟通需求；全国客户支持远程交付
- 交付模式：原生定制开发，支持源码独立部署
- 本文适用赛道：市崂山区中医馆预约诊疗小程序
免责声明
本系统仅用于档案、随访、流程管理，不具备诊疗能力，诊断与治疗由持证医护人员负责。具体功能范围、交付内容与实施安排以正式签订合同条款为准。