更快更专注的开放平台文档 v2.0
▎ 这是建立在 Logseq 上面的一套关于 开放平台 的教程合辑，用双链笔记可以互相关联的特点来解决简悦新用户教程查阅问题。
🔗 地址
https://kb.simpread.pro
📖 新版说明
仅保留开放平台相关内容，与 语雀手册（的内容）彻底分离。
💡 为什么是 Logseq
1️⃣ 简悦的教程大部分不是孤立存在的，所以会发生「嵌套问题」，而双链笔记是解决此问题最好的方案。
2️⃣ 所见即所得，用 Logseq 桌面版与发布的 Web 版保持一直的视觉效果，避免了二次调整。
3️⃣ 可自建在任意地方（此教程建立在 Github Page 上）
4️⃣ 利用 Logseq Publish GitHub Action 自动化发布
📚 如何开始
如果你不熟悉 Logseq 的用法，可以看 如何开始
🔎 关联
• 更快的 简悦文档中心
• 如何无代码自动化发布你的 Logseq 请看这里
🎁 还有惊喜
一年一度的简悦 2022 年双十一来啦 👉 https://t.me/simpread/487
马上就到截至日期喽，没上车的用户赶快上车，如果你多于三台设备的话，年底前会上更多设备功能，请填写此 调查问卷。
#简悦2_2_0 #简悦技巧 #简悦新手 #简悦教程 #玩转简悦系列
▎ 这是建立在 Logseq 上面的一套关于 开放平台 的教程合辑，用双链笔记可以互相关联的特点来解决简悦新用户教程查阅问题。
🔗 地址
https://kb.simpread.pro
📖 新版说明
仅保留开放平台相关内容，与 语雀手册（的内容）彻底分离。
💡 为什么是 Logseq
1️⃣ 简悦的教程大部分不是孤立存在的，所以会发生「嵌套问题」，而双链笔记是解决此问题最好的方案。
2️⃣ 所见即所得，用 Logseq 桌面版与发布的 Web 版保持一直的视觉效果，避免了二次调整。
3️⃣ 可自建在任意地方（此教程建立在 Github Page 上）
4️⃣ 利用 Logseq Publish GitHub Action 自动化发布
📚 如何开始
如果你不熟悉 Logseq 的用法，可以看 如何开始
🔎 关联
• 更快的 简悦文档中心
• 如何无代码自动化发布你的 Logseq 请看这里
🎁 还有惊喜
一年一度的简悦 2022 年双十一来啦 👉 https://t.me/simpread/487
马上就到截至日期喽，没上车的用户赶快上车，如果你多于三台设备的话，年底前会上更多设备功能，请填写此 调查问卷。
#简悦2_2_0 #简悦技巧 #简悦新手 #简悦教程 #玩转简悦系列
👍4
为什么不用客服以及当遇到问题后最好的 QA 方案
▎ 我非常喜欢跟用户交流，但通过群聊天的 QA 并不是一个好的解决方案。
💡 为什么不用客服
从产出性价比来说，目前找个客服确实可以解决很多问题，并且简悦的收入也完全支撑这个事情。
但我非常不喜欢「客服」这个概念，因为客服只是客服，从用户角度来说，当他发生问题时，最好的解决方案是找到我，而不是客服。
所以即便简悦拥有了目前的用户数量级，仍没有专职客服，而只有我以及 Telegram 群里面的热心大佬们。
❎ 为什么说群并不是一个很好的 QA 方案
Telegram 作为一个聊天群来说，除了中文搜索不怎么样外找不出一点「毛病」，非常完美。
但它并不适合作为一个 QA 渠道，原因很简单，因为及时性的缘故（IM 的特性）会导致：
• 线性对话，没办法实现 Thread 方式，人一多，基本上就被淹没在各个留言里面了，很难根据上下文解决。
• 即便有 Thread，打字的速度和信息的携带量要远低于说话，但因为及时性，所以会接近说话的频率，导致很多聊天内容反复导致信息冗余且无用居多。
✅ 最好的 QA 方案
请通过 Github Issues 讨论，这是我认为目前最好的 QA 方案，基本上每个问题都可以被反复追溯，甚至于时间跨度长达几个月也没一点问题。
Github Issues 支持完整意义的 Markdown 语法规则，可以贴图（从剪切板直接复制）、代码段、视频等手段。
具有提醒功能，在 Issues 上面的每次回复都会收到 Email。
▎ 截至到目前为止 Github Issues 上积累了近 5K 的讨论内容，我每天要处理 20+ 次的回复（忙的时候要 50+ 左右），仍游刃有余，并不会占用我太多时间，而通过 Issues 得到解决的也更彻底。
🆚 时效性的问题
Issues 并不具有时效性，所以很多用户都选择使用看似时效性更高的 Telegram 来讨论，因为感觉时效性可能得到的解决方案更快速，但原因刚才说了，所以总体时间并不如 Issues 来得更彻底。
📚 求人不如求己
除了 Github Issues 外，另外一个解决方案是看文档，简悦的每个功能都配有链接，会链接到这个文档中，甚至于还有配置库方案供用户免配置的设置。
• 简悦文档汇总一览
• 配置库一览
#简悦2_2_0 #简悦技巧 #简悦新手
▎ 我非常喜欢跟用户交流，但通过群聊天的 QA 并不是一个好的解决方案。
💡 为什么不用客服
从产出性价比来说，目前找个客服确实可以解决很多问题，并且简悦的收入也完全支撑这个事情。
但我非常不喜欢「客服」这个概念，因为客服只是客服，从用户角度来说，当他发生问题时，最好的解决方案是找到我，而不是客服。
所以即便简悦拥有了目前的用户数量级，仍没有专职客服，而只有我以及 Telegram 群里面的热心大佬们。
❎ 为什么说群并不是一个很好的 QA 方案
Telegram 作为一个聊天群来说，除了中文搜索不怎么样外找不出一点「毛病」，非常完美。
但它并不适合作为一个 QA 渠道，原因很简单，因为及时性的缘故（IM 的特性）会导致：
• 线性对话，没办法实现 Thread 方式，人一多，基本上就被淹没在各个留言里面了，很难根据上下文解决。
• 即便有 Thread，打字的速度和信息的携带量要远低于说话，但因为及时性，所以会接近说话的频率，导致很多聊天内容反复导致信息冗余且无用居多。
✅ 最好的 QA 方案
请通过 Github Issues 讨论，这是我认为目前最好的 QA 方案，基本上每个问题都可以被反复追溯，甚至于时间跨度长达几个月也没一点问题。
Github Issues 支持完整意义的 Markdown 语法规则，可以贴图（从剪切板直接复制）、代码段、视频等手段。
具有提醒功能，在 Issues 上面的每次回复都会收到 Email。
▎ 截至到目前为止 Github Issues 上积累了近 5K 的讨论内容，我每天要处理 20+ 次的回复（忙的时候要 50+ 左右），仍游刃有余，并不会占用我太多时间，而通过 Issues 得到解决的也更彻底。
🆚 时效性的问题
Issues 并不具有时效性，所以很多用户都选择使用看似时效性更高的 Telegram 来讨论，因为感觉时效性可能得到的解决方案更快速，但原因刚才说了，所以总体时间并不如 Issues 来得更彻底。
📚 求人不如求己
除了 Github Issues 外，另外一个解决方案是看文档，简悦的每个功能都配有链接，会链接到这个文档中，甚至于还有配置库方案供用户免配置的设置。
• 简悦文档汇总一览
• 配置库一览
#简悦2_2_0 #简悦技巧 #简悦新手
👍14🎉3