现在有什么问题就是你提一个工单吧，那么大的问题，我在群里和你说了还不行，就要让你提工单，那这个群到底是干什么用的？如果所有沟通都要走工单，那加群的意义又在哪里？有事就提工单呗？
以前也不这样的，现在就知道推，出问题不说解决，不给办法。
那干脆再怀旧一点，开个漂流瓶功能算了，遇到 bug 我就写张纸条塞瓶子里，随缘漂到你们总部。好歹漂流瓶还有个“随缘”的说法
有微信有群就是不用就是玩，就在群里搬视频号就完事了。有时候明明是小 bug，顺手反馈一下的事没想兴师动众，也就是顺嘴提一句，但既然你们这么重流程轻沟通，那以后也不多嘴了。
哦对，工单提了也不一定给你解决，就在那挂在，让你看看日志，看看业务规则，要不就是扯皮拖着，明道云我们用了 7 年了，产品在变，推诿的手法也在变，唯独解决问题的速度不见长进。
如果连基本的倾听都做不到，以后出了问题，我们也懒得再开这个口了。
看了那么多，我觉得：
当你是明道云客户，给给明道云钱的，遇到 bug 往死里喷，论坛发帖的喷。
当你是用明道云挣钱的，遇到 bug 影响交付的，首先不是喷和走工单修复 bug，而是想办法绕过 bug，换个方式实现功能完成交付。然后再喷。
此外，私有化交付的，真心建议用 1 个固定版本交付完了，就别去升级了，免得出 bug，哈哈
敲黑板：
没错，3 最真实了，有人站出来发声你要是觉得不对你可以沉默，非要反驳型人格附体装杯
我的目的是提出问题解决问题，公有版出了问题我们一点办法没有，工单提了解决时间未知，顾问只会让你提工单，那我怎么向我的用户交代，也学明道让我的用户提一个工单吗？我就请问我怎么和客户交代？
看了那么多，我觉得：
当你是明道云客户，给给明道云钱的，遇到 bug 往死里喷，论坛发帖的喷。
当你是用明道云挣钱的，遇到 bug 影响交付的，首先不是喷和走工单修复 bug，而是想办法绕过 bug，换个方式实现功能完成交付。然后再喷。
此外，私有化交付的，真心建议用 1 个固定版本交付完了，就别去升级了，免得出 bug，哈哈
个人感觉还是因为升级后导致的 BUG 增多，给用户带来了麻烦甚至“事故”。以前，用户因为喜欢明道云，而且那段时间 BUG 少，用户还能接受。后来因为 BUG 不断增多，搞得用户不胜其烦的时候，对明道云的那种喜爱会慢慢转变为不满意，不满意积累的多了，积累的久了，会变成不耐烦。最终不耐烦被积压成了火药桶，不知在哪个瞬间被点燃爆炸。用户心理从愿意体谅到我凭啥成了你们的免费测试，我把问题告诉你们都已经很不错了，你们还要我写一堆报告来描述问题，这个事情我没有义务，你们的问题你们看着办，不修复，损失的是你们自己，大不了我换平台了。。。
以上的心历路程必须是用户才能真切的感受到。这个时候用户还愿意把它吐槽出来，其实对明道还是抱有一丝期待和不舍的。HAP 作为一个承载伙伴生产力工具，以及最终用户数字化底座的平台，其性能和功能的稳定何其重要，不容得任何的借口。因为人家把“身家性命”交给了你，这是何等的份量！建议明道加强内部代码质量管理，从源头抓起，激发员工责任心，强化测试环节，守住出厂前最后一道防线。咱们不是还有 800 多伙伴嘛，发挥伙伴的力量，版本可以推慢点，但让伙伴们帮着充分测试起来，给与伙伴测试贡献奖励，把生态的力量发挥到极致。
相信睿智的任总一定能妥善解决好这件事情，明道云再上新台阶！
意见最大的是明明有渠道，明明反馈了，非要你提工单，我也让我的用户提一个工单？等什么时候明道的工单闭环了，我再给我的用户闭环？
用户不会管你什么问题，用户只会问你我钱花了，生产环境什么时候恢复，少和我提什么工单，明年还想不想签二期了？
我和你感受一样的，服务群建立的初衷就是为了沟通更高效，群里有销售和实施，现在无论大小 bug 都让走工单，形式主义严重了，说得好听是为了更好追踪 bug 和工单处理进度，实则就是工作形式主义，全部把责任推到研发。那么多用户，每天经常发生的高频 bug 顾问肯定都知道，当客户提出来的时候，顾问可以第一时间说这个是已知 bug，不用重复提，多节约时间呀。反过来，如果明道云产品 bug 多到顾问都记不得了，那得是有多少 bug 呀。另外你发现没有，每次遇到这些事情有几个现象，看起来很对，实则很难受：
1.明道云创始人会出来解释一堆，的确尊重客户，但是依旧没有解决问题
2.部分用户会说这个帖子终于有人发了，替自己发声了，说明大部分用户都懒得发声了
3.还有一些自以为很懂明道云和产品的装杯用户，开始站在产品和公司经营学角度给你解释这些 bug 是很正常的现象，要感谢明道云
没错，3 最真实了，有人站出来发声你要是觉得不对你可以沉默，非要反驳型人格附体装杯
我的目的是提出问题解决问题，公有版出了问题我们一点办法没有，工单提了解决时间未知，顾问只会让你提工单，那我怎么向我的用户交代，也学明道让我的用户提一个工单吗？我就请问我怎么和客户交代？
个人感觉还是因为升级后导致的 BUG 增多，给用户带来了麻烦甚至“事故”。以前，用户因为喜欢明道云，而且那段时间 BUG 少，用户还能接受。后来因为 BUG 不断增多，搞得用户不胜其烦的时候，对明道云的那种喜爱会慢慢转变为不满意，不满意积累的多了，积累的久了，会变成不耐烦。最终不耐烦被积压成了火药桶，不知在哪个瞬间被点燃爆炸。用户心理从愿意体谅到我凭啥成了你们的免费测试，我把问题告诉你们都已经很不错了，你们还要我写一堆报告来描述问题，这个事情我没有义务，你们的问题你们看着办，不修复，损失的是你们自己，大不了我换平台了。。。
以上的心历路程必须是用户才能真切的感受到。这个时候用户还愿意把它吐槽出来，其实对明道还是抱有一丝期待和不舍的。HAP 作为一个承载伙伴生产力工具，以及最终用户数字化底座的平台，其性能和功能的稳定何其重要，不容得任何的借口。因为人家把“身家性命”交给了你，这是何等的份量！建议明道加强内部代码质量管理，从源头抓起，激发员工责任心，强化测试环节，守住出厂前最后一道防线。咱们不是还有 800 多伙伴嘛，发挥伙伴的力量，版本可以推慢点，但让伙伴们帮着充分测试起来，给与伙伴测试贡献奖励，把生态的力量发挥到极致。
相信睿智的任总一定能妥善解决好这件事情，明道云再上新台阶！
我和你感受一样的，服务群建立的初衷就是为了沟通更高效，群里有销售和实施，现在无论大小 bug 都让走工单，形式主义严重了，说得好听是为了更好追踪 bug 和工单处理进度，实则就是工作形式主义，全部把责任推到研发。那么多用户，每天经常发生的高频 bug 顾问肯定都知道，当客户提出来的时候，顾问可以第一时间说这个是已知 bug，不用重复提，多节约时间呀。反过来，如果明道云产品 bug 多到顾问都记不得了，那得是有多少 bug 呀。另外你发现没有，每次遇到这些事情有几个现象，看起来很对，实则很难受：
1.明道云创始人会出来解释一堆，的确尊重客户，但是依旧没有解决问题
2.部分用户会说这个帖子终于有人发了，替自己发声了，说明大部分用户都懒得发声了
3.还有一些自以为很懂明道云和产品的装杯用户，开始站在产品和公司经营学角度给你解释这些 bug 是很正常的现象，要感谢明道云
明道要服务的是众多的客户，由此建立的工作机制不会因为少数几个人的意见而改动。
老板收到了你的意见，也给了长文回复，你就知足吧。
你的意思是明道客户多，不差你一个，老板都回你了，别不识抬举吗？那我跪谢老板翻牌恩赐了
明道要服务的是众多的客户，由此建立的工作机制不会因为少数几个人的意见而改动。
老板收到了你的意见，也给了长文回复，你就知足吧。
👀️ 还是有人跟我想法一样的，已经忍不了才嗷一下泄气
没错，早就对这个工单有意见了，从去年还是前年开始动不动就让提工单，在群里是看不懂消息吗？客户着急解决问题，明道要流程正确，没有大公司命得了大公司病，客户的时间不是时间？
现在的流程，本质上是在用“客户的成本”来覆盖“你们的风险”。以前顾问在群里能顺手看一眼解决的小问题，现在全部推给客户写工单。表面上是“规范了”，实际上是把沟通成本和时间成本全部转嫁给了客户，而你们自己的效率没有任何提升。
我觉得你可以直接投诉这个服务顾问，没必要自己忍着受气。
明道云内部肯定是用工单来记录哪个岗位，哪个人干了多少事的，所以为了留痕以及后期绩效考评，问题统计，没有工单是不行。不过话说回来，你不提工单，那个顾问就要自己写工单，所以。。。
服务这个事情，一方面和公司管理，服务流程有很大的关系，另外一方面我觉得和顾问的自身责任心也有很大的关系。别的不说，就说一说和我对接的顾问，那是真的很认真很负责，细心、耐心、不厌其烦、问题肯定闭环，效率也是杠杠滴。我是当着任总的面，发自内心的表示赞许的，也不知道有没有给这位顾问年底多争取到奖金 😄
和顾问没关系，我能理解顾问让提工单，一定是“公司”有要求，所以问题不是投诉顾问，是投诉这个有问题的流程
我来解释下：
首先，无论客户是不是自己写工单，软件问题的解决都是要依赖工单流转的，这可不是为了流程而流程，而是为了保证有跟踪，有记录，并且尽可能一次性获取问题的上下文。
至于顾问是不是都应该帮助客户提交工单，这个不能一概而论。有很多场景，涉及复杂的上下文，环境差异，客户直接提交第一手的工单更好。顾问即使帮助做，也需要和客户多轮沟通。至于提交了工单，问题依然不能立刻解决，这个和工单的提交方式并无直接联系，取决于问题的性质，如果是需要整体改进性或者追加的新需求，则必然需要评估和决定采纳的过程。我们的确做不到，客户提出的任何问题都能够立刻得到解决。我讲的这些都和我们企业软件行业的规律有关，并不是明道云特有的。就像进了饭店，你可以立刻点菜，进了医院，你必须先挂号（虽然这个比方有点不妥当）。
当然，今天我们已经有更好的基础设施，无论客户还是顾问，都可以很便利地通过 AI 提交整好好的工单。我觉得我们的顾问最好能够给客户提供一个提交工单的链接，这样客户一点就能写。
另外，我建议您尝试一下工单，你一定会发现，习惯了提交工单以后，问题解决的速度和质量一定比你在群聊里呼叫顾问要更好。
回复写得很长，辛苦。但通篇看下来，核心就一个意思：流程没错，错的是我不习惯。
那我作为用了 7 年的老用户，也给你翻译翻译你这段话的真实含义：
跟踪记录是为了解决问题，不是为了记录问题怎么被拖死的。现在的情况是，工单提了，记录有了，然后呢？挂着、看着、等着。跟踪记录做成了“死亡档案”，有什么意义？ 群里的聊天记录也是记录，以前能顺手修的小 Bug，现在非要走个“仪式感”才配被修，这不是流程，这是折腾。
翻译一下就是：“顾问不想传话，怕担责任，所以客户你自己写，写错了也是你的事。” 我一个截图就能说清楚的事，非要我写三百字背景描述、复现步骤、预期结果。我是来解决问题的，不是来帮你们写需求文档的。顾问的专业价值，难道就是告诉用户自己提工单？都是老用户了，不要扯教你怎么搭建。
这个比喻你提出来，我都替你捏把汗。挂号没问题，但挂完号医生看一眼说“这个病我们科室要评估一下，排期不定，你先回去等着”——这叫医闹预备役。更贴切的比方是：我进饭店点菜，服务员说“您先写个书面申请，后厨排期到了会做，具体啥时候不知道”——这饭店你觉得能开下去？
这句话是最虚的。工单速度取决于你们排期，和我习不习惯有一毛钱关系？ 我每天提一百个工单，你们就能修得快了？速度是你们给的，不是我“习惯”出来的。 你要真有底气，直接在群里把 Bug 类工单的 SLA 贴出来——几小时内响应、几天内修复、超时怎么处理。你敢贴，我就敢提。
用了 7 年，我是看着你们产品长大的，也一直愿意在群里“顺嘴提一句”，是因为把你们当合作伙伴，而不是工单处理机。但如果以后“开口就是工单，工单就是排队，排队就是无期”，那行，以后退群删顾问：有问题只提工单。
流程没问题，但把流程当成推诿的遮羞布，就是问题。
我来解释下：
首先，无论客户是不是自己写工单，软件问题的解决都是要依赖工单流转的，这可不是为了流程而流程，而是为了保证有跟踪，有记录，并且尽可能一次性获取问题的上下文。
至于顾问是不是都应该帮助客户提交工单，这个不能一概而论。有很多场景，涉及复杂的上下文，环境差异，客户直接提交第一手的工单更好。顾问即使帮助做，也需要和客户多轮沟通。至于提交了工单，问题依然不能立刻解决，这个和工单的提交方式并无直接联系，取决于问题的性质，如果是需要整体改进性或者追加的新需求，则必然需要评估和决定采纳的过程。我们的确做不到，客户提出的任何问题都能够立刻得到解决。我讲的这些都和我们企业软件行业的规律有关，并不是明道云特有的。就像进了饭店，你可以立刻点菜，进了医院，你必须先挂号（虽然这个比方有点不妥当）。
当然，今天我们已经有更好的基础设施，无论客户还是顾问，都可以很便利地通过 AI 提交整好好的工单。我觉得我们的顾问最好能够给客户提供一个提交工单的链接，这样客户一点就能写。
另外，我建议您尝试一下工单，你一定会发现，习惯了提交工单以后，问题解决的速度和质量一定比你在群聊里呼叫顾问要更好。
我觉得你可以直接投诉这个服务顾问，没必要自己忍着受气。
明道云内部肯定是用工单来记录哪个岗位，哪个人干了多少事的，所以为了留痕以及后期绩效考评，问题统计，没有工单是不行。不过话说回来，你不提工单，那个顾问就要自己写工单，所以。。。
服务这个事情，一方面和公司管理，服务流程有很大的关系，另外一方面我觉得和顾问的自身责任心也有很大的关系。别的不说，就说一说和我对接的顾问，那是真的很认真很负责，细心、耐心、不厌其烦、问题肯定闭环，效率也是杠杠滴。我是当着任总的面，发自内心的表示赞许的，也不知道有没有给这位顾问年底多争取到奖金 😄
在微信里，你要讲明白这几个意思：
1，明确要求客服帮你填工单。
2，这个问题不只影响自己，会影响其他客户。
3，若技术人员想了解更多信息，可以让我和技术人员直接沟通。
我相信，客服就会这么做了。
👀️ 还是有人跟我想法一样的，已经忍不了才嗷一下泄气