关于“许愿”，想听听大家的意见

23年10月至今，很快两年多过去了

暴雨从品牌创立之初，我便立下初衷

把用户当朋友对待，做一个以“消费者主导”的品牌

然而，看似简单的一句话

做起来却是相当的难，不是一般的难

我们对着初衷，做了很多事

比如我们设立了“许愿墙”版块，更多听从大家的建议

比如我们坚持性价比路线，让买家朋友们能少花钱少踩坑

比如我们坚持做不赚钱的“寄卖”业务，只为服务好买家朋友

还有很多比如，大家应该也能感知到

但也有很多时候，我和我们团队，在一些事务中也会忘了初心

我也经常反思，为什么落实和现实会有差距

----------------------------------------------------------

2026年，是一个新的开始，也是对初衷更好践行的开始

我计划把“暴雨的初衷”，拆成可落实的行为准则

让我们的初衷能更加贴地，而不是停留在口号

所以，我们会更加关注大家对产品的想法和意见

所以，我们会更加关注大家的购物体验和感受

过往，大家只是在许愿墙提出自己的想法

但，不知道自己的想法最终能不能实现

也不知道自己的需求什么时候能被实现

后续，我希望能彻底改变这个问题

大家所有提及的想法、需求、意见、体验

后续我们都会进行纪录、汇总、跟进、反馈.....

从“暴雨的初衷”出发，真正跟大家用心交朋友

真正把暴雨变成“消费者主导”的品牌

----------------------------------------------------------------

如果你们有更好的，关于许愿墙的管理意见

欢迎在本贴留言，我都会逐一查看回复

最后，也感谢一直以来对暴雨宽容以待的朋友们

下体外观仿真   丰富通道类型   保证通道可更换前提下  视觉不违和

把重复的许愿  可以合并，然后许愿的 能看到 基本进度，那就太好了

可以规范分类与发帖模板，提升内容有效性，也可以结合现有产品业务来管理优化，如产品、功能、体验、服务、活动类等；

目前我觉得需要解决的问题有“重复许愿”和“许愿后的进展度”这两项需要着重关心。建议根据暴雨自身能力，每月或固定一段时间，列出一些暴雨现在有能力进行试验的实验性项目，然后由玩家投票选取几项，开始试制。然后根据项目阶段：“许愿意见征集”，“内部可行性评测”，“试验性制作”，“小范围公开测试”，“上市”/“项目中止”等几个阶段制作一个定期更新的表格或进度条，并开设项目统一回复贴讨论研发进度与持续收集意见。在选取试验项目中，鼓励玩家实际参与，并对给出关于核心问题的具体解决方案的人给予一定奖励。例如昨天的写帖子“关于未来指骨3.0的改进建议～”的老哥/老姐，如果他的设计确实有效并且能量产，我认为是应该积极鼓励的。

参加过一些数码产品的内测，做法可以参考
①规范许愿格式，简单点的话就是做一个链接，做一张表，这种小免费的小程序就可以做了，不过考虑到论坛，也可以做成论坛填表的格式
里面选择许愿类型，比如【新品】【改进】【bug】【活动】【瑕品】【其他】，用于确定官方的对接人，再就是具体的对象，比如盘古tpe、硅胶，具体尺寸配置，许愿内容
最后搞一个汇总贴，入选的置顶依次分大类排列，可以最终落到一张Excel表里，
把入选许愿当项目进度管理，立项→确定定方案→研发→内测→公测（试上市/试运行）→迭代/结案
对于有贡献的人，提供内测/公测资格或者绑定人的代金券，表格里留名，必要时可以评选年度军师粉什么的（看销路及手头宽裕程度）
顺手贴一个对千面抱枕的方案改进建议

只有具备相应的产能与技术储备，梳理引导用户的需求，才能有效的践行“用户主导”的理念，不然反倒会加深“用户与销售”“市场与研发”之间的成见。
获取用户需求的渠道有很多，“许愿”对厂家来说是是一种较为便捷的，但并不唯一，使用不当也会存在“陶片放逐法”式的过分平权弊端。
先说“渠道”，目前的讨论平台主要为：视频网站、贴吧、论坛以及厂商的电商与微信，群体的垂直度，消费欲望逐步提升。需要有权重的获取各渠道的信息。越外围的需求可能越不切实际，但也能映衬出可能的发展方向，越向内的需求则越实际，越能带来收益。可以组织人手进行对应的收集工作（例如统计电商/微信统计咨询信息等），相信公司已经在做这方面的事了。
再说“许愿”，结合之前对产能和技术的描述。
可以先简单的将愿望分为“身型需求”与“技术工艺”两个部分。对于“身型需求”，存在产能与能力瓶颈，建议论坛可以根据材质类型开一个或多个身型许愿贴，公司结合论坛和其他渠道收集的信息，列出计划制作的身型，在论坛中发布，供大家讨论（鉴于论坛的准入机制，是否开启投票需要谨慎考虑）；对于“技术工艺”建议公司基于现有研发团队的组织架构，分列不同类别的帖子标签，用户创建许愿贴时，需要添加涉及的技术标签，便于分类与归口，公司同样定期对汇总需求进行技术分析，列出可行需求与优先级进行开发，不可行的愿望给予简单的解释，个人认为“愿望”大概率是过饱和的，建议给予技术人员跟多的讨论与决定权，至于后续是定期汇报的透明开发，还是闷声发大财式的制造惊喜，还得公司讨论决定，鉴于过往“预公布”产品的结果，还是建议等功能稳定后再进行公布。
其实实际说下来，做“许愿”，除了立规矩外，还是需要投入对等的人员进行“愿望”的拆解、维护与实现，且“许愿”方式也需要根据实际情况更新迭代。在期待其带来产品发展方向的同时，也需要防止其变为技术一言堂或是用户跑火车的场地。