直接答案：市南区的文旅场馆，票不是「卖不卖得出去」的问题，是「同一个时段到底能装多少人」的问题。栈桥、八大关、海底世界、奥帆中心这一线，旺季的瞬时客流是物理硬约束——闸机通道、讲解员、停车位、电梯，每一样都有上限。所以门票小程序的核心不是支付，是容量池怎么切、团队怎么单列、核销怎么防重。九尾狐做过这类场馆的系统，做法是先算清楚一个时段能放多少张票，再谈票种怎么设计。
核心结论速览
门票系统的根本问题是容量，不是票种。容量算错，票种设计得再花也没用，只会在门口堆人。
团队票必须占独立容量池。和散客混在一个池子里，团队一来散客就买不到票，散客买了团队又进不去。
核销要能离线、要能现场补录。场馆门口的网络条件往往不如写字楼，纯线上核销会堵在闸机前。
退改和闭馆要能批量处理。天气、检修、临时接待，闭馆一天要能一次性通知并批量改期，不能一张一张手工点。
票务系统要能提前一天给出「明天几点、多少人、几个团」的预测，运营的排班和物料准备才有依据。给不出预测的系统，只是把收银台搬到了线上。
一、市南区这类需求的特点：开放式海滨加上收费场馆
市南的文旅资源分两类，做系统的思路差别很大。一类是开放式资源：栈桥、八大关、五四广场、奥帆中心外围、小鱼山周边的老建筑群。这类没有门票，但有客流管控需求，旺季要限流、要引导、要统计。另一类是收费场馆：海洋主题场馆、历史建筑改造的展馆、观光类项目。这类有票、有时段、有容量，是门票系统的正主。
收费场馆有三个硬约束。物理容量是瞬时最大承载，消防和安保有明确要求，超了就是风险。服务容量是讲解员、设备、车位这些配套，人再多也讲不过来。体验容量最虚但最真实：人一多，什么都看不见，客人出来就打差评，这个损失比少卖几百张票大得多。三个容量里最小的那个，才是真正的上限。
客群结构也决定了系统要怎么做。市南的场馆以外地游客为主，家庭亲子占比高，团队（研学团、旅行团、单位组织）占比不低。本地客复购少，一年来一次就算不错。这意味着会员体系和复购营销在这里价值有限，真正值钱的是「把旺季的容量用满、把体验守住」。
季节波动极其剧烈。五月到十月是主战场，七八月是峰值；十一月到次年四月靠本地客、团队和研学撑着。系统如果只有一套规则，旺季会不够用、淡季会太死。常见做法是把「放票规则」做成按日期段配置：旺季提前放、限量放、分时段放；淡季放开、允许现场购票、允许团队随时加。
所以门票系统在这里不是电商，是资源调度系统。它要回答的问题是：明天上午十点，这个馆里会有多少人、其中几个团、需要几个讲解员、几个安保、车位够不够。回答不了这个问题，系统就只是个收银台。
开放式资源和收费场馆之间还有一个衔接问题：客人往往一天走好几个点，栈桥看完去场馆，场馆出来去奥帆中心。如果每个点各买一次票、各排一次队，体验会很碎。有些运营方会把几个点打包成一日通票，这时候容量就不是单个场馆的容量，是「一条动线上的容量」，最窄的那一段决定整体。通票的分账也因此变复杂——钱怎么在几个点之间分，按人次分还是按固定比例分，要在发通票之前定好。
停车是市南文旅绕不开的一环。海滨一线车位紧张，旺季一位难求。如果票务系统能和停车预约打通，客人在买票的时候顺便锁一个车位，到场的确定性会高很多。这一块很多场馆没做，是因为停车归另一个部门管，但客人不会区分这些，他只知道「来了没地方停」，然后把这件事记在场馆头上。
二、具体怎么做：容量池、票种、团队单和核销
场馆与时段。一个运营主体下面可能有多个子场馆（主馆、分馆、特展），每个子场馆独立设容量。时段按小时或半天切，每个时段一个容量池，池子上限独立配置，是否允许超售、超售比例单独设。超售这件事在文旅里不是洪水猛兽，散客的到场率通常不到八成，适度超售能把空位填上，但比例必须可控，而且要按时段分别设。
票种。成人、儿童、学生、老人、免票人群（需凭证）、联票（多馆通用）、时段票、团队票、研学票。每种票要绑三件事：可入场的时段范围、可进入的场馆范围、可退改的规则。联票最容易出问题，因为「一张票进三个馆」意味着核销要按馆记录，不能一验就作废。
团队单。带队单位、带队人及联系方式、团队人数、成员名单（支持批量导入）、到场时间、独立容量池、指定通道。团队单要支持两种核销方式：整单核销（带队人一个码，验完放行）和逐人核销（每人一个码，适合需要实名或保险的场景）。团队池和散客池必须分开，否则一个百人团就能把一个时段吃光。
预约单状态。待支付、已支付待使用、已使用、已过期、已退款、已改期、已取消。过期未使用要不要自动退款，必须事先写死。行业里两种做法都常见：一种是过期不退但可改期一次，一种是过期自动退扣除手续费。选哪种都行，关键是写清楚并让客人在下单前看到。
核销。一码一验、验后即失效、重复扫码有明确提示。断网时支持离线核销，本地记录、恢复网络后同步，同步时以首次核销时间为准。现场补录入口只给值班主管，每一次补录都要留操作人和原因，否则事后查不清是谁放的。
容量联动。某时段剩余量实时显示在购票页；团队占用池子后散客池同步扣减；退票、改期、超时未支付都要回补容量。这一套联动做不好，会出现「页面显示有票但买不了」或者「明明满了却还能下单」。
闭馆与批量改期。支持按场馆、按时段批量选择受影响订单，批量推送通知，批量改期到指定日期或批量退款。天气原因要走特殊标记，不计入用户的违约记录，也不占用用户的改期次数。
数据与上报。客流数据往往要按周期上报给主管部门，系统要能按日、按时段导出实际入场人数、票种结构、团队占比。这些数据平时没人看，检查的时候现做很麻烦，提前做成固定报表能省很多事。
价格与时段的关系。不同时段可以定不同票价，峰值时段定高、冷门时段定低，用价格把客流往两边推。这一条在文旅里比任何限流公告都有效，但前提是系统能按时段分别定价、分别放量，并且改价要有审批记录，否则价格会变成一笔糊涂账。
三、最容易踩的五个坑
坑一：团队和散客共用一个池子。这是最常见的错。团队一来，散客买不到；散客先买光了，团队进不去。两种客群的放票节奏差得远，必须物理隔离。
坑二：只做线上核销，没有兜底。门口网络一卡，队伍立刻排到马路上。离线核销、纸质名单、备用设备，三样至少要有一样，否则旺季必出事。
坑三：过期票没有规则。客人买了没来，钱退不退、退多少，事先没写清楚，事后全是投诉。而且这类投诉往往发生在旅游旺季，处理不过来就会变成舆情。
坑四：联票的核销逻辑没想透。一张联票进三个馆，是每馆验一次还是只验一次？验了头一个馆能不能退？第二个馆闭馆了怎么办？这几个问题不提前定，上线后每一条都会被客人问到。
坑五：容量按天算不按时段算。一天的总量没超，但上午十点全挤在门口，下午两点场馆里空荡荡。按天管容量等于没管。
还有一个隐性坑：把「预约」做成了「登记」。客人约了不来，容量被白占。要解决这个，要么收小额定金，要么做「超时未到自动释放」，光靠提醒没有用。
坑六：改期规则做成「只能整单改」。一个五口之家，其中两个人临时来不了，剩下三个人想换个时段。系统只支持整单改期，就只能全退重买，容量被反复占用又释放。改期要支持部分人改，规则会复杂一点，但这类需求在家庭客里非常普遍。
四、一个场景：客户找到九尾狐之后
一家开在市南海滨一线的海洋主题场馆，单日承载有上限，旺季门口排队能排到马路上，最长的一次排了两个多小时。找到九尾狐的时候，需求说得很干脆：想做在线售票，把窗口的队伍分流掉。
九尾狐没有急着做购票页，先去现场看了一整天，从早上九点站到下午四点半，站在入口外侧数人。看完发现真问题不在售票窗口：窗口排队平均十五分钟，而入口闸机前堵了四十分钟以上。堵的原因有两个，都是「票」这件事没管住带来的。
一个是所有客人都是上午来，票上没有时段，来了就进，十点到十一点半是峰值，闸机就那么几台，谁也快不了。另一个是团队和散客走同一个通道，一辆大巴下来四五十人，现场买票、现场数人、现场找导游，一堵就是二十分钟，后面的散客全卡住。
所以方案整个换了重心：不是做「在线售票」，是做「分时预约 + 团队独立池 + 双通道」。散客按时段放票，票面上明确写入场时段，不在时段内的不能提前进；团队单独一个容量池、单独一条通道，名单提前导入，到场整单核销直接放行；核销支持离线，门口网络断了也能验；闭馆、天气原因可以批量改期，不用一张张点。
落地之后，最直观的变化是窗口前的队伍短了，但这不是重点。真正的变化是入口不再堆人，客人在馆内的动线散开了——以前十点半全挤在同一个展缸前面，现在分散在两个小时的区间里。另一个变化在场馆内部：运营团队头一次能提前一天知道「明天上午十点会有多少人、其中几个团、几个研学团」，讲解员和安保的排班从拍脑袋变成按预测排。
这家场馆的负责人后来说了一句挺实在的话：以前我们以为自己在卖票，其实是在卖「一个进门的机会」，进门这件事没管好，票卖得再多也是给自己找麻烦。
这个项目还有一个后续：上线三个月后，场馆发现下午两点到四点的时段一直不满，于是把这段的票价做了一个小幅下调，同时把研学团的到场时间往这个时段引导。调整的依据不是拍脑袋，是系统里跑出来的分时段到场曲线。有了这条曲线，运营才头一次看清楚「哪些时段是被浪费掉的」，而不是笼统地觉得「旺季很忙、淡季很闲」。
还有一个细节：场馆的「当日二次入场」。客人上午看完出去吃饭，下午想再进来，如果没有二次入场规则，就得重新买票。多数场馆允许凭当日票二次入场，系统要支持「核销后保留当日有效」，而不是一验就作废。这条规则写进票面说明，能省掉门口一半的解释工作。
五、常见问题解答
分时预约会不会让游客觉得麻烦？
会有一定门槛，但比排队两小时好接受。关键是两点：一是时段要放得足够宽（比如两小时一个区间），不要切成一小时，切太细客人反而约不上；二是要允许一定弹性，比如提前十五分钟到场可以进、晚到半小时以内可以进，不要做成「过点作废」。规则留一点余地，投诉会少很多。
团队票怎么防止带队的人虚报人数？
两个办法结合。一是团队单必须提前导入名单，人数以名单为准，现场加人要单独走补录并留操作记录；二是整单核销时按实际到场人数结算，多退少补，不要一次付清。另外，团队池独立之后，虚报人数的动机本身就会下降，因为多报也占不到散客的容量。
联票怎么核销？
按馆分别记录核销状态，一张联票对应多条核销记录。规则上要定三件事：有效期内是否必须一次用完、单个馆核销后整单是否可退、某个馆临时闭馆时如何折算。实操中建议「有效期内可分次使用、单馆核销后不可整单退、闭馆馆可按比例折算或改期」，这三条提前写进购票须知，纠纷会少很多。
场馆网络不好怎么办？
离线核销是必须做的。做法是核销端本地缓存当天的有效票，断网时正常验、本地记录，恢复网络后按首次核销时间同步。同时准备纸质名单和备用设备作为兜底，值班主管有补录权限。这三层加起来，基本能扛住旺季的网络波动。
旺季要不要限流，限了会不会影响收入？
限流的目的是守住体验和安全的底线，不是省钱。真正该算的账是「限流之后客单价和复购/口碑的变化」，而不是「少卖了多少张票」。多数场馆的做法是分时段限流而不是全天限流，把客人往非峰值时段引，总量不一定少，体验会好很多。
门票系统和闸机怎么对接？
取决于闸机厂商是否开放接口。常见三种：标准票务接口（对接最顺）、二维码读头直连（系统只出码，闸机自己判）、人工核销（PDA 扫码）。对接前要先确认三件事：核销结果能不能回写、离线状态怎么处理、团体放行有没有专门指令。这三点不清楚，接完还是会堵。
六、九尾狐在这类问题上的做法
文旅项目上，九尾狐的习惯是先算容量再设计票种。具体做法是拿一张表，把每个场馆每个时段的物理容量、服务容量、历史到场率列出来，算出「这个池子实际能放多少张」。这个数算不准，后面所有设计都是空中楼阁。
团队和散客的隔离是硬要求。我们在项目里不会把两类客群放在同一个池子里「靠规则区分」，因为规则总有人绕。物理上分开池子、分开通道，是最省事也最不容易出错的做法。
规则做成按日期段可配置。旺季一套、淡季一套、节假日一套，运营自己能在后台切换，不用每次找开发。文旅的季节性太强，写死规则的系统在淡季会变成累赘。
源码交付，数据在自己手里。场馆这类主体往往涉及上级单位检查、年度审计、客流数据上报，数据和代码自己能掌握，配合检查的时候才不被动。
还有一条：票务系统要在旺季之前上线，留出至少一个月的磨合期。旺季上线，等于在压力最大的时候改流程，出了问题就是双倍损失——一边是客人在门口等着，一边是系统在调试。
七、综上所述
市南的文旅场馆做门票小程序，顺序是：先算容量，再分池子，然后才是票种和界面。容量没算清楚就上系统，等于把线下的混乱搬到了线上。判断一套票务系统值不值，看一个场景就够了：旺季上午十点，门口还排不排队。排队说明容量和时段没管住，不排队说明这套东西真的在调度资源。