每个功能一步一步讲，配有来自真实运行系统的截图。图中的界面是英文的，那是产品的基础语言。
截图来自 0.46.0 版本。图中所示的界面到 1.1.6 版本为止没有变化。唯一看起来不同的是侧边栏底部的版本号。
在这里把系统调整到贴合您的公司。语言、徽标和配色属于这里。那些平时很少做、真做起来又很要紧的事也在这里：给所有人发一条通知、做一次更新、归档一批工单。除了把通知作为邮件发出去以外，这一整块都属于 Basic。
在“Settings → Language Settings”里，您选择公司提供哪些语言。一共有 30 种可选。
英语始终开启，无法关闭。当某段文字还没有翻译时，系统就退回到它。
之后每位用户在自己的菜单里，从您启用的语言中选择自己工作用的那一种。
翻译不会随更新一起送来。更新带来的是新的英文文字，它们的翻译由您自己补上。
这分两步。用“Export JSON”下载一个文件，里面每一条英文文字旁边都放着您已有的翻译。
您可以按自己的节奏把这个文件填好，再用“Import JSON”导入回去。空着的字段会被跳过，已有的翻译会被覆盖。
像 {count} 这样的占位符必须在翻译里保留下来。丢掉占位符的条目会被拒绝，继续显示英文。系统会告诉您是哪一条。
“State of your language packs”这张卡片会按语言告诉您进展到哪一步。它区分三种情况：已翻译、未翻译和已过时。
“已过时”是要紧的那一种。英文原文改了，您的翻译还在，而它现在说的是另一回事。
在“Settings → CI Settings”里，您设置自己的徽标、网站图标和三种颜色。
徽标出现在侧边栏里，系统徽标的下方。建议使用 400 × 160 像素的 PNG 或 SVG，背景透明，最大 2 MB。
网站图标是浏览器标签页上的小图。建议使用 SVG 或 64 × 64 像素。
这三种颜色是“Primary color”、“Accent color”和“Background color”。第一种用在重要按钮上，第二种用在图标和高亮上，第三种用在背景上。
文字颜色和悬停颜色由系统自己算出来，好让文字始终清楚。您只需要提供这三种基础颜色。
字段留空表示使用内置颜色。旁边的方块这时显示黑色，因为它没法显示“没有颜色”。下面的提示会说明这一点。
字段下方的预览让您在保存之前就看到自己的配色。只有点了“Save”，它才对所有人生效。
“Restore defaults”把一切恢复原样。上传的徽标和网站图标也会一起被移除。
系统有深色和浅色两种外观。您在侧边栏底部自己的菜单里切换。
这个选择属于每位用户，并且会被记住。一位客服人员可以用浅色工作，同事用深色。
同一个菜单里还有您的在岗状态、头像、密码和语言。
屏幕窄的时候，界面会自己重新排布。表格变成上下堆叠的卡片，侧边栏收进左上角的图标里。
没有单独的 App。地址和电脑上的一样，登录方式也一样。
开始之前： 管理员和客服人员可以更改通用设置。其他所有人都按那里设定的写法读日期。
在“Settings → General Settings”里有一张“Date and time format”卡片。它就在时区的后面。
日期的写法由四项选择决定。“Date order”是日、月、年的顺序。
“Date separator”是数字之间的那个字符。可以选点号、斜杠或连字符。
“Clock”是时制：24 小时制，或者带 AM 和 PM 的 12 小时制。“Time separator”是小时和分钟之间的那个字符。
四个字段下面写着“This is how it looks”。它在您点“Save”之前就显示结果。
这项设置对整套安装生效。它不取决于语言，也不取决于单个用户。
这是有意为之。一家公司用一种写法写日期，每位同事读到的都是同一种。
出厂设置是日、月、年，用点号分隔，24 小时制。您什么都不改，就什么都不变。
选定的写法在系统显示日期的每一个地方都生效。这包括工单、各种列表、跟进和记录的工时。
导出不受影响。导出文件里的日期写成 2026-08-22，因为表格程序读这种形式最可靠。
让您输入日期的字段不在此列。它打开的是浏览器自己的日历，写法也用浏览器的。
更多内容见这张卡片： 启用语言并自行翻译
开始之前： 登录页上的通知属于 Basic。把它同时作为邮件发出去属于 Professional。
侧边栏里有“Maintenance / Incident-Notification”这个页面。您在那里写一条所有人都能看到的通知。
通知会出现在登录页上，也出现在系统各处。这样人们在登录之前就读到了。
这样做是为了避免不必要的工单。读到网络中断的人，不会再报一次。
文字是点出来的。先点您要填的那个字段，它会带上红色边框，之后您勾选的内容都会进到那里。
“Title / Subject”显示在通知的上方，“Body”显示在它下面。如果您把通知作为邮件发出，一个成为主题，另一个成为正文。
现成的句子已经作为积木备好。您可以在“Text Modules”里添加自己的句子，在“Systems / Services”里添加自己的系统和服务。
用“Calendar (add date)”和“Time (add time)”插入日期和时间。计划内的维护就是这样公告的。
上方的开关打开和关闭通知。它会一直挂着，直到您把它关掉。
旁边还有第二种通知。如果您把一张工单变成故障公告，它同样会出现在登录页上，并在工单解决之后自己消失。这个开关对它不起作用。
用“Send as E-Mail”还可以把同一段文字发给一个地址清单。这一部分属于 Professional。
更多内容见这张卡片： 故障作为横幅，以及自动回复里的提示
系统会盯着服务器上的磁盘空间，在它用完之前先开口。
一共两级。用掉 90% 时给出提示，到 95% 时给出警告。
负责更新的人会看到具体数字和该做什么。通常，早先更新留下的旧镜像占的地方最大。
其他已登录的人只看到一句话和一个去找管理员的提示。他们要到警告这一级才会看到。
这些都不会出现在登录页上。服务器磁盘有多满，在登录之前与谁都无关。
磁盘写满影响的不只是更新。附件、收进来的邮件、数据库和备份都在同一块磁盘上。
在“Settings → Updates”里，您能看到当前运行的是哪个版本，以及有没有更新的版本。
如果有新版本，它带来什么会列在下面。跳过的每一个版本都会列出来。
更新之前，系统会自己做一次备份。备份包含数据库、附件和归档。
然后它会检查剩余空间够不够。更新期间新旧镜像会同时存在，所以它要求 10 GB。
空间不够时，系统会拒绝更新并说明原因。这比做到一半放弃要好。
系统会先问一句再开始。更新期间它有几分钟无法访问，所以请挑一个清闲的时间。
万一出了问题，系统会退回到上一个版本并继续运行。
如果您的服务器连不上更新源，系统会明说这一点。它不会因此就宣称您已经是最新的。
需要把数据库升到新版本的更新，不会通过一键完成。系统会告诉您，具体怎么做写在发行说明里。
开始之前： “Delete from live DB”会把这些工单从正在运行的数据库里彻底删除。请先下载归档文件并看一看里面。
在“Settings → Archive”里，您把某个时间段内已关闭的工单打包成一个文件。这样可以让日常的数据量保持较小。
只有已关闭的工单会被移走。同一时间段里还开着的工单留在原处。
“Preview”会先告诉您这段时间里有多少张工单。它不写入任何东西，也不改变任何东西。
“Create archive”生成一个 ZIP 文件。里面装着工单及其评论、历史、自定义字段和附件。
文件随后出现在下方的列表里，带时间段、数量和大小。如果您想按年份归档，也可以指定子文件夹。
到这一步您才决定这些工单是否离开正在运行的数据库。只生成归档文件本身不改变任何东西。
“Restore”把工单从文件里恢复回来。编号已经存在的工单会被跳过。
恢复需要工单引用的团队和工作流。如果它们缺失，系统会说明哪些对不上。
“Delete archive file”只删除文件。正在运行的数据库里的工单不受影响。
在“Settings → General Settings”里可以找到系统的各个下拉列表。每个列表都有自己的标签页。
部门、职位和地点还有一条走文件的路。一次要加很多条目时，这样更划算。
“Export JSON”把列表下载下来。在全新安装上，您得到的是一个空结构，可以往里写自己的条目。
文件里有一个示例，展示一条条目长什么样。重新导入时它会被跳过。
“Import JSON”会创建缺少的条目。已有的条目保持不动。
改名不能走文件这条路。本页上的字段就是干这个的，红色提示也这么写着。
条目的翻译之后在语言页上做。文件里放的是英文名称。
分类也是同样的做法。它们属于某个团队，所以放在那个团队的分类页上。
更多内容见这张卡片： 主分类和子分类每个团队都可以自由设置
团队是一份责任，不是一个文件夹。它有自己的分类、自己的期限和自己的成员。客户只看到其中一个。剩下的事情，归结为谁有哪个账号，以及那个账号可以做什么。
团队在“Settings → Teams”下面。左边是列表，右边是您点中的那个团队的设置。名字后面的数字是它的成员数。
新团队在“Team name”字段里取名。下面的“Copy categories from”可以选一个已有的团队，这样新团队一开始就带着同样的主分类和子分类。“Create team”把它建出来。
第一个团队就是客户看到的团队。之后的每个团队都是站在它后面的专业团队。让报障的人自己挑对部门是强人所难：他们提交给第一个团队，再从那里转交出去。
这一点随时可以改。“Customer permissions”卡片按团队决定客户是否可以在那里创建工单、是否能看到自己的工单。两项权限都没有的话，这个团队对客户来说根本不存在。
“Agent permissions”卡片针对这个团队的客服人员。它决定他们是否可以管理工单、管理分类，以及查看这个团队的报表。
“Agents”卡片装着成员。虽然标题是这么写的，这个团队的客户也在里面。上方的选择框加上“Add Agent”把人加进来，“Remove”把人拿出去。被加进来或被移出去的人，需要退出登录再登录一次。
“Default e-mail language”是这个团队写信用的语言。当邮件规则选择“Team default language”时，它就生效。
“Active”开关让一个团队停止服务。它会从侧边栏和所有选择框里消失，但并不会因此被删除。
只有当没有工单还开着时，“Delete”才会删掉一个团队。否则系统会说明原因，什么也不做。
“Audit log”卡片记录这个团队的每一次更改，带姓名和时间。
Basic 只能有一个团队。Professional 没有上限。
账号在“User management”下面。列表显示姓名和登录名、电子邮件地址、团队及其下方的部门，还有角色。
“New user”打开表单。名、姓、登录名和电子邮件地址是必填的。此外还要么填一个密码，要么勾上“Send login details by e-mail”。
勾上之后您就不设密码。新用户会收到一封邮件，里面有他的登录名和一个有时限的链接，由他自己设置密码。系统从不发送密码。
其余的都由角色决定。“Admin”和“Agent”都算员工，占用同一个额度。管理员默认能做的事更多，但每一项权限都可以改。
Basic 自带两个员工坐席。怎么分由您决定：一位管理员加一位客服人员，或者两位管理员。客户不占坐席，两个版本里都不限量。
有人离职时，点他那一行里的归档图标。账号会被锁定，他就无法再登录。
被锁定的账号会转到“Archived”视图，并在那里带上“locked”标记。它在“Active”视图里不再显示。
被锁定的账号不再占用员工坐席，也不会出现在任何“Assign to”选择框里。已经分派出去的工单保留原来的客服人员和他的名字。
在“Archived”视图里，同一个按钮叫“Restore”，它会重新启用这个账号。在 Basic 里，这需要重新有一个空闲坐席。
中间那两个图标用来重置密码和双因素登录。新密码随后会在屏幕上显示一次。它不会被发到任何地方。
客户在 Basic 和 Professional 里都不限量。他们不占用员工坐席。
客户账号有三种产生方式。您在“User management”里创建它。您通过邮件邀请对方。或者您允许自助注册。
相应的开关在“Settings → Security”的“Self-registration”卡片里。它出厂时是关的。打开之后，登录页上会出现一个“Register”链接。
自助注册的人拿到的一定是“Customer”角色。这条路上发不出别的角色。
没有邮件发送功能就无法验证地址。这类账号在列表里带着“not confirmed”提示，好让客服人员看出这个地址是否确实属于它背后的那个人。
内部帮助台最好别动这个开关。否则任何知道地址的人都能建一个账号。
客户只看到自己的案件。他的侧边栏很短：自己的工单、新建工单、知识库。他从来看不到任何设置。
他在某个团队里可以做什么，由那个团队来定。如果没有在那里创建工单的权限，这个团队对他来说就不存在。
一共有三种角色：“Admin”、“Agent”和“Customer”。不能再创建别的角色。可以自由设定的是每一项单独的权限。
这三种角色可以改名和翻译，在“Settings → General Settings”的“Role”标签页里。
一种角色可以做什么写在别处：“Settings → Security”里的“Permission concept”卡片。
每一行是一项功能，每一列是一种角色。打上勾就是允许。名称下面写着内部键名，用这个页面时并不需要它。
这份清单很长。它从用户管理，到各个设置页面的访问权限，一直排到工时记录。
“Agent Team”列是特殊情况。只有同一行里的“Agent”勾上之后，它才可用。在那里选一个团队，这项权限就只对那个团队的客服人员生效。
“Admin”角色的权限一项都拿不走。保存之后勾会自己回来。这样谁也不会把自己锁在自己的系统外面。
点“Save”之后更改立即生效。受影响的人在下一次点击时就会察觉。
有三份清单描述的是人，而不是工单：部门、职位和地点。
它们在“Settings → General Settings”的“Drop-down lists”卡片里创建。三份清单的用法一样。
它们在账号上指定。“User management”的表单里，这些字段叫“Department”、“Position”和“Location”。
在用户列表里，部门写在团队下面。职位和地点在账号的表单里可以看到。
地点还有第二个用途。工单上有一个“Location”字段，它取的是同一份清单。
这三份清单各有一条无法删除的条目。它叫“None selected or available”，带着“Mandatory”标记。
如果您删掉另一条条目，所有原本带着它的人都会转到这个占位条目上。这样就不会有人指向一个已经不存在的东西。
翻译不在这里做，而是在翻译页上一次做完。英文名称是翻译挂靠的锚点。
工单系统从邮箱收取邮件，也自己发送邮件。怎么设置写在工单管理板块里的“邮件转工单、回复与后续往来”卡片上。这一块讲的是一封来信会变成什么、您怎么屏蔽发件人，以及系统会自己发出哪些邮件。整个邮件通道属于 Professional 版本。
有人写信到团队邮箱时，系统会由它创建一张工单。主题成为标题，正文成为描述，发件地址被记作请求者。工单上的入口渠道写着“E-mail”。
如果邮件带发件人姓名，这个名字会进到地址旁边的字段里。如果没有，字段里写的是“E-Mail”。入口渠道已经说明了这件事是通过邮件进来的。
标题里的“Re:”“Fwd:”这类前缀会被去掉。这样工单带的是事情本身的名字，而不是某封回信的名字。
邮件的排版会保留。加粗的文字、列表和表格在工单里和在邮件里长得一模一样。
链接会保留。您的客服人员可以在工单里直接点开，不用把地址抄一遍。
嵌在邮件正文里的图片会留在原来的位置。它同时还会作为附件存到工单上。
只是从网上加载的图片会被去掉。这类图片常常会把邮件何时何地被读过回报给发件人。想让图片一定送到的人，应该把它嵌进邮件里，或者作为附件发送。
邮件的附件会变成工单的附件。它们和客服人员上传的文件受同一个大小限制。
如果工作流里打开了自动回复，发件人会立刻收到一封确认信。凭主题里的编号，之后的每一次回信都能找回同一个案件，并作为评论加进去。
更多内容见这张卡片： 邮件转工单、回复与后续往来
开始之前： 屏蔽名单在“E-Mail Settings”页面的最下面。它对所有团队同时生效。
有些发件人不该产生工单。新闻邮件是一例，只发机器报告的邮箱是另一例。
只针对一个发件人时，填写完整地址。图中就是 no-reply@example.com。
要针对某个发件人的所有地址时，填写以 @ 开头的域名。图中就是 @newsletter.example.net。子域名会一并被屏蔽。
被屏蔽的发件人来信不会产生工单。它会被标记为已读，并移到已处理文件夹里。收件箱里不会积压东西。
屏蔽在另一个方向上同样有效。系统不会向被屏蔽的地址发送邮件。
对那些没人看的地址来说，这才是真正的用处。没有屏蔽的话，确认信就会发到一个永远不会回应的邮箱里。
“Add”把一条条目加进清单。旁边的垃圾桶图标把它再删掉。更改立即生效，没有需要保存的东西。
开始之前： 这张卡片上的开关按团队分布，位于“E-Mail Settings”页面的“Team mailboxes”下面，就在该团队邮箱地址的正下方。
除了发给客户的回复之外，系统还会自己发出一些消息。其中包括工单的分派、超时的期限、邀请、新密码、满意度调查和申请的审批。
这些文字是现成的，一开始是英文的。它们和界面上其他所有文字一起放在语言包里。
导入语言包之后，这些消息每一封都会按收件人设置的语言发出。因此，同一件事上的两个人会收到两种语言的消息。
措辞在语言页上更改。您在那里把某种语言的文字下载成一个文件，改好之后再上传回去。英语是源语言，保持不变。
分派要不要通知，按团队决定。邮箱下面有三个开关管这件事。
“Send assignment e-mails”会给接到工单的客服人员发一封邮件。开关关掉，这个团队就完全不通知分派。
“Notify on self-assignment”决定有人自己接下工单时是否也发邮件。这个开关默认是关的。
“Send mail on ticket actions”作用在别处。打开之后，关闭工单、更改状态和转交的对话框里会多一项，让您把评论同时作为邮件发出。
发给客户的确认信不属于这里。它的文字由您自己写，写在邮箱的工作流里。
更多内容见这张卡片： 邮件转工单、回复与后续往来
谁能进来、怎么进来，由两个地方决定。安全页面管的是用用户名和密码登录。SSO 页面接入的是目录服务或外部登录服务。两者可以同时启用。
开始之前： 这张卡片上的设置在“Settings → Security”里。只有管理员能看到那个页面。
出厂设置下，每个人都用用户名和密码登录。电子邮件地址也可以代替用户名。表单下面有一个链接，给忘记密码的人用。
登录之后，浏览器会拿到一张有时限的通行证。有效期由“JWT token timer”卡片决定。允许填 1 到 24 小时，建议 12。过期之后，本人必须重新登录。
“Password policy”卡片适用于系统里设置的每一个密码。创建账号时、本人自己改密码时，以及管理员重置密码时，它都会被执行。
您可以设定最小长度、必须出现哪几类字符、密码多少天后过期，以及有多少个旧密码继续被禁用。天数和禁用列表填 0 表示“关闭”。
关于大小写的规则不会把任何语言挡在门外。很多书写系统根本没有大小写之分，来自其中的一个字符本身就同时满足这两条规则。
通过 SSO 或目录服务登录的账号没有本地密码，所以过期规则对它们不适用。它们的规则在提供方那边。
“2FA Settings”卡片打开双因素登录。它有两个开关。上面那个要求管理员和客服人员使用，下面那个要求所有人使用，包括客户。两个都关，双因素登录就是停用的。
下一次登录时还没有第二因素的人，会当场设置一个。系统会显示一个给身份验证器 App 用的二维码，以及同一个可以手工输入的密钥。输入第一个验证码之后，第二因素就生效了。
紧接着会出现十个恢复码。每一个都可以代替 App 里的验证码使用一次。它们只显示这一次。
如果有人把设备和恢复码都弄丢了，由管理员来帮忙。在用户列表里，那个划掉的盾牌按钮会重置此人的双因素登录。他在下次登录时重新设置。
验证码依赖服务器时钟。时钟不准，任何验证码都不会被接受。同一张卡片上的“Check now”按钮会把服务器时间和一个公共时间源做比对。
如果有人通过外部登录服务登录，系统不会索要验证码。第二因素已经由提供方检查过了。目录服务登录不一样：那里上面那条规则依然适用。
这项保护不需要任何设置就在运行，没有什么要打开的。相关说明写在“2FA Settings”卡片里。
它分两级。同一个账号连续五次登录失败之后，发起请求的那个地址会被暂停 15 分钟。从任何其他地址访问，这个账号立刻还能用。
这一点很重要。否则，任何知道登录名的人都能用五个错误密码把同事锁在外面。他连密码都不需要。
第二级针对账号本身。20 次失败之后，账号会被锁定 15 分钟。由于单个地址最多只能贡献其中五次，这需要用上好几个地址。
一次成功登录会把两个计数器都清零。服务器重启之后，地址暂停会消失，账号锁定则保留。
在用户列表里，这样被锁定的账号带着“temporarily locked”标记。它仍然留在列表里。15 分钟之后，标记会自己消失。
您不必等。同一行里有一个开着的挂锁按钮。它会立刻解除锁定，并把两个计数器都清零。
这和“Archive”不是一回事。那个按钮会把账号彻底停用，而且只有它会占用或释放员工坐席。
开始之前： 相关设置在“Settings → SSO Settings”里。没有配置好提供方时，登录页上什么都不会变。
最上面是总开关“Enable single sign-on”。它关着的时候，登录仍然走用户名和密码。您在它下面配置的一切都会保存下来，只有把它打开才会生效。
“Active Directory / LDAP”卡片接入本地部署的目录服务。您填入服务器、搜索基准、用来找到某个人的过滤条件，以及电子邮件地址和姓名对应的字段。
用于查询的账号是可选的。没有它，系统会以匿名方式查询。某个人的密码只用于向目录服务做绑定验证，从不保存。
目录服务本身不带第二因素。如果安全页面要求双因素登录，这些人同样会被索要第二因素。
“Identity providers”卡片装着外部登录服务。每一个都有自己的磁贴，登录页上也有自己的按钮。“Add provider”新建一个。
在“Provider type”里选择类型。“Generic OIDC Provider”适用于 Google Workspace、Microsoft Entra ID、Okta、Keycloak、Auth0 或 Ping Identity 这类服务。“SAML 2.0 Provider”适用于同样这些厂商，只是改走 SAML 接入。
旁边还有六个地区性服务：LINE、Kakao、Naver、WeChat、WeCom 和 DingTalk。它们的地址已经预填好，在字段里显示为灰色文字。
“Display name”里填的名字之后会出现在按钮上。旁边的开关只对这一个提供方生效。
回调地址要按这个顺序来做。先只填一个名字，点“Save provider”。系统这时才知道这个提供方的编号，并在“Redirect URI”下面显示完整的地址。
您把这个地址复制下来，在提供方那里登记。它在那边必须一个字符不差地对上。作为交换，提供方会给您一个 ID 和一个密钥，您通过“Edit”把它们填到这里。
“Allowed e-mail domains”字段限定谁可以通过这个提供方进来。留空表示允许所有域名。
如果某个提供方还缺东西，它的磁贴上会带红色的“Incomplete”标记。它这时不会出现在登录页上。旁边的文字会说明这种类型需要哪些字段。
已经配置齐全的提供方，在总开关关着时仍然不会出现。磁贴上会用一行黄字说明这一点。
“Automatically create accounts on first sign-in”开关和总开关在同一张卡片里。它默认是打开的。
有人第一次通过某个提供方登录时，系统会先找有没有已经属于该提供方的账号。找不到，就新建一个。
新账号拿到“Customer”角色，不属于任何团队。客户不需要团队成员身份就能创建工单，因此可以马上开始用。
客户在两个版本里都不限量，所以这样建出来的账号不占用员工坐席。谁要成为客服人员，之后在用户管理里改角色。
如果已经存在一个电子邮件地址相同的账号，两者会被关联起来。只有提供方报告该地址已验证时才会这样做。如果没有验证，登录会被拒绝。
如果您把它关掉，就只有已经有账号的人能进来。其他人都会被挡回去。
页面底部的“Recent sign-in attempts”卡片显示最近 100 次尝试。本页上的每一条登录途径都会记录，包括目录服务登录。
每一行写明时间、提供方、结果和来源地址。失败的尝试旁边还写着原因。“E-mail”列在提供方报告了地址时显示地址，否则显示输入的那个名字。
用用户名和密码登录不会出现在这张表里。那不是 SSO。
日常的手艺活：创建工单、分门别类、再把它们找出来。除非某张卡片另有说明，这一块里的一切都属于 Basic。
开始之前： 单张工单无法删除，管理员也不行。工单只能通过归档离开数据库，而且必须先关闭。这是有意为之：一个谁都能不留痕迹地抹掉的案件，作为记录毫无价值。
用左侧栏里的“New Ticket”创建新工单。表单叫“Create new ticket”。作为客服人员，您也用它来替别人记录请求，“User”字段就是干这个的：它说明这个案件是为谁办的，而不是谁在录入。
带星号的都是必填项：“Title”、“User”、“Main category”和“Description”。还有一项容易漏掉：没有子分类表单也保存不了，尽管“Subcategory”上没有星号。主分类和子分类是一对，永远一起设置。
到底显示哪些字段、其中哪些必填，在“Settings → Ticket Settings”里设置，客服人员和客户分开设置。所以客户看到的表单比您的短，而不需要谁去维护两套表单。
之后几乎所有内容都能改：工单右侧是“Details”卡片，里面有请求者、电话、电子邮件、地点、分类和参考编号；您改动字段本身，再用下面的“Save”确认。状态、优先级、分派、入口渠道和关注者在上面一张“Actions”卡片里，它们立刻生效，不需要单独保存。
只有客服人员和管理员可以改这些。请求者可以阅读案件、发表评论并上传文件，但不能改动您的报表所依赖的那些分类信息。
有一个副作用值得知道一次：如果您编辑一张还不属于任何人的工单，之后它就属于您了。系统会把您填成客服人员，并把状态从“Open”改成“Assigned”，两者都会进入历史。如果您本来不想这样，事后把它分派给别人。
这些更改每一次都会进到工单的历史里，带姓名、时间、旧值和新值。这不需要您打开任何开关。
剩下的问题是怎么把工单再清出去。在“Settings → Archive”里，您选一个时间段，用“Preview”看看里面有多少张已关闭的工单，再用“Create archive”生成一个 ZIP 文件：工单、评论、历史、自定义字段和附件，全在一个文件里。到这时这些工单才会从实时数据库里消失，而且可以从同一个文件里恢复回来。
描述和评论不是光秃秃的文本框。每一个上面都有一排工具按钮，把鼠标停在按钮上就会说明它的作用：“Bold”、“Italic”、“Underline”、“Strikethrough”、“Text color”、“Highlight color”、“Bullet list”、“Numbered list”、“Quote”、“Link”和“Clear formatting”。
链接是这样做的：选中文字，点“Link”，在弹出的小输入框里填地址。留空就把链接去掉。允许网址和邮件地址（http、https、mailto），其他的在保存时会被丢弃，这样一条评论就没法夹带任何东西。
图片走剪贴板进来：截个图，用 Ctrl+V 直接粘进编辑器。一开始正文里只显示一个标记，比如“[inline-image:1]”。保存时系统会上传这张图片，并把它显示在那个位置，同时它也会进到“Attachments”标签页里，案件的所有文件都放在那儿。
您看到的就是别人看到的：排版、列表和链接在工单里会保留，发给请求者的邮件里也一样。外来的标记，比如从网页复制的或者来信里带的，会被裁剪到这套允许的范围内。您的文字一个都不会丢，丢掉的只是外面的包装。
用“Only for Admin/Agents”可以把一条评论标为内部评论。它随后带上“Internal”标记，请求者看不到它，搜索也翻不出来。
开始之前： 允许的类型有 PDF、DOC、DOCX、XLS、XLSX、TXT、PNG、JPG、JPEG 和 GIF，每个文件最大 50 MB。表单里写着这个上限（“Max. 50 MB per file”），更大的文件在开始上传之前就会被拒绝。
文件属于案件，不属于某一条评论。在工单上，“Attachments”标签页通往这份列表：“Upload file”添加一个文件，每一行写着文件名、大小和日期。工单相关的每个人都可以上传，包括请求者，所以没人需要把截图另外发邮件给您。
点一下文件名就打开预览，不用先下载。图片可以在里面放大、缩小和旋转，遇到斜着拍下来的显示屏就用得上。PDF 在同一个窗口里显示，带页面缩略图、缩放和打印。文本文件按文本显示。用“Open in new tab”可以在单独的窗口里打开文件。
附件属于案件，并跟着案件走：它会出现在历史里（“File uploaded: …”），转交给另一个团队时也在，工单归档时它会一起进到归档文件里。
工单上的“History”标签页回答每次追查背后的问题：谁在什么时候改了什么？每一行写着人、字段、划掉的旧值、后面的新值，以及精确到秒的时间。最新的一条在最上面。
记录是自动写下的：状态、优先级、分派、分类、地点、关注者、标题和描述的变动，以及创建（“Ticket opened”）、每一条评论和每一个上传的文件。标签上的数字会提前告诉您这个案件动过多少次。
历史无法编辑，也无法关闭。正是这一点让它有用：单张工单不能删除，原因就在这里，而且工单归档时历史会一起进到归档文件里。
评论在那里是缩略显示的，完整内容在“Comments”标签页里。内部评论同样会出现在历史里，但只对客服人员和管理员显示。
状态说明一张工单目前走到哪一步。系统自带十二种状态：Open、Assigned、In Progress、Waiting for User Response、Resolved、Closed 等等。它们在“Settings → General Settings”的“Drop-down lists”一节里，藏在“Status”标签页后面；“+ Add status”新建一个自己的状态，“Edit status”打开一个已有的。
要紧的是名称和含义的区别。在某个状态的编辑器里，“Meaning of this status”下面有三个开关：“Counts as resolved”、“Counts as closed”和“Waiting for the requester”。只有这三个开关才告诉系统该怎么对待这个状态。
每一种状态都可以改名，系统自带的也不例外：在编辑器最下面的“Translations”里，每种语言都有一个“Name”字段，把您的人该读到的写进去。它背后的技术名称保持不变，正因如此才不会出问题：自动化、报表和上面那三个开关挂的是技术名称，不是您写的标签。所以“Resolved”可以改叫“Done”。
删除就不是每一种都行了。列表里有六种状态带着“Mandatory”标记：Open、Assigned、In Progress、Resolved、Closed 和 Reopened。它们可以改名、可以调整顺序，但不能删掉；尝试删除会得到一条明确的提示。这不是为了给您添堵：有些流程挂在它们身上，删掉之后那些流程会一声不吭地停下，比如自动关闭，它需要一个“已解决”的状态作为起点。
有两种状态属于系统自己：“Waiting for approval”和“Rejected”带着“System only”标记。它们来自审批流程，而谁都不该能手工声称某件从未提交决定的事被驳回了。
这三个开关的作用是：算作已解决的状态，会让工单在 24 小时后自己关闭。算作已关闭的状态，是工单被移入的最终状态。而“Waiting for the requester”的意思就是字面上的：我们在等请求者，不是在等另一个团队，也不是在等某个服务商。如果您这样设置，服务级别协议的计时器就是在这个标记上停住的。
下面是“Allowed transitions to new status”。您在这里勾选从这个状态可以走到哪些状态。全都留空就不作限制；勾了任何一个，其余的路就都关上了。跳不过去的流程就是这样搭出来的，比如：从“Open”只能走到“In Progress”或“Rejected”，不能直接到“Closed”。
编辑器里剩下的开关都是小东西，作用却不小：列表里显示的颜色、决定排序的“Sort order”、“Show status in new ticket form”（创建工单时这个状态到底能不能选？）、“Requires comment in dialog”（强制填写理由），以及只有系统自己才能设置的“System only”。
工单里以下拉框出现的一切都归您管。在“Settings → General Settings”里有“Drop-down lists”卡片，带六个标签页：“Department”、“Position”、“Site”、“Role”、“Status”和“Priority”。每一个后面的用法都一样，所以只要学一次。
一条一条来：把英文名称填进空字段，点旁边的按钮，按钮的名字跟着列表走，比如“+ Add site”“+ Add department”等等。下面的各行是已有的条目：您在那里改名称，用旁边的“Save”确认。
一次要加很多条时，有“Export JSON”和“Import JSON”。在全新安装的系统上，您用“Export JSON”下载空结构，填好之后再导入回去。它不能用来改名，卡片上也是这么写的。
有些条目带着“Mandatory”标记。“Admin”、“Agent”和“Customer”这三种角色属于此列，系统自带的六种状态也是，还有地点、职位和部门三份清单里各一个占位条目（“None selected or available”）。它们可以改名，但不能删除：有权限和流程挂在它们身上，删掉之后那些会一声不吭地停下。
翻译成其他语言不在这里做，而是在翻译页上一次做完。这里填英文名称就够了，它是之后翻译挂靠的锚点。
状态是唯一一个有自己编辑器的条目，因为挂在它身上的不只是一个名称；它在下面有自己的卡片。
开始之前： 您至少需要一个团队。分类页面是以它的团队命名的，所以只有建了团队之后它才存在。
分类是请求者或客服人员在创建工单时选的东西，也是您之后给报表分组的依据。每个团队都有自己的一套：帮助台的分法和网络部门不一样，两边都看不到对方的清单。
它们在“Settings”下面，条目名叫“<团队名称> Categories”。例子里团队叫“Helpdesk”，所以条目写作“Helpdesk Categories”。
这个页面有三张卡片：“Main categories”、“Subcategories”和“Links”。最快的上手方式：把英文名称填进“EN (required)”字段，点“+ New main category”或“+ New subcategory”。其他语言之后在翻译页上一次译完，这里不用为此做任何准备。
如果您面前有一大堆分类，就走文件这条路：“Export JSON”把结构下载下来，在全新安装的系统上这个文件是空的，只给您看格式。您把它填好（手工填，或者让 AI 帮忙），存好再用“Import JSON”上传回去。它不能用来改名：改名要在那个分类自己的字段里改，用旁边的“Save”确认，页面上也是这么写的。
第三张卡片“Links”才是真正干活的地方。上面选一个主分类，下面勾上属于它的子分类，用“Save links”保存。窍门在于：一个子分类可以挂在多个主分类下面。所以“Malfunction”只需要建一次，打印机、网络、会议室和笔记本电脑都能重复用它。
从此这些分类就可以在工单里用了。只要还有工单在用某个分类，删除就可能失败，这是有意为之，否则旧工单会丢掉自己的分类信息。
如果您把一张工单转交给另一个团队，它的分类信息会保留下来，哪怕新团队根本没有这些分类。它这时会连同来源一起显示在字段里，比如“Meeting-Room · from Helpdesk”，并且是灰色的：新团队能看出这个案件此前算在什么名下，但不能自己指定这个条目。要重新归类，就从自己的清单里选，而系统这时要的是主分类和子分类一起。
每张工单都带一个入口渠道。它在表单里，之后在“Actions”卡片的“How the request came in”下面，它回答的是一个在报表里很快就会变重要的问题：工作是从门户来的，还是从电话来的？
可以选的只有人知道而系统不知道的那些：“Phone”和“Entered by an agent”。另外两个值由系统自己填，请求者在门户里创建工单时是“Self-service”，由一封来信生成时是“Email”。
这也是为什么系统填好的入口渠道之后不能改成“Phone”：那样这个字段就丢掉了它存在的意义。反过来，在一张电话记录下来的工单上，其他内容您照样可以改。
只有客服人员或管理员可以设置入口渠道。对请求者来说，这是在为自己的案件下结论，而报表就要指望每个人都诚实了。
“Email”需要接好一个邮箱，那属于 Professional 版本。另外三个渠道两个版本里都有。
每个工单列表上方都有“Search tickets…”字段。它搜的不只是标题，而是整个案件：标题、描述、请求者的姓名、电子邮件地址和电话号码、地点、关联工单号、所有评论，以及您自己那些自定义字段里的文字内容。
例子里就能看到：“coffee”没出现在任何标题里，只出现在其中一张工单的描述里，但照样被找到了。所以您不用记住一张工单当初叫什么名字，案件里的一个词就够了。
大小写不影响结果。搜索始终作用于您当前所在的列表，还可以和旁边的“Filter”组合使用；“Reset”把搜索和筛选一起清空。客户那边有一个看不见但值得知道的限制：他们搜不到内部评论，否则他们就能从结果列表推断出内部讨论了什么。
开始之前： 两条路都需要第二个团队。客户对此一无所见：对他来说，无论多少个团队参与过，始终是一个案件、一个编号。
工单上为此并排放了两个按钮，区别用小字写在下面。“Involve another team”：您继续负责，另一个团队在一张关联工单里和您并肩处理。“Escalate to another team”：由另一个团队接手。
转交时责任转移，而不会产生第二张工单。您的团队保留读取权限，也还可以评论，但不能再改动任何东西，对话框在您确认之前就会把这一点讲清楚。您在那里选目标团队，还可以补一个理由。
拉另一个团队进来时，您的工单还在您手上，并在对方团队里生成一张子工单。您这张转到“Waiting for other team”状态；对方把他们那张关掉之后，您这张会以“Back from other team”回来。这样您就不用去问那边有没有动静。
至于分类：转交方团队的分类会留在工单上，哪怕新团队根本没有这些分类，它们会带着来源显示在那里，颜色是灰的。这样新团队能看出这个案件此前算在什么名下，需要时再归到自己的清单里。
只有当前负责的人才可以把工单继续交出去。更早的那一站仍然看得到案件，但不能第二次转交它。
当您的工单里缺少某项信息，比如资产编号、保修到期日、成本中心，您可以自己加。在“Settings → Ticket Settings”页面的最下面有“Custom fields”卡片，按钮叫“Add custom field”。
在对话框里填一个名称和一种字段类型：“Text”、“Multiline text”、“Integer”、“Decimal”、“Date”或“Yes / No”。类型决定能填什么，日期字段不会接受“下周”，而正因如此，之后才能拿它做报表。
在“Scope”下面您决定这个字段在哪里生效：“All teams (including new ones)”或者“Selected teams only”。第一个选项也涵盖还不存在的团队，这种区别通常要半年后才察觉得到。
“Defaults”下面的三个开关对新工单生效：“Mandatory by default”、“Hidden for customer by default”和“Not editable by customer by default”。它们只是默认值，同一页上的字段设置仍然是按角色精确设定的地方。
在工单上，自定义字段单独放在一张“Additional information”卡片里，位于描述和评论之间。不用模板时，表单会显示这个团队的所有自定义字段。如果您在创建工单时选了模板，就只显示这个模板列出的那些字段，顺序也按它的来，也就是“这个案件需要哪些字段就显示哪些”。
模板还可以额外把某个字段设成必填，但它取消不了规则：管理员对客户隐藏的字段、声明为必填的字段，仍然照旧，哪怕模板另有说法。否则模板就成了绕开公司规矩的一条路。
一个团队最多可以有多少个自定义字段，在“Settings → General Settings”的“Custom fields limit”卡片里设置。要清掉一个字段，用“Deactivate”：它从表单里消失，但它在旧工单上的取值保留下来，“Show deactivated”开关能把它再显示回列表里。
有时候某个人应该跟着看一个案件，但不参与处理：一件敏感事情上的团队负责人，或者下周要接手的同事。关注者就是干这个的。在工单上，“Observers”字段位于“Actions”卡片，按钮叫“Add observer”；“Create new ticket”表单里也有同一个字段。
只能选参与团队里的客服人员和管理员。客户不能当关注者，否则他会收到关于内部工作的邮件。
工单上有动静时，关注者会收到一封邮件：新评论、状态变动、新的分派、字段改动。邮件不是立刻发出的，而是攒在一起：最后一次改动之后系统等一分钟，然后把这段时间里发生的所有事情合成一封邮件发出。所以一口气处理完一张工单，不会触发七封邮件。
谁在关注也是历史的一部分：这项改动和其他改动一样被记录下来，带旧状态和新状态。
通知是电子邮件，所以必须先配置好发信（Professional）。没有它，您仍然可以填关注者，但什么都不会发出去。
开始之前： 用 Google/Gmail 时需要一个应用专用密码（它要求先打开双因素登录），Google 不接受普通的账号凭据。Microsoft 365 目前完全不行：那里 IMAP 的基本身份验证已经关闭，应用专用密码也帮不上忙。
邮件通道是一条双向的路，两个方向是一体的：一封来信变成工单，您的回复作为邮件发出，请求者的答复作为评论落到同一张工单上，而不是新开一张。
匹配不是靠感觉：只有当邮件的主题里带着案件编号，或者带着邮件程序的回复标头时，回信才会落到已有的工单上。两者都没有的邮件会开启一个新案件。宁可多出一张工单，也好过仅仅因为主题碰巧一样，就把两件不相干的事合到一起。
相关设置都在“Settings → E-Mail Settings”里。上面那张“SMTP settings”卡片管的是出去的路：主机、端口、“Use SSL”、用户和密码，以及发件地址和发件人名称。用“Send test e-mail”给自己发一封样例，先保存再测试，卡片上也是这么写的。
“IMAP settings”卡片管的是进来的路：主机、端口、轮询间隔和两个文件夹。文件夹名字不用猜：“Read from server”会取回您邮箱里实际存在的文件夹，“Create on server”新建一个。字段随后会填入您的邮件服务器所用的路径，一台服务器写“INBOX/Processed”，另一台写“INBOX.Processed”，两者是一回事。
处理过的邮件会移到“Processed folder”里；留空就留在收件箱。下面设置清理什么时候运行（“Hour”、“Minute”），以及邮件最多保留多久（“Retention (days)”），否则邮箱会不声不响地一直变大。
邮箱属于团队，不属于系统：在“Team mailboxes”下面，每个团队填自己的地址和密码。这个地址同时也是该团队邮件的发件人，这样请求者回信的地方，正是收信的地方。
接下来是缺了它这一切都不会发生的那一环：工作流。光配好邮箱什么也不会做。如果一个团队没有启用的工作流，邮箱根本不会被轮询，没有工单，没有确认信，邮件就那么放着。发给客户的自动回复只存在于这里，而且要您自己配。这是有意为之：一个不问就给每个发件地址写信的系统，比一个不吭声的更糟。
在“E-Mail workflows”下面，先在上方选团队，用“+ Add workflow”新建一个工作流。它有一个名称（只给您自己看）、一个“Enabled”开关，以及两项关于何时生效的设定：“Match”决定是所有条件都必须成立（“All conditions”）还是有一条就够，“Stop after match”表示这个工作流一旦命中就结束本次运行，排在后面的工作流就再也轮不上。顺序用旁边的箭头调整。
“When?”下面是条件本身。“Every e-mail in this mailbox”接收每一封邮件；“Only when subject or text contains”要求主题或正文里出现某个词。“Advanced”让它更精确：您在那里选择看哪一部分，“Subject or body”、“Subject”、“Body”、“Sender (From)”还是“Recipient (To/Cc)”，以及怎么比对：“Contains”、“Equals”还是“Regex”。比方说，发到某个共用地址的报障就是这样和其他邮件分开的。
下面是五个动作开关。它们才是工作流的真正内容，没打开的就不会发生：
“Create or append ticket”把邮件变成工单，或者当主题里带着案件编号时，把它作为评论追加到已有的工单上。没有这个动作，邮件永远不会变成案件。
“Set fields”在工单创建时就设定优先级、状态、主分类和子分类、所属团队和负责人。所有停在“— Keep default —”上的项，都保持没有工作流时的样子。
“Auto-reply”是发给发件人的确认信，也是系统唯一自己作答的地方。这个开关关着，您的客户就永远收不到自动回复，其他部分配得再好也没用。
“Send mail”额外发一封邮件：可以发给来信的发件人，也可以发给选定的团队成员和固定地址。它有自己的“Send conditions”，留空的话，这个工作流每次运行都会发。
“Move to folder”把处理过的邮件归到某个文件夹里。字段留空，就用上面 IMAP 设置里那个通用的“Processed folder”。
细说“Auto-reply”这个动作：主题是用积木拼出来的。“Original subject {originalSubject}”接过来信的主题，“Ticket reference {ticketTag}”插入案件编号，两者合起来就得到类似“Printer problem [TICKET-99]”的主题。
案件编号不会自己加上去。它只出现在您放了 {ticketTag} 或 {ticketId} 的地方，而系统之后正是靠它认出您客户的回信。主题里没有它，每一次后续往来都会新开一张工单，而不是变成旧工单上的一条评论。
下面那段文字是您的确认信内容。请用英文写：它和其他所有文字一样走同一套导出和导入流程，也只有这样才能被翻译成其他语言。留空的话，系统会发它自带的默认信息。这里同样允许使用那些占位符。
“Reply language”决定主题和正文用哪种语言发出：“Standard English”用英语，“Fixed language”用您指定的一种语言，“Assigned agent's language”用负责客服人员的语言，“Team default language”用团队的默认语言。翻译本身在语言页上维护。
有一条建议，系统也把它印在卡片上方：属于同一个案件的一切，都该放在同一个工作流里。只有同一个工作流内部的动作才知道刚刚创建的那张工单，所以确认信才能写出它的编号，而另一个工作流里的动作做不到。
整个邮件通道，进和出，都属于 Professional 版本。在 Basic 里，系统既不发也不收电子邮件；那里的工单通过客户门户、电话和客服人员产生。
每位客服人员都会显示自己此刻是否有空，您分派工单时，这个状态就写在名字旁边。这一块里的一切都属于 Basic。会跳过不在岗客服人员的自动分派是另一项功能，属于 Professional。
每位客服人员都处于三种状态之一，由本人在侧边栏左下角的用户菜单里设置。这三项在“Availability”标题下面。
状态用一个圆点表示。“Available”是绿点，“Busy”是琥珀色的点，“Away”是一个空心圆环。
这三者不只是颜色不同，填充也不同，所以分辨颜色有困难的人照样看得出区别。
您自己的圆点就在左下角的头像上，不用打开菜单也能看到。
您分派工单时，状态写在名字后面。如果记录了离开的结束日期，它也写在那里。
不在岗的客服人员仍然可以被选中，只是被标注出来。工单要不要照样给他，由您决定。
系统只会给您列出工单所属团队里的客服人员。
只有客服人员和管理员有状态。客户没有。
更多内容见这张卡片： 一次把多张工单分派给同一位客服人员
生病的人很少会先请好假。所以管理员可以替别人设置状态，在“User management”里那个账号的编辑表单中。
表单里为此有两个字段。“Availability”放状态，“Away until”放离开的结束日期。
第二个字段只在选了“Away”时才出现。“Busy”和“Available”没有结束日期可填。
不填日期，离开就持续到有人把它结束为止。填了日期，它会自己结束。字段下面的提示这么写着：“Leave empty for an absence without a set end.”
过去的日期不会被接受。它会立刻失效，而您的同事仍然以有空的样子留在列表里。
这两个字段只对客服人员和管理员出现。如果您在同一个表单里把角色改成“Customer”，它们就消失了。
一个字段承载两件事。对系统来说，请一天病假和休三周假是同一回事，只是日期不同。
“Busy”持续一小时。之后客服人员不用做任何事就重新变成有空。
菜单里会在状态旁边显示剩余时间，比如“60 min left”。
这一小时是固定的。它是防遗忘的安全网，不是运营规则。谁要更长时间不在，就选“Away”。
复位是一个时间点，不是一项任务。账号里存的是状态结束的那一刻，状态是在有人读取时算出来的。如果那一小时里服务器是关着的，之后这位客服人员就是有空的。不会留下什么积压，等着某个后台服务去补。
“Away”只有记录了结束日期才会到期。没有的话，它会一直保持，直到有人改动它。
客服人员自己设成“Away”时，这个状态不带结束日期。只有管理员才会给出结束日期。
系统只记住此刻生效的是哪个状态。谁在什么时候忙碌或离开，它不做记录。
所以用户列表只显示当下的状态，别的没有。没有历史列，也没有出勤报表。
这是一个决定，不是缺件。按人统计的在岗数据属于行为数据，在很多公司职工委员会对此有话语权。
历史也不需要。状态回答的是一个问题：这位同事现在有空吗？“Busy”一小时后自己结束。
一位客服人员手上有多少张工单，您在工单列表里就能看到，那里的“Assigned to”可以按人筛选。某人离开了多久，任何地方都没有记下来。
新工单可以立刻有一个负责人。系统用的是上一块讲的在岗状态，分派按团队开启，出厂设置是关闭的。这一整块都属于 Professional。
没有分派的话，每张新工单都会落进待处理队列。得有人去认领，或者得有人来分发，只要有人盯着，两种都行。
打开分派之后，每张新工单在创建时就有了负责人。这是立刻发生的，不是几分钟之后。
这项设置在“Settings → Teams”下面的团队上，每个团队自己决定。一个团队可以做分派，旁边的团队从待处理队列里取活儿。
出厂设置下，每个团队都停在“Off”。已经在运行的环境不会因为多了这个功能就改变行为。
工单发给团队的成员。一位在队列里干活、并且是该团队成员的管理员，和客服人员一样会收到工单。
有两种方式，每个团队选一种。
“Round robin”按顺序轮着来。新工单交给有空的客服人员中，上一次自动分派离现在最久的那一位，所以刚加入团队的人排在最前面。
“Least load”看的是手上的活儿。新工单交给有空的客服人员中，未关闭工单最少的那一位。
等请求者回话的工单算半张。手上有很多待回复问题的人，和堆着一摞新故障的人，忙的程度不一样。
已解决或已关闭的工单完全不算。您自己创建的状态也一样，只要它被标记为已解决或已关闭。
两种方式的结果都是可以推算出来的。两位客服人员打平时，永远由同一条规则决定，而不是靠运气。
每次分派之前，分派机制都会问一下客服人员的状态。“Busy”和“Away”会被跳过。
被锁定和已删除的账号同样不在考虑之列，不属于工单所在团队的人也一样。
如果没有人有空，工单就没有负责人，创建过程照常完成。
这是有意为之。放在待处理队列里的工单大家都看得见，而落在一个已经离开的人手上的工单，谁也看不见。
工单历史里写着原因：那里写的是“(nobody available)”，而不是一个名字。
更多内容见这张卡片： 有空、忙碌、离开
工单不管从哪条路产生，分派都起作用，包括来自邮箱的工单。
对申请的子工单也一样：每一张都在接收它的团队内部做分派。
由人指定过负责人的工单，分派绝不会去碰。如果您在创建工单时自己选了负责人，您的选择就算数。
每一次自动分派都会记进工单历史，作者写作“Auto-assignment”，旁边是客服人员的名字。
客服人员收到的邮件和手工分派时一样。如果工单还停在“Open”，它会转到“Assigned”。
更多内容见这张卡片： 一封电子邮件变成一张工单
谁运行一项自动化，就得能检查它做了什么。报表页面上为此有一张单独的卡片。
上面是两个数字。左边是这项自动化分出去了多少张工单，右边是有多少次没有人有空。
右边那个数字旁边写着发生这种情况的工单编号，点一下就能到现场。
下面每位客服人员一行，带各自的数量和在岗状态。这些行来自团队的成员名单。
所以某一行是零并不是错误。这张表就是为此存在的。
一位连着几周都是“Away”的同事没有分到工单，但仍然列在表里，零的旁边写着原因。
这张卡片是机器的日志，不是对人的评价。这里没有在岗历史，也没有关于谁在岗多久的报表。
更多内容见这张卡片： 没有在岗历史，也没有按人统计
有些请求不是一张工单。申请在提交时就创建自己的任务，每一项都是处理它的团队里的一张单独工单，审批可以有，但不是必须的。这一整块都属于 Professional。
“有位新同事要入职”不是一张工单。它是一台笔记本电脑、两个账号、一个电话分机，也许还有从外部接入的权限。每一件都归不同的团队，而您还是想要一个案件，一眼看出进展到哪里。
申请就是干这个的。它是一张工单，在提交的那一刻创建自己的任务，每项任务在处理它的团队里变成一张自己的工单。
申请不是第二样要维护的东西。它挂在一个工单模板上：在“Settings → Request workflows”里能看到所有工单模板，您把任务挂到其中一个上面。
每项任务要设四样东西。“Task”是请求者读到的名称，“Handled by”是接手它的团队，“Ticket title”和“What the team has to do”填的是由它生成的那张工单。
多项任务可以指向同一个团队。那个团队随后会收到多张工单，而不是一张里面带清单的工单。
没有团队的任务根本不会被提供。字段本身也这么写着：“Not assigned yet — this task is not offered”。这样您就可以先把还没做完的方案保存下来。
任务上方有一句话概括整个方案：出厂设置下会创建什么、请求者可以改多少、由谁来放行。改一项设置，这句话就自己重写一遍。
有人在新建工单表单里选中这个模板时，会出现“What is needed?”方框，每项任务一行可以勾选。
一共有三种，按任务分别设置。“Selectable, off by default”一开始是空的，“Selectable, on by default”一开始就打了勾并且可以取消，“Always — cannot be deselected”则始终执行。
始终执行的任务照样会显示出来，标注着“(always included)”。请求者应该看到反正会发生什么。
方框下面写着这会带来什么：“Each selected item becomes its own ticket for the team that handles it.”
客户也可以提交申请，前提是这个模板对客户开放。相应的开关在模板上。
客户随后只看到自己的申请。专业团队里的那些工单对他是隐藏的，尽管是他的申请生成了它们，因为那些工单里带着凭据和内部备注。
更多内容见这张卡片： 工单模板可以逐个对客户开放
在申请本身上，任务列在“Workflow tasks”下面，旁边带计数，比如“1 of 4 done”。
每一行显示任务名称、它那张工单的编号、团队和负责人，名称是通往那张工单的链接。
“已完成”来自工单的状态，不是另外打的勾。在工单列表里算已关闭的，在这里就算已完成。同一件事有两套算法，早晚会对不上。
这一块只出现在申请上。普通工单不显示它。
一次审批覆盖整个申请，而不是每一项任务。八个申请项是给主管的一封邮件，不是八封。
这在同一个方案的“Approvals”下面设置，上方那句话点明了规则：“One approval covers the whole request. Add a second stage only when single tasks need their own release.”每一级有三项设置：“Covers”说明它适用于什么，“Decided by”说明审批人从哪里来，“Approver”填的是具体的人。
审批人不需要工单系统里的账号：您填一个电子邮件地址，他通过链接做决定。一位一个季度批两次的主管，因此不占用客服人员坐席。
邮件里正好只有一个通往页面的链接。邮件本身刻意不放同意和拒绝按钮：否则一个会打开每个链接的病毒扫描器就替人同意了。
那个页面叫“Approval request”。它显示申请的编号和标题、请求者，并在“This decision covers”下面列出这次决定涉及的任务，下面是一个备注框和两个按钮。
链接不会一直有效，页面上写着期限：“Please decide by …”。
决定无法收回，做完之后页面也会说明：“A decision cannot be changed.”
有些任务需要单独放行。从外部接入的权限和一台笔记本电脑不是一回事。
为此您加上第二级，并在任务的“Extra approval”里选中它。只要它写着“None — the request approval is enough”，申请这一级的放行就够了。两级是同时发出询问的，不是一前一后。
一项任务要等到与它相关的每一级都同意之后才放行。其他任务在申请本身获批之后就开始。
在此之前任务是锁住的：它那张工单停在“Waiting for approval”，没有负责人，状态选择框里什么都选不出来。
这道锁在工单列表的批量操作上同样有效。在那里选中这样一张工单，您会读到原因：“This task is waiting for approval and cannot be worked on yet.”
工单仍然是立刻创建的，这样专业团队就能看到接下来有什么活儿，也没人需要盯着那份申请。
您可以按级设置提醒，以小时为单位。
如果没有回音，过了这个时间同一封邮件会再发一次，带的还是第一封里的那个链接。留着第一封邮件的人照样能用。
不设提醒的话，申请就那么等着，不再追问。
不存在的是到期自动放行。字段下面把这句话说得明明白白：“A request is never approved automatically. If nobody reacts, it keeps waiting.”一个自己就会同意的期限，不是审批，只是走个形式。
拒绝时必须填理由。没有文字，页面不接受这次拒绝。
字段写明这段文字去往哪里：“Comment (required when you reject — the requester will see it)”。内部备注不该写在这儿。
请求者会收到一封带理由的电子邮件，不用再去问为什么没有动静。
同意不需要理由。那是预期中的结果。
如果只有第二级拒绝，被拒的就只是那一级涉及的任务。申请的其余部分继续进行。
被拒绝的任务拿到“Rejected”状态并算作已完结，这样申请就不会永远挂在一件永远不会来的事情上。
在申请上，“Approvals”每一级显示一行，带审批人、状态，对还没决定的申请还显示已经等了多久。
做完决定之后，这一行会显示决定的时间和所附的备注。这就是审计轨迹，它跟着案件留下来。
如果审批人在休假，管理员可以把申请转到另一个地址。按钮叫“Reassign”，只在申请还没决定时出现。
只有管理员可以这么做。一位能改派的客服人员，就能把它改派给自己再自己决定。
改派会生成一个新链接，旧的立刻失效，哪怕有人把它转发出去了也一样。
改派本身会出现在同一份清单里：谁在什么时候，把它从谁转给了谁。
没有人能以别人的名义做决定。链接是唯一的途径，而谁收到过它，都记在案件上。
两种模板对应两个时刻：回复模板填的是已打开工单上的评论编辑器，工单模板填的是新建工单表单。两者都属于 Basic。只有把回复作为邮件发出这一项依赖邮件通道，因而属于 Professional，模板本身不属于。
开始之前： 管理和套用是两项不同的权限。管理员和客服人员出厂设置下两样都能做。套用对每一个可以处理这张工单的人开放。就算某个角色不能管理设置，它照样可以套用模板。
模板在“Settings → Templates”下面。标题下面那行写明它们做什么、不做什么：“Reply templates fill the comment editor and suggest field actions. Nothing is sent automatically.”模板是准备好的一步棋，不是一台机器，发送始终由您自己来。
一共两种，创建时就要选定：“Add reply template”用于已打开工单上的答复，“Add ticket template”用于新建工单表单。种类之后不能改，因为它决定表单到底显示哪些字段。每个模板上方的标记会告诉您看的是哪一种：蓝色的“Reply template”，绿色的“Ticket template”。
一个回复模板由答复文字（“Reply text”）、“Internal note”复选框和任意多个动作组成。动作有六种：“Set the status”、“Set the priority”、“Assign to a user”、“Remove the assignee”、“Hand over to another team”和“Set a follow-up”。
“Assign to a user”列表的第一条是“The agent who applies it”。多人共用一个模板时就选它：工单随后属于套用它的那个人，而不是列表里某个固定的人。“Set a follow-up”要填一个数值和一个单位（分钟、小时、天、工作分钟、工作小时、工作日），再加上一条备注，之后它会告诉您这张工单为什么又回来了。
每个模板末尾那个蓝色方框会用一句话写明它将要做什么，比如“Inserts the text as a public comment, sets status to Waiting for Service Provider Response, assigns to the applying agent, sets a follow-up in 3 days.”您一边编辑，这句话就一边重写。它是您的对照检查：如果它说的和您想的不一样，那就是有一项设置错了。
文字不是必需的。“把它转给网络团队，一个字也不写”也是一个有效的模板，这时那句话会写成“Suggests actions without a reply text”。
在已打开的工单上，“Template”按钮在评论编辑器上方。点一下会打开随打随找的搜索框（“Search templates…”），选中一个就把评论编辑器填好。除此之外什么都不会发生，下面那行也这么写着：“Nothing happens until you add the comment.”
模板的每个动作都会在按钮旁边变成一个标签，用大白话写，不用行话：“sets status to Waiting for Service Provider Response”、“assigns to the applying agent”、“sets a follow-up in 3 days”。点一下标签就把它划掉：它被取消了，不会执行。再点一下又回来。
被取消的动作是划掉，不是移走。这样就能一直看到模板本来建议了什么，而且只要您还没发送，这个决定就可以改回来。
哪些标签一开始是激活的，由模板决定：在设置里每个动作都带一个“Suggested”开关。那个开关是对所有情况的建议；工单上的标签是对这一次的决定。
标签后面的“×”会把模板撤掉。文字留在编辑器里，因为您很可能已经改过它了；撤掉的只是效果，也就是动作、邮件和附件。
用平时那个评论按钮发送。这时评论才会创建，之后仍然激活的那些动作才会执行。
答复文字里可以用五个占位符，清单就在字段下面：“{requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}”。要带花括号写，和那里显示的完全一样。
“{ticketRef}”是形如“[TICKET-8-…]”的案件编号。系统正是靠它认出客户通过邮件回来的答复。相比之下，“{ticketId}”只是那个光秃秃的数字。
它们是在套用模板时解析的，不是在保存时：设置页面上始终显示“{requesterName}”，而工单上的评论编辑器里显示的是真实的名字。理由很实际：保存时就解析，会把某一张工单的值永久烧进模板里。
这样您在任何东西出门之前就能读到最终的文字。如果称呼不合适，您可以像改其他文字一样在编辑器里改它。
谁算“请求者”由工单决定，不由账号决定：工单上记录的请求者优先于提交它的那个账号。如果一位客服人员接完电话替同事开了工单，答复问候的仍然是那位同事，不是客服人员。
写错的占位符在保存时就会被拒绝，而且会被点名：“Reply text: unknown placeholders {requesterNam}. Available here: {requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}.”所以您在写模板的时候就会发现它，而不是在某个客户身上。
邮件主题有自己那份更短的清单（“{originalSubject}, {ticketTag}, {ticketId}”），所以那里又印了一遍。正文里的占位符在主题里不起作用，同样会被拒绝。
开始之前： 整个邮件通道属于 Professional，收和发都是。此外，团队邮箱那边必须打开工单操作发信。没打开的话，工单上根本不会出现邮件标签；模板的动作照常执行，只是邮件被略过。
“Send the comment as e-mail”开关会把这条评论同时变成邮件。这里刻意没有第二个文字框：工单里写的就是客户读到的，两份文字早晚会对不上。
在“Recipient”下面，您可以在“Requester”、“Assignee”、“Observers”和“Fixed address”之间选择。请求者是谁，由服务器在套用模板时解析，因为模板这时还不知道是哪张工单。收信邮箱账号本身永远不会被写信，那等于给自己发消息。
主题里可以用“{originalSubject}”、“{ticketTag}”和“{ticketId}”。请把“{ticketTag}”留在里面：系统正是靠这个编号认出客户的答复，并把它追加到同一张工单上。没有它，每一次回复都会变成一张新工单。
邮件以纯文本发出。加粗、列表和链接在发送前会被去掉，否则客户读到的就是原始标记。在工单内部，评论的排版保持不变。
在工单上，邮件是动作旁边的又一个标签（“E-mail to Requester”），和它们一样可以取消。所以模板绝不会在您没看过的情况下发出任何东西。只有当团队邮箱会发送工单操作邮件时，这个标签才会出现。
模板的附件（“Attachments”）是这些文件自己的副本。套用模板会把它们加到工单上，并在历史里留下自己的一行，它们不是邮件的一部分。给模板带附件不需要 Professional 许可证，只有发送才需要。
大多数模板不是在设计板上诞生的，而是在您第二次写同一份答复的那一刻。所以工单上的每条评论右边都有一个小纸张图标，写着“Make template”。它把这条评论原样拿来当起始文字，同事写的评论也可以。
如果工单有附件，会先弹出一个对话框问哪些要一起带上：“Tick only the attachments the template should carry — one of them may be a customer's screenshot. Nothing is ticked by default.”默认一个都不勾，这是有意为之。
之后您会来到模板页面，带着一份还没有保存的草稿。上面是琥珀色的横幅：“Draft from ticket #… — name it and review the text (it may contain customer details), then save.”名称是空的：您必须给一个，否则保存不了。
会带过来的是：文字、“Internal note”复选框、工单所属的团队，以及工单的状态作为建议，它的状态和优先级已经作为两个动作放在那里了。不会带过来的是：请求者、地址和标题。那些只属于这一个案件。
保存之前请把文字读一遍。它来自一个真实的案件，可能带着某个人的名字、一个订单号或者一个房间号。系统不会替您做匿名化处理，横幅上写了这一点，但做这件事是您的活儿。
只有点“Save”才会真正生成模板；勾上的附件这时才被复制过去，并有一条消息确认。
“Applies to”决定谁会被提供这个模板：某一个团队，或者“All teams”。新模板一开始是某个具体的团队，“All teams”得有人专门去选，不是一个不吭声的默认值。
在一张工单上，您会被提供所属团队的模板加上全局模板。如果工单在转交之后到了另一个团队，这份清单也跟着变，您能选的是新团队的模板。
“Draft”开关把模板变成您自己的工作台：“Only you can see this template until you publish it.”别人的草稿不会出现在任何清单里，也没法通过地址访问到，管理员也不行。新模板一开始是草稿；只有把这个开关关掉并保存，其他人才看得到。
两个可能同时出现的模板不能重名：一个全局模板和任何团队里任何同名的模板都会冲突。不过回复模板和工单模板可以重名，因为它们从不会并排出现在同一份清单里。
“Duplicate”生成一个副本，副本永远是草稿：“Duplicated. The copy is a draft only you can see.”想做一个变体时，这是最省事的路，别人不会被提供那个做了一半的版本。
工单模板填的是“Create new ticket”表单。它没有答复文字，没有动作，也没有邮件，因为这个时刻还没有工单可以让动作作用其上。所以这个表单显示的字段和回复模板不一样，绿色的边框告诉您看的是一个工单模板。
可以预填的有“Ticket title”、“Owning team of the new ticket”、“Main category”、“Subcategory”、“Priority”和“Ticket description”。每个字段都可以停在“Not prefilled”上，留空的部分由之后使用表单的人来填。
请注意两个团队字段的区别：上面的“Applies to”说的是谁看得到这个模板。“Owning team of the new ticket”说的是新工单落到哪里。这是两个不同的问题，答案也可以不同。
分类是按团队分组的，因为分类属于团队。如果您选了另一个团队的分类，表单会提示您，并且拒绝保存：在目标团队的新建工单表单上，那个分类根本不会被提供，预填也就落了空。
这里没有占位符，文字下面的提示也这么写着：“No placeholders here: the template only prefills the form, nothing is resolved or sent.”一个“{requesterName}”会原样进到新工单里，所以它在保存时就会被拒绝。
蓝色方框在这里同样总结了模板会做什么：“Prefills the new ticket with title ‘New notebook for a colleague’ · category Notebook / New request · priority Medium · team Helpdesk · the description.”
在表单本身上，您用“Template”按钮选模板，旁边写着“Prefills the form - nothing is created until you submit.”预填的一切都还可以改，不提交就什么都不会创建。
系统自带一个示例模板：“Example: create accounts for a new colleague”。它让您看清这东西长什么样，本身什么也不做，您可以照着重建它，也可以删掉。
“Offer this template to customers”开关出厂时是关的。旁边的提示把您需要知道的两件事都说了：“Customers can pick this template when they create a ticket. A draft stays hidden either way.”
它默认关闭的原因是：模板的名字常常用的是内部说法，写的时候面向的是同事。让它对客户可见，是一次对外的表态，这该由人有意去做，而不是不小心做出来的。
客户在新建工单表单上方看到的是同一个“Template”按钮，但只看得到已开放的模板。草稿即使开关打开也仍然是隐藏的，这两条规则是前后相接的，不是并列的。
这么做图的不是方便，而是第一次接触：一份提交时就完整的请求，省下的那轮追问原本要花两天。把那些问题写进模板的描述里，客户在创建工单时就把它们答了。
用“Fields to ask for”还可以更进一步。模板随后决定表单询问哪些自定义字段、按什么顺序，以及其中哪些必填。这份选择会替换团队原本的字段，而不是叠加上去。这正是它的用途。自定义字段本身属于 Professional，它的卡片叫“Custom fields”。把模板对客户开放在每个版本里都能用。
对客户隐藏的字段仍然隐藏，哪怕模板把它列了出来。字段选择是用来理顺和裁剪的工具，不是绕开字段设置的路。
每一次套用都会在历史里写下一条记录，字段名是“Template”。它点出模板的名字，并列出实际执行了什么。没有它，之后就没法解释一张工单为什么突然跳到了“In Progress”：各个动作确实会写下自己的行，但没有一行点出模板。
图里写的是：“Template ‘First reply: we have your ticket’ applied: Assign: already assigned to that user; SetStatus: Assigned -> InProgress”。前半句不是错误。发送评论时工单已经记在这位客服人员名下了，所以分派动作没什么可做的，而这条记录写的正是这一点，而不是声称发生了一个从未发生的效果。
被取消的动作不在里面：它们没有发生。失败会在里面，而且会被明确写成失败，跟在“failed”这个词后面。
这条记录是内部的，请求者看不到。模板的名字属于内部说法（比如“标准拒绝”），而历史对工单的创建者也是开放的。字段变动本身他仍然看得到，看不到的只是它们出自某个模板。
作者是那位客服人员，不是“system”，也不是模板。这是有意为之：套用它是他的决定。和自动化规则不同，这里写在工单上的是一个人。
通往同一个目标的两条路：不让任何案件因为没人再想着它而躺在那里。跟进是您自己设的，属于 Basic。规则不用您动手就会做，属于 Professional。
开始之前： 只有客服人员和管理员看得到跟进，工单上也这么写着：“Only agents and administrators see this — the requester never does.”请求者始终看不到它。
跟进在工单右侧的“Details”卡片里，位于期限下面。还没设的时候写着“No follow-up set.”，旁边是一个“Set follow-up”按钮。您选一个日期和时间（“Date and time”），再加一条备注（“Note (optional)”，提示文字是“Why is this coming back?”）。之后按钮变成“Change”和“Remove”。
价值在那条备注上。两周之后，光一个日期不会告诉您这张工单为什么又回到桌上。这也是备注挂在日期上的原因：把日期删掉，备注也跟着走，因为一条没有日期的理由，谁也不会再看到它。
工单列表上方有一行“Follow-up:”，带四个按钮：“No filter”、“Today”、“This week”和“Overdue”，列表本身也有一列“Follow-up”。它刻意没有放进收起来的筛选块里：这是客服人员一天开始时要问的问题。
“Overdue”包含今天的。否则跟进偏偏会在它起作用的那一天消失，就在当天那个时刻过去的时候。
开始之前： 新规则永远是以关闭状态创建的，就算您在界面上试图以打开状态创建也一样。一条刚建好就跑遍您全部积压工单的规则，正是系统在这里替您挡下的那种事故。它要到下一次“Save”才真正上线。
规则在“Settings → Automation”下面。标题下面那行写明这是干什么的：“Rules that act when nobody else does.”一条规则属于一个团队，作用在该团队的工单上；上方的“Team”选择框决定您正在看哪些规则。
它和系统里其他一切的区别在于：这些规则不是对事件作出反应，而是对事件的缺席作出反应。请求者三天没有回复、一周没有任何动静、创建了四小时还没有人认领，这些都没有哪一次点击会触发它们。也正因如此，才没有人会注意到。
上方的绿色横幅告诉您检查正在运行：“The automation checks every minute. 2 of 6 rule(s) are enabled.”一条规则都没启用时，您会看到警告“No rule is enabled. Nothing is being checked and tickets behave exactly as before.”，那时确实什么都不会发生。
一条规则有三块。“WHEN”是它作出反应的那个缺席（“Something has not happened for a while. This is what the automation reacts to.”）。“IF”把范围缩小到哪些工单（“Which tickets it applies to.”），按状态、优先级、团队、分类、负责人或评分。“THEN”是要发生的事。
这些块的上方，整条规则以一句话呈现，每改一处它就重写一遍：“When a ticket has seen no activity for more than 5 minutes and has the priority “High”, then set a follow-up in 4 hours.”如果还缺什么，这句话会当场指出来，而不是把它藏起来。
在“IF”块里，您还要决定条件之间怎么组合：“All conditions must apply”还是“Any condition is enough”。上面那句话的写法会跟着变，否则用一个“并且”写出来，说的就和规则实际做的相反了。
有两个字段决定多条规则之间怎么配合：“Order”决定顺序，而“Skip the following rules for a ticket this rule applies to”这个开关，会对这条规则命中的工单停掉后面所有的规则。
更多内容见这张卡片： 差评作为触发条件
每套安装都自带四条规则：“Example: remind the requester after 3 business days”、“Example: close after 10 days without a reply”、“Example: raise the priority of unassigned tickets”和“Example: follow up on tickets nobody touched for a week”。它们在“Automation”页面上依次排列。
四条都是关着的，每一条都带灰色的“Off”标记和“Last run: never”。它们是拿来读、拿来照着重建的起点，不是谁悄悄塞给您的行为。您可以改名、修改、打开，或者删掉。
它们的适用范围还是“Every team”，这是系统里唯一一处没有明确选择就这样设定的地方。所以在打开某一条之前，请先确认它是不是真的适用于您所有的团队。
每条规则下面都有一个按钮“Which tickets would this affect?”。点一下就显示清单“Tickets this rule would affect right now”，也就是此刻这条规则命中的工单，带编号和标题。
下面写着预览不做什么：“The preview only reads. It changes nothing and writes no log entry. Unsaved changes are not included.”最后一句很要紧：预览用的是已保存的规则，不是表单里当前的内容。
如果规则此刻什么都没命中，它也会说：“No ticket matches this rule right now.”这正是您打开它之前想要的答案，而不是打开之后从客户的工单上得到的答案。
开始之前： “Send an e-mail”动作走的是系统其余部分用的同一条邮件通道。没有配置好发信就什么都不会发生，而 Basic 安装根本没有这条通道。
在“THEN”块里可以从七个动作里挑：“Send an e-mail”、“Set the status”、“Set the priority”、“Assign to a user”、“Remove the assignee”、“Hand over to another team”和“Set a follow-up”。“Add action”可以再加；每个动作都有自己的“Active”开关，所以您可以只让其中一个安静下来，而不必关掉整条规则。
“Send an e-mail”的收件人要一个一个勾：“the requester”、“the assignee”、“the observers”和“a fixed address”，最后一个还带自己的地址字段。“Set a follow-up”要填一个数值、一个单位，以及之后会留在工单上的那条备注。
“Hand over to another team”的提示就在它下面：“The ticket moves to that team and the current assignee is cleared. No second ticket is created.”所以不会多出一张重复的工单，同一个案件只是换了手。
“WHEN”块里的每个时间条件都有三部分：种类、比较词“longer than”，以及一个带单位的数值。种类有五种：“Time since the ticket was created”、“Time without any activity”、“Time without a reply from the requester”、“Time without a public reply from an agent”和“Time without a status change”。
单位决定时间怎么算，而且是按条件分别决定的：“minutes”、“hours”和“days”是连续计算的，夜间和周末也算。“business minutes”、“business hours”和“business days”按团队的工作时间日历计算，只有落在营业时间内的部分才算数。
在日常使用里，这个区别很大：三天就是三天，而在周一到周五的一周里，从周四起算的三个工作日会落到下周二。用的是和服务级别协议期限同一套日历。
每条规则下面都有一个“Log”按钮。它打开“What this rule did”表格，每个受影响的工单一行：“When”、“Ticket”、“Cycle”、“Result”和“Details”。“Details”里写着具体做了什么，比如“SetFollowUp: 2026-08-20 02:18Z”。如果某条规则还什么都没做，它也会说：“This rule has not done anything yet.”
“Cycle”列正是规则不会每分钟对您嚷一遍的原因：它对一张工单在一个周期里只动一次。只有当规则不再命中这张工单时，一个周期才结束，所以客户回复之后又没了动静，第二个周期就开始，规则会再动一次。
在工单本身上，规则以作者的身份出现。它在历史里以自己的名字显示，带“Automation:”前缀，比如“Automation: High priority: bring it back to us”。所以在每个案件上，您都能查到是人还是规则动的手，如果是规则，是哪一条。
每条规则的标题行还写着“Last run:”和上一次运行的时间，从没运行过的规则写的是“never”。
勾上多张工单，一次改完。这一切都属于 Basic。只有模板发给客户的那封邮件依赖邮件通道，因而属于 Professional。真正的要点不是工单的数量，而是对部分结果的诚实处理：每一条规则都作用在单张工单上，所以系统会事先说明这个动作适用于多少张，事后说明哪些没有跟上来，以及为什么。
工单列表最左边有一列复选框。它是给管理员和客服人员用的。客户永远看不到它。
表头行里的复选框选中的是您当前这一页的所有行，不是整个结果集。如果您需要更多，就把筛选收紧一些。用筛选来说明数量，比用一个连看不见的工单也一并勾上的复选框更诚实。
只要您翻页、筛选、搜索或切换团队，选择就会清空。这样就不会有已经不在屏幕上的选择被一路带着走。
图里的列表并没有显示所有工单。右上角“Filter”旁边写着“active”，再旁边是“Reset”：已关闭的工单被隐藏了，因为批量操作针对的是还在进行的案件。选择永远只覆盖列表当时显示的内容。
勾上第一张之后，列表上方会出现一条工具栏。它显示“20 selected”，旁边是“Clear selection”，以及“Change status”、“Assign”、“Assign to me”和“Apply template”几个按钮。再往右是“Multiple report”和“Group into incident”，这两个属于重复报障，下一块会讲。
“Change status”会打开一个小对话框。您选好目标状态，下面那行立刻写出选中的工单里有多少张适用。
如果目标状态要求填写评论，会出现一个文本框。下面写着这段文字会送到多少张工单上。它会送到每一张被改动的工单，不只是第一张。
并不是每种状态都会出现在清单里。系统状态不在，因为没有人会手工设置它们。“Waiting for other team”也不在：那个状态会为某个目标团队生成一张子工单，而这个团队是按工单分别选的。在批量里，这一项就只有一个输入框了。
在详情页上更改一张没有负责人的工单的状态时，它会被分派给您。在批量里不会这样：否则“关闭 30 张工单”就会不声不响地变成“30 张工单分派给我”外加 30 封邮件。
这个对话框不改动别的东西。优先级、分类以及更多内容，在批量里通过回复模板来设置。
更多内容见这张卡片： 给单项任务的第二级审批
“Assign”会打开客服人员清单。离开中的客服人员仍然可以被选中，只是被标注出来，和单张工单上完全一样。
“Assign to me”是同一个对话框，只是预先选好了您自己的名字。它是一条捷径，不是第二条路，适用的规则完全一样。
每一次分派都会给客服人员发一封邮件。对话框事先写出数量：“This sends 11 e-mail(s) to the selected agent.”十一张工单就是十一封邮件。
客服人员必须属于那张工单所在的团队。所以跨两个团队的选择，没法一次交给同一个人。这不是批量操作的限制，单张工单上也是同一条规则。
分派不能被重置成“没有人”。单张工单上就没有这一项，批量里自然也没有。
“Apply template”把一个回复模板套用到所有选中的工单上。每张工单得到的评论，和您手工套用这个模板时得到的一样。
清单里会提供选择中出现过的每个团队的模板。只要一个模板适合至少一张选中的工单，它就会出现；到底适合多少张，接下来的预览会说。
服务器按工单分别解析占位符，所以每位客户都得到属于自己的称呼和自己的工单号。对话框里的提示也这么写着。
模板的字段动作会一起执行，它的附件会被复制到每一张工单上。
在批量里，模板的所有动作都会执行。只有在单张工单上才能逐个取消；如果您不想要某个动作，就用一个不带它的模板。
如果选择中的那些团队没有可用的模板，对话框会说明：“No reply template is available for the teams of the selected tickets.”
三个对话框在任何事情发生之前，都会显示同一行：“Applies to 19 of 20 selected ticket(s)”。
下面是“Will be skipped”方框，每一张跟不上来的工单一行，写明工单编号和原因。所以在点击之前，您就读到了为什么这个数字比您选的少。
执行之后写的是“19 changed, 1 skipped”，同一个方框变成“Not changed”。内容是一样的，只是从预告变成了陈述。
原因和单张工单上的一样。工单已经处于目标状态。从它当前的状态不允许这样转换。它属于一个您不负责的团队。选中的客服人员不在它的团队里。它在等审批。它是一张还有未结报障的故障工单。它是一张还有未结子工单的父工单。
被跳过的工单仍然保持选中，被改动的则不再选中。所以换一个目标再试一次只有一步之遥，也没人需要猜哪些还没处理。
预览是第二意见，不是许可证。动作执行时，服务器会把每一张工单重新检查一遍，因为一张工单可能在显示和点击之间发生变化。
一次调用最多接受 200 张工单。每页 20 行的话，离这个上限还远得很。
只有会发邮件的模板才会出现发信复选框，而且要邮件通道是通的。它默认不勾，所以在您勾上之前，批量操作不会向外写出任何东西。
如果通道不通，复选框的位置上写的是原因：要么邮件发送被关掉了，要么选中团队的邮箱不发送工单操作邮件。这一点您在点击之前就读到，而不是事后从结果里读到。
一旦勾上，就会出现一条带数字的琥珀色提示：“This sends 20 e-mail(s) to customers.”这个数字来自预览，是模板真正适合的工单数。
更改状态和分派永远不会向客户写信。分派确实会发邮件，但是发给客服人员。批量套用模板是唯一会产生客户邮件的那条路。
发送依赖邮件通道，因而依赖 Professional。通道关着时不会有邮件发出，工单历史里会写明原因，它绝不会声称发生过一次没有发生的投递。
批量操作做的每一处改动，都会出现在单张工单的历史里。它在那里和其他改动看起来一样，带旧值和新值。
请求者同样看得到这些行。对他来说，一次状态变动就是同一件事，不管它是单独触发的还是批量触发的。把它藏起来并不更体贴，只会更糟。
批量分派会写下两行这样的记录：新负责人旁边写着状态，因为被分派的工单会转到“Assigned”。
此外还有一行内部记录，带着这次运行的编号。凭这个编号，之后可以找出同一次运行涉及的所有工单。这一行请求者看不到。
每一行都写明是谁触发了这次批量操作。
被跳过的工单不会有记录，连一条关于尝试过的记录都没有。没发生的事不进历史。
有两种情况看着很像，其实不是一回事。如果同一个人把同一件事报了两次，就该有一条消失。如果很多人报同一次故障，那就一条都不能消失。两者各有各的路，区别在于请求者是谁。
在工单列表里勾上那些行，点“Multiple report”。勾上两行起，这个按钮才可用。
对话框先问：“Which ticket stays?”最早的那张工单是预选的，这样期限就从请求者第一次联系开始算，而不是从他第二次尝试算。您也可以另选一张。
下面写着方向和两个编号：“#11 will be closed and moved into #10.”所以在点击之前就能看清哪张工单会留下。
什么都会跟过来：评论、附件，还有第二条报障的描述。描述会变成原工单上的一条评论，保留原来的作者和日期。对话框事先会写出数量。
记录的工时是移动，不是复制。否则同一份工作量会同时挂在两张工单上，被开两次账。
第二条报障不会被删除。它被关闭，并从此指向原工单，它的编号仍然有效。
请求者不会另外收到一封邮件。他就在原工单上，在那里什么都看得到。被关闭的报障上有一条评论指出原工单，他可以读到。
没有撤销。所以在您点“Merge”之前，所有信息都摆在对话框里。
之后，两张工单的历史里都记着谁在什么时候合并了什么。
开始之前： 这需要邮件收信。没有它，就不存在需要被引导的邮件回复。
请求者的邮箱里放着旧的工单号。他不知道有两条报障被合并了，回复的是自己手上的那封邮件。
这条回复会落到原工单上。系统顺着被关闭的报障所带的那个指向走。
所以被合并的报障永远不会被删除。没有它，那个指向就不存在，回复也就无处可去。
参与过旧报障的人，同样可以在原工单上发言。检查是针对邮件里写明的那张工单做的。
如果您选了不同人的工单，对话框不会把它们带上。它会在您点击之前，逐条写明被拒绝的行和它的原因。
原因写的是：“Different requester — this is an incident, not a multiple report.”它还告诉您该去哪条路。
这是整个功能里最重要的一道闸门。如果您把三十个人的三十条报障合并了，其中二十九个人会失去自己的工单，从此再没有下文。
请求者是谁，取自工单上的“User”字段。如果它是空的，就算创建这张工单的那个账号。
所以这道闸门对电话记录同样有效。如果一位客服人员记录了两通电话，两张工单都是他创建的。不同的来电者仍然是不同的人，因为他们的名字写在那个字段里。
如果有一边的请求者无法确定，同样会被拒绝。不知道不等于同一个人。
同一个方框里还会出现别的原因。故障工单不能被合并。已关闭的原工单不再接收任何东西。而一条本身已经带着报障的报障也不会跟过来，这样就不会形成链条。
文件服务器一坏，二十个人来报障。这些报障每一条都是自己的案件，各有各的请求者。在这里合并是错的，因为会有十九个人失去自己的工单。
勾上这些报障，点“Group into incident”。对话框给出三条路：加进一张已经打开的故障工单，把选中的某张工单声明为故障工单，或者新建一张带自己标题的故障工单。
如果这个团队已经有一张打开的故障工单，那条路是预选的。它更常见：故障早就知道了，只是新的报障还在不断进来。
每一张关联的工单都保留自己的请求者、自己的状态和自己的期限。什么都不会消失。故障工单归拢的只是答复。
同一张故障工单下的所有报障必须属于同一个团队。如果一次故障牵涉两个团队，每个团队各有一张故障工单。否则一个团队的解决会清空另一个团队的队列。
后来的报障也可以在单张工单上挂进去。如果这个团队有一张打开的故障工单，上方会出现一条提示，带“Assign”和“Not related”。系统从不自己挂：挂错的工单会收到一份与它无关的解决说明，还会顺带被关掉。
故障工单上写着挂了多少条报障。关联的工单反过来带着它那张故障工单的编号，在列表里和右侧卡片里都有。
“Resolve incident”关闭故障工单，并一次答复所有报障。解决说明是必填的：它正是这个功能的全部意义，因为它会送到每一位受影响的人手里。
每一张关联的工单都会收到这段文字作为对客户可见的评论，被设为选定的状态，它的请求者会收到属于自己的邮件。没有群发，因为那会暴露所有受影响者的地址。
之后的消息会写明关闭了多少张工单、通知了多少位请求者。两个数字分开写，因为一张没有可用地址的工单会得到评论和状态，但收不到邮件。
您自己中途已经答复并关闭的工单不会被碰。它不会被第二次关闭，也不会再被写信。
只要还有未结的报障挂在一张故障工单上，它就不能通过普通的状态变更关闭。否则会有二十个人不声不响地得不到答复。
对话框和故障工单上都有“Also show as a banner on the sign-in page”复选框。有了它，所有人在再开一张工单之前就知道有故障。
横幅显示在登录页上，登录之后也显示在系统内部。它写着“Known incident”和故障工单的标题，所以这个标题是给客户看的文字。
如果有多条通知同时生效，它们会上下排列。已经公告的周六维护不会挤掉今天的故障，反过来也一样。
如果还是有人新建了工单，自动回复里会点明这次故障。这对已经关联的工单以及该团队的每一张新工单都成立，只要故障工单还开着并且已经公告。这需要邮件发送。
故障工单一解决，横幅自己就没了。没有人需要记着再去关掉它。
在“Maintenance / Incident-Notification”页面上，您可以看到当前是哪一张故障工单在作为横幅显示。那个页面上的开关属于计划内维护，对故障不起作用。
与您营业时间相匹配的期限：一份策略说明您要多快回复、多快解决，一份日历说明计时器什么时候才走。这一块里的一切都属于 Professional。
开始之前： 没有生效的策略，系统什么都不测量：没有期限，没有列，也没有邮件。而且计时器是在工单创建时生成的：在您打开策略之前进来的工单，不会有期限。这是有意为之，否则第二天早上会有一千张旧工单显示为超时。
期限在“Settings → SLA”里设置。这个页面在没有生效策略时会在上方明说。一条策略有三部分：一个名称、若干条件和若干目标。新策略刻意以未生效的状态创建，这样您可以先把它配好，再让它开始起作用。
条件是“Team”、“Priority”、“Main category”和“Subcategory”。留空表示“任意”，也就是“适用于所有”，不是“不适用于任何”。如果有多条策略命中，“Order”里数字最小的那条胜出；所以窄的策略排在上面，通用的排在下面。
两个分类字段是按团队分组的，因为分类属于团队，但系统会把所有分类都提供给您，包括别的团队的。这是有意为之：转交时工单会走，分类不会。帮助台转交给网络团队的工单仍然带着帮助台的分类，而一条策略正可以指向它。选定主分类之后，下面的字段只提供与之关联的子分类，一个工单上不可能出现的组合在保存时会被拒绝。
每条策略有两个目标。“Time to first response”在客服人员写下第一条对客户可见的回复时结束，自动确认信和内部备注明确不算。“Time to resolution”在工单进入一个算作已解决的状态时结束（哪些算，您在“Settings → General → Status”里设置）。两个目标各有自己的分钟数、自己的日历，以及自己对超时的反应。
在工单上，期限位于右侧的“Details”卡片里，下面是“Show deadline history”：一份记录每一步的日志，开始、暂停、恢复、达成、超时，每一条都带原因和已用掉的工作时间。只有客服人员和管理员看得到它，客户那边根本调不出来。
如果之后有人改了优先级或团队，计时器会切换到当时匹配的那条策略：此前用掉的工作时间按旧日历结清，之后按新值算。如果再也没有策略匹配，计时器就没有结论地结束，既不算达成，也不算超时。
日历说明计时器什么时候走。它有一个名称、自己的时区，以及每个工作日任意多个时段，午休就是一天里有两个时段。一个时段可以跨过午夜，那时旁边会写着“ends next day”。
一个团队用哪份日历，在团队上设置（“Settings → Teams”）。在策略的单个目标上还可以覆盖它：“From the team”用团队那份，或者您另选一份。常见的做法正是这么来的：故障不分昼夜地算，其他的只在办公时间算。
算的是时段之内真正流逝的时间，不是两个钟点读数之间的差。在夏令时切换时这就有区别了：十月里一个全天候的日子有 25 小时，春天里 22:00 到 06:00 的夜班只有七小时而不是八小时。09:00 到 17:00 的办公时段永远不受影响，因为在欧盟切换发生在夜里。
如果找不到任何有营业时间的日历，就不会生成期限，宁可没有，也不要猜一个。工单上出现的是一条提示，而不是一个日期。
开始之前： 我们不随产品提供任何假日数据。公共假日取决于地点，不取决于语言：德国 16 个联邦州，瑞士 26 个州，美国 50 个州，而且每年都不一样。随产品带的清单迟早会出错，还没有人会发现。请用您所在地区的官方 .ics 文件，一年花一分钟。
每份日历下面都有“Closed days”清单。点一下“Import holidays (.ics)”接收一个日历文件，之后会报告四个数字：接收了多少天、替换了多少天、有多少读不出来，以及有多少本来就有。您也可以手工录入单个日期。
日期后面的 ↻ 符号表示“每年重复”。它只对固定日期正确：10 月 3 日每年都是同一个日期，而耶稣受难日和圣灵降临节星期一挂在复活节的日期上，会移动。所以移动的假日会按年份以具体日期列在清单里，图里的“Good Friday”就没有这个符号。
一个休息日会吞掉这一天的整个时段，包括伸进第二天的那一部分。而当一份日历在未来十二个月里一个休息日都没有时，页面会明确说明这一点，否则系统会不声不响地把假日算进去，得出错误的期限。
关于期限最常见的争论就是这一条：工单已经等客户回话三天了，计时器还照走不误。所以每个目标都有“Pause while waiting for the requester”开关，是按目标分别设的，不是整条策略一起。
是不是在等，由状态决定：在“Settings → General → Status”里，每种状态都带一个标记，说明它是否算“在等请求者”。开关打开时，工单处于这样的状态期间，期限就歇着。挂钟时间照常走，所以列表里显示的是“Paused”而不是剩余时间，期限历史里则有带时间的“Paused”和“Resumed”。
对首次响应，通常把这个开关关着：不管在等什么，第一条回复都是您欠着的。对解决，通常是打开的。图里正是这样的设置。
只要有一条策略生效，工单列表就会多出“Deadline”列。它显示下一个未结期限的剩余时间（“14h 53m”）。等工单上再没有正在走的期限时，那里显示的就是结论：达成的是“In time”标记，超时的是红色的“Breached”。完全没有计时器的工单显示一个中性的短横线，这是有意为之：策略生效之前的工单不算失败。
如果没有生效的策略，这一列干脆不出现，而不是空着摆在那儿。筛选也一样：只有确实存在期限时，“Filter”里才会出现“Breached only”这个勾选项。
一张工单有两个计时器，而这一列只有一个位置，它显示的是最紧迫的那个未结期限。如果首次响应已经超时而解决还在走，这一列显示的是解决的剩余时间，旁边带一个红色的“!”。这个标记的意思是：这张工单上已经有一个期限超时了，而“Breached only”筛选找的正是这个，因为它问的是有没有任何超时的期限，包括早已结束的那种。到底是两个里的哪一个，写在工单本身里。
还可以按它排序：同一个“Deadline”标题下有一个字段，可选“Due soonest first”和“Due latest first”。没有正在走的计时器的工单永远排在最后，它们不是最不紧急，而是根本不涉及。按期限排序优先于按“Updated at”排序：没有哪份列表能同时满足两种顺序。
开始之前： 转交刻意不是默认动作。它会转移责任、清空负责人并重置状态，一张正有人在处理的工单，之后就躺到别的地方去了。只有当您要的正是这个效果时才选它。
每个目标都可以在“When breached”下面设定超时后发生什么：“Record only”只做记录，“Notify assignee and observers”给负责人和关注者发一封邮件（不是发给整个团队），“Hand over to another team”把工单转交出去。转交必须选一个目标团队，没有选的策略在保存时会被拒绝，因为它看着配好了，实际什么也不做。
这个动作对每个计时器只执行一次。没有这道闩，服务器一重启就会把同一封邮件再发一遍。就算发送失败，“已执行”标记也会被设上，因为一封没送到的邮件，好过一个每分钟都新发一封的循环。
超时本身以它到期的那一刻为准，而不是以检查运行的时刻为准，否则报表就会挂在检查服务的节奏上。而且它是按用掉的工作时间衡量的：暂停中的计时器不会超时，哪怕到期日早就过去了。
在“Reports”里选好时间段，按“Generate report”，不点这一下页面就是空的。报表随后包含“Service level agreements”一块，每个目标一行：达成、超时、仍在进行、达成率和平均用时。
统计是按目标算的，不是按工单算的，表格下面也这么写着。所以一张两个目标都有的工单会出现两次，每一行里各一次。
达成率只统计已有结论的计时器。还在走的不属于分母，否则每一套刚打开的服务级别协议一开始都会显得糟透了，然后自己慢慢变好。如果一个有结论的计时器都还没有，显示的是一个短横线，而不是“0 %”。
如果您用群体故障，还会多出一行“Achieved without group incidents”：一次故障挂上一百张工单，否则会把达成率往两个方向都带偏。
客服人员记录一个案件花掉的工作量。这说的是工单上的工作，不是某个人的出勤，它明确不是考勤系统。这一整块都属于 Professional。
工时记录在出厂设置下是关的。关着的时候，既没有字段，也没有列，报表里也没有相应的卡片。
一个用不了的字段比根本没有更糟，所以这个功能是整个消失，而不是灰着摆在那里。
开关在“Settings → General”里的“Time tracking per ticket”卡片上，叫“Enable time tracking”。
之后所有团队都参与。要漏掉某个团队，就在那个团队本身上关掉它，位置在“Settings → Teams”的“Team details”方框里。
一家既有内部 IT 团队又有面向客户团队的公司，往往只需要后者记工时。
如果您之后又把工时记录关掉，已有的记录仍然可读、可导出，它们是开票的依据，不是一项便利功能。只是不能再记新的了。
工单上有一张叫“Time spent”的卡片。“Log time”打开输入框。
字段旁边是快捷按钮：点一下“30m”就记下三十分钟。出现哪些按钮，在设置里定。
“Duration”字段也接受自由输入：“90”是九十分钟，“1.5h”是一个半小时，“1h 30m”也是。不带单位的数字一律按分钟算。
系统看不全懂的输入会被拒绝。“1h in the evening”不会变成一小时的记录，只会变成一条错误提示。
在“What for (optional)”里写这段时间是干什么的。这段文字会进到导出里，不会出现在工单历史里。
多位客服人员在同一张工单上记工时。每条记录都带日期、备注和做这份工作的人的名字。
工时记在某一天上，不记在某个钟点上。补记昨天是常态，而钟点会声称一种输入本身并不具备的精确度。
遇到长时段的工作，工单上有一个秒表：“Start timer”启动，“Pause”暂停。
秒表从不自己生成记录。它只是给出已经过去的时间，在您按下“Log”之前什么都不会保存。
它替代的是心算，不是知识。没有它这个功能也是完整的，因为把数字敲进去才是主路。
打开另一张工单会让正在走的秒表暂停，新工单会告诉您它挂在哪张工单上。
窗口被挡住不等于休息。您只是点开别处的话，秒表照走。
为了防止秒表跑一整夜，有一个最长运行时间。数值会被封顶，绝不会被丢弃，而且会告诉客服人员。
秒表在出厂设置下是关的。您可以在设置里的“Stopwatch on the ticket”找到它。
每条记录都带一个“Billable”勾选项。时间只记一次，勾选项决定它进不进账单。
所以工单上显示两个合计：左边是全部记录的，右边是可计费的。
没有专门的情面减免类型。情面减免、保修工作和内部返工，每家公司叫法都不一样，而系统只认那一个和钱有关的区分。
情面减免是这样记的：照常填时间，把勾去掉，把理由写进备注。
这条记录随后会明显带着“not billable”。这些分钟仍然算在记录的合计里，因为工作确实做了。
干脆不记时间的人，丢掉的正是那个之后用来解释为什么只向客户收了这么少的数字。
如果您的工作大多不可计费，就用“New entries are billable by default”开关把默认值反过来。
出厂设置下一切按分钟计费。按一刻钟计费的人要设两个值。
“Rounding increment (minutes)”是步长。每条记录都向上取到下一个整数倍。
“Minimum per entry (minutes)”是下限。每条记录至少按这个值计费。
两者是先后作用的：先下限，再步长。下限 20、步长 15 时，五分钟会变成三十分钟，因为结果必须同时满足两者。
两个字段下面有一句用您自己的数值算出来的示例。它是算出来的，不是随口说的。
取整永远只作用于计费值，而且只按单条记录，绝不对合计取整。所以两条小记录会各自向上取整一次。
记录的时间保持不变。之后改取整规则不会篡改任何旧数据，因为那个值是在显示时才算出来的。
在记录上两者都看得到：凡是取整改变了数值的地方，结果会写在旁边的括号里。
服务商往往不希望有工单在没记工时的情况下被关掉。为此有一个开关。
它叫“Require a time entry before resolving or closing”，出厂设置下是关的。
它只在人改状态时生效。没有记录的客服人员会收到一条提示，工单保持打开。
自动关闭、合并和批量操作永远不会被拦。否则就会出现没人能再关掉的工单。
这是整个功能里最危险的一个开关。只有当您的团队真的每次都记工时了，才把它打开。
工单列表会多出一列“Time”，显示一个案件上已经记了多少时间。
这一列不用您去打开。只要列表里有工单带着工时，它就会出现。
窗口窄的时候，它是最先被去掉的列之一。列表这时保留的是没有它就找不到工单的那些列。
只写在单张工单上的时间不能作为开票依据。所以报表页面上有一张“Time spent”卡片。
上面是四个数字：记录的、计费的、记录条数，以及总共有多少张工单带着时间。
除了合计之外，最后那个数字最重要。五百张工单里只有三张记了四十小时，这不是一份统计，而是只有三位客服人员在记。
下面是各种细分：按请求者、按团队、按分类、按日期。
此外每个自定义字段还各有一张表。按公司或成本中心开票走的就是这条路：您建一个自定义字段，在工单上填好，报表就按它分组。
页面上方的时间段针对的是做工作的那一天。所以六月的工单在七月做的工作，进的是七月的报表。
数字上方有一条提示值得认真对待：它们来自人填的记录和您设定的取整规则。它们是工作依据，不是经过审计的账单。
卡片下面有三个按钮。它们给出的是单条记录，不是页面上的合计。
这是两类收件人，不是三种文件格式。“Export entries (CSV)”和“Export entries (Excel)”是给财务的：两者都是完整的，永远不会被截断。
“Export entries (PDF)”是给人看的文件。它作为账单的附件送到客户手里。
PDF 最多 20 000 条记录，文件里自己也写着这一点。反正没有人会去读比这更长的账单。
三个文件出自同一个源头：筛选、取整、列和数字都只存在一份，所以三者不会互相走样。
不可计费的记录，在计费那一列里是空单元格，不是零。零在数据透视表里会被加进去。
客户从来看不到工时记录，在自己的工单上也看不到。
这不是一项设置，而是服务器里的一道锁。没有哪个开关能打开它。
原因就在记录本身：备注是写给团队看的。它们写的是哪里出了问题，以及找原因花了多久。
同类的其他系统也是这么做的。凡是时间会到客户手里的地方，它到达的形式是一份文件。
PDF 导出就是干这个的：它随账单发出，而不是出现在客户门户里的工单上。
更多内容见这张卡片： 给财务和给客户的导出
报表还可以额外显示谁记了多少。出厂设置下不显示。
按人统计的工时属于绩效数据，在很多公司职工委员会对此有话语权。
这个开关叫“Per-agent evaluation”，在设置里。
关着的时候，服务器根本不提供这些数字。那张表不是被藏起来了，而是不存在。
这个区别很要紧。一道只有显示层知道的锁，不是锁。
更多内容见这张卡片： 没有在岗历史，也没有按人统计
仪表盘显示一个团队目前的情况。报表回答的是您自己提出的问题。两者都只做读取，谁都不会改动一张工单。除了您自己的字段之外，这一整块都属于 Basic。
上方每种状态一块，带各自的数量。它们下面是整个团队的三个数字：“Total tickets”、“Tickets which are not Closed”和“Avg. resolution time”。
中间那个数字最要紧。它说明当前还有多少活儿没做完。
只要还没有工单被解决过，“Avg. resolution time”就是空的。一个短横线比一个零更诚实。
“Top 3 longest open tickets”卡片列出三个最老的未结案件及其年龄。这些正是再也没有人提起的那几个。
下面是三张图：“Tickets by status”、“Tickets by priority”和“Tickets by category”。
仪表盘显示的始终是当下的状态。这里不能选时间段，那是报表的事。
侧边栏里每个团队一个条目。它叫“Dashboard”，后面跟着团队名称。
每个条目只显示自己团队的工单。所以数字、分类和最老的案件按团队各不相同。
权限挂在单个仪表盘上。您可以让某个角色访问一个团队的仪表盘，而不给另一个。
没有某个仪表盘权限的人，根本看不到那个条目。一个看得见却进不去的条目只会引出问题。
打开“Reports”页面时它是空的。只有筛选框在那儿。
只有点了“Generate report”才开始计算。它要花一会儿，因为所有部分是一次算完的。
这是有意为之。一份每敲一个键就重算的报表，在大数据量上没法用。
之后上方是四个关键数字，下面是各张图。
每张图都写出自己的数字。环形图在旁边的图例里印出数量和占比；柱状图把数量印在柱子上方。
上面的筛选框是您提问的地方。您可以用“From”和“To”选时间段，还可以选团队、状态、客服人员、请求者、地点、优先级、主分类和子分类，以及工单进来的入口渠道。
如果您填了多个字段，它们会同时生效。“七月、Helpdesk 团队、High 优先级”是一个问题。
时间段按工单创建的日期算。
有一个例外。工时报表按做工作的日期算。所以六月的工单在七月做的工作，会出现在七月的报表里。
每次改动筛选之后，都要重新点一下“Generate report”。
这个页面上还有其他功能的统计。只有当那项功能打开了、并且在所选时间段里确实发生过事情时，它们才会出现。
它们的说明各在各的地方：期限在“报表里的服务级别协议指标”，评分在“评分的报表”，分派在“关于分派的报表”，工作量在工时那一块的“报表”。
如果您建过自己的字段，报表会像对待内置字段一样提供它们。
您的每一个字段都会在筛选框里得到一个筛选项，并在报表里得到一张自己的图。
这样就能回答只有贵公司才会问的问题。“有多少张工单落到哪个成本中心？”就是其中之一。
图的名称就是您字段的名称。它们不会被翻译，因为它们来自您自己的安装。
在哪里创建自己的字段，写在“自定义字段”那一节里。
在“Settings → Report Settings”里，您决定报表提供哪些字段。
这个页面有三节：“Admin”、“Agent”和“Customer”。每一节都是同一份清单，各有各的开关。
在这里关掉的字段，对那个角色来说会从筛选和导出里消失。
出厂设置下，管理员和客服人员看得到全部。客户看到的少一些，因为他们不需要客服人员、地点和优先级。
您自己的字段在同一份清单里的“Custom fields”下面。
客户可以打开和客服人员一样的报表。在里面他只看到自己的工单。
这个限制在系统里，不在筛选里。客户就算手工输入地址也绕不过去。
您在团队上放开它。开关在“Settings → Teams”里，叫“Has permission to view their own Tickets in the Dashboard and in Reports for this Team”。
出厂设置下它是关的。关着的时候，客户既找不到仪表盘，也找不到报表。
客户看到哪些列，来自报表设置里的“Customer”一节。
文件输出对他也是开放的。客户可以把自己的工单下载成 CSV、Excel 或 PDF。
筛选框下面有三个按钮：“CSV export”、“Excel export”和“PDF export”。
三者输出的都是屏幕上当前的内容，所以筛选同样生效。
Excel 文件有两个工作表。“Key figures”放各项数字，“Tickets”放单个案件。
数字和图表总是包含在内。单张工单的清单只有在您勾上“Include ticket table in export”时才会有。
勾上之后，下面会显示真实的工单数和预计的页数。
工单非常多时还会出现一条红色警告。它说明导出可能要花一会儿。
CSV 和 Excel 包含每一行。PDF 到 20 000 张工单为止，并把这一点写进文件里。
这个上限在导出之前就写在页面上。一个到成品文件里才知道的上限，来得太晚了。
PDF 是拿来转交的。它包含屏幕上那些同样的图。
每张图旁边都写着它所依据的数字和百分比占比。
它们存在的理由就在这儿。一根柱子可以看，但没法核对。
在屏幕上，鼠标指针会显示同样的数字。而在打印出来的纸上没有鼠标指针。
文件上方写着时间段和生成的日期。
工单关闭之后，您问客户这次办得怎么样。这一整块都属于 Professional。
开始之前： 有两件事必须就位，否则什么都不会发生。邮件发送必须配好。还有，“Settings → Security”里这套安装的公网地址必须正确，因为邮件里的链接是用它拼出来的。那里存的地址错了，系统照样会把调查发出去，而您的客户会落到一个不存在的页面上。
工单关闭时，请求者会收到一封带五颗星的邮件。每颗星都是一个单独的链接，点一下就是全部回答。
邮件不会立刻发出。系统在关闭之后等一小时，此后由一个后台服务每十分钟把到点的调查发出去。这一小时是有意为之：一张刚关掉又被重新打开的工单不该触发调查。
每张工单正好一次调查。就算工单之后被重新打开又再次关闭，系统也不会问第二次。
这个链接不需要客户账号，有效期 30 天。在此之前，您的客户可以改评分，点错星比恶意使用常见得多。
评语是可选的。点一颗星就已经是一次评分了；想多说几句的人可以在页面上找到一个输入框，用“Update rating”确认。
页面上只显示工单的编号和标题。描述、评论和历史都不在上面：这个链接给的是评分权，不是阅读权，它可能被转发，也可能落进共享邮箱。
从邮件点进来之后，只有页面加载完成才会写下评分。所以病毒扫描器和预览抓取不会给您的工单评分：它们会去取那个地址，但不会运行 JavaScript。对真人来说，仍然只是点一下。
回来的评分放在工单上，负责团队的客服人员和管理员能看到它。客户在那里从来看不到评分，连自己的也看不到。
并不是每张关闭的工单都会被询问。请求者没有地址的，根本不会发邮件；被合并的重复报障，以及挂在一次大规模故障下面的报障，同样不在其列，因为解决一次故障只需一次点击就会关闭所有挂着的报障，没有这个例外，每一位报障的人都会为同一份工作被问一次。
这项调查只有一个地方可以设置：“Settings → General”里的“Customer Satisfaction Score (CSAT)”卡片，上面有三个控件。它没有自己单独的设置区域。
“Send satisfaction surveys”打开发送，出厂设置下是关的。只有在您打开之后关闭的工单才会被调查，否则您全部的积压工单会一口气收到邮件。
如果您又把它关掉，已有的评分仍然可见。只是不再有新的发出去。
开关上方显示的是拼链接用的那个地址。它放在那里是给您核对的，不是给您编辑的：您在那个唯一维护它的地方改它，旁边的提示会带您过去。
中间那个开关“Per-agent evaluation”属于报表。它在那里做什么、为什么出厂设置下是关的，写在关于报表的那张卡片上。
“At most one survey per requester within”限制同一个人多久被问一次。出厂设置是 7 天：在这个窗口内报了多张工单的人，仍然只被问一次。
填 0 就是每张关闭的工单都问。对内部帮助台来说这通常太多了，因为总是同一批人在报障；而发件人各不相同的客户服务台，多半根本碰不到这个上限。
这项调查刻意做得很朴素。评分标度固定为一到五颗星，一小时的延迟和 30 天的有效期也是固定的。同一个数据库里有两套标度，报表就会把没法比较的东西平均到一起。
更多内容见这张卡片： 评分的报表
在“Reports”里，满意度有自己的一节“Customer satisfaction (CSAT)”。它和其他内容出现在同一份报表里，遵循同样的筛选：时间段、团队、分类和客服人员。
上方是五块。“Average score”是星级的平均值，“Satisfaction rate (4-5 stars)”说明满意的占多大比例，“Response rate”是有多少人回答了，“Surveys sent”统计发出去的调查数。两个比率下面都用小字写着它们所依据的分数。
“Closed without survey”是第五块。它统计从未被询问的已关闭工单，下面写着已关闭工单的总数。没有这个数字，您会把一个比率当成客户的全貌，而它其实建立在一个您看不见的子集上。
最要紧的数字不是平均分，而是回复率。建立在少量回答上的好分数，说明不了您客户的情况。
下面是分布：从五颗星到一颗星，每一档都有一根柱子显示它被打出多少次，旁边是数量。然后是“Trend”，每一个有人回答的日子一行，带日期、当天平均分的柱子和回答数。最后是“By agent”，每位客服人员一行，以及“Latest comments”，里面是人们实际写下的话。只要有一个以上的团队有被评分的工单，还会加上一张“By team”的细分。
按客服人员的细分可以关掉。“Per-agent evaluation”出厂设置下是关的，因为按人统计的评分属于绩效数据，在很多公司职工委员会对此有话语权，而在云厂商那里，这种统计往往根本关不掉。
这个开关作用在服务器上，不只是在屏幕上：关着的时候，导出里同样没有这份细分。
工单上的单条评分不受影响，团队仍然看得到。这个开关管的是跨人的统计，不是某一个案件上显示什么。
“Satisfaction”筛选把报表缩小到评分上。“Rated only”显示被评过分的工单，“Not rated”显示没被评过的，用“Score from”和“Score to”可以把一星或两星的工单都调出来。这个筛选对表格和两种导出都生效。
一次评分可以触发一条规则。在“Settings → Automation”的规则编辑器里有一个相应的条件“Satisfaction rating (CSAT)”，旁边可以选“is at most”、“is at least”、“is”或“is not”。第三个字段填星数，一到五，旁边写着数值。
常见的用法是“is at most 2”。规则上方随后会写着编辑器一起生成的那句话：“When a ticket was rated 2 stars or fewer, then send an e-mail to the assignee.”
这条规则不需要时间条件，所以“WHEN”块是空的。这让它成了规则里的例外：其他所有规则等的是某件事一段时间没有发生，而它等的是一个事件。
动作方面，规则本来能做的这里都能做：发邮件、提高优先级、把工单交给另一个团队，或者设一个跟进。
有一点在这里不一样。规则通常不碰已关闭的工单，而评分几乎总是落在已关闭的工单上，所以带这个条件的规则也能触及已关闭的工单。其他每一条规则仍然不会。
这个条件永远不会命中没有评分的工单，“is not”也一样，否则“不是五颗星”就会命中您全部没被评分的积压工单。想知道有多少人没有回答，那是报表里的回复率。
这条规则对每一次评分只动一次。它下面的“Log”打开“What this rule did”表格，每张工单一行，您可以看到它什么时候运行、做了什么。
这一部分能减少工单：解决办法写下一次，团队之后能再找到它，而且在请求者还在打字的时候就推荐给他。这一块里的一切都属于 Basic。
通过左侧栏里的“Knowledge Base”进入知识库。总览由一块块卡片组成，每个主题一块。卡片右上角的数字是已发布条目的数量，下面是主题的名称和描述。点一下卡片进入条目清单，每一条都带作者、修改日期和正文的开头几行。
主题不在这里创建，而是在“Settings → Knowledge Base”里（见“按主题设定可见性”那张卡片）。一个主题都没有的话，总览上除了一条提示什么都没有，因为条目总要有一个主题。
在主题页面上用“New entry”撰写。编辑器要三样东西：“Title”、“Topic”和“Content”。它和工单里用的是同一个编辑器，工具栏也一样：“Bold”、“Italic”、“Underline”、“Strikethrough”、“Text color”、“Highlight color”、“Bullet list”、“Numbered list”、“Quote”、“Link”和“Clear formatting”。链接的做法和工单里一样：选中文字，点“Link”，填地址，允许网址和邮件地址（http、https、mailto）。标题或主题没填时，“Save”一直是灰的，而没有正文的条目会被拒绝：光有附件不算一个条目。
图片和工单里一样通过剪贴板进来：截个图，用 Ctrl+V 粘进编辑器。正文里会出现一个像“[inline-image:1]”这样的标记；保存时系统上传图片，并把它显示在那个位置。它还会额外出现在下面的“Attachments”里，删除也在那儿。可以粘贴 PNG、JPEG 和 GIF。
附件要等条目保存之后才能加：条目页面的最下面有“Attachments”卡片和“Upload file”。允许的文件类型和大小和工单一样（每个文件最大 50 MB）。谁上传的文件谁可以再删掉，管理员可以删任何一个。
管理员随时可以撰写，客服人员则要看设置里的开关是否允许（见“审核”那张卡片）。客户只能读。管理员可以删除任何条目；作者可以删除自己那条，只要它还在等审核。
搜索框在总览页面的上方。从两个字符起就边打边搜；清空之后卡片就回来了。它搜的是标题和正文，不只是标题，图里的“separation pad”根本没出现在任何标题里，却照样找到了两条条目。
输入会被拆成词，一条条目包含的这些词越多，排得越靠前。所以它不是在搜完整的短语：“printer jam”也会找到只包含“printer”的条目，作为交换，有人用自己的说法提问时它总能找到些什么。
为了不让一整句话变成一份随机清单，命中的条目必须包含您输入的词里的至少一半。对单个搜索词来说这没什么影响；而对“Wi-Fi drops in the west wing”来说，它会把那些只共用“the”和“in”的条目筛掉。
谁能找到什么，取决于他的角色：客服人员和管理员还能看到内部主题以及仍在等审核的条目（带琥珀色标记）。客户只能找到对客户开放的主题里已发布的条目。
开始之前： 可见性挂在主题上，不挂在单个条目上。一条放在对客户开放的主题里的内部备注，一发布客户就能读到。请照此规划您的主题，必要时用“Edit”把条目移到另一个主题去。
主题在“Settings → Knowledge Base”的“Topics”卡片里维护。每一行都有名称、描述、决定卡片顺序的排序号、“Visible to customers”开关，以及保存和删除两个按钮，保存是按行来的，不是整张卡片一起。
开关关着时，只有客服人员和管理员看得到这个主题、它的条目和附件，客户连那块卡片都拿不到，通过搜索也找不到那些条目。开关打开时，客户看得到这个主题和里面已发布的条目；草稿反正是看不到的。
新主题在下面那一行虚线里创建：填名称，选可见性，点“Add topic”。只有主题是空的时候才能删除，否则您会连同看不见的条目一起删掉。
只要“Create new ticket”表单的“Title”字段里有了三个字符，系统就会在后台搜索，并显示“Possible solutions from the knowledge base”方框，里面最多五条与标题匹配的条目。在那里找到答案的人就不会再开工单，这正是它的全部意义。
搜的只有标题，不搜描述。和搜索里一样的规则在这里同样适用：一条推荐必须包含标题里至少一半的词，标题越准确，推荐就越少也越贴切。点一条推荐会在新标签页里打开它，这样填了一半的表单不会丢；下面的“Open knowledge base”通往完整的总览。
可见性在这里同样有效：客户只会被推荐对客户开放的主题里已发布的条目。作为客服人员，您还会额外看到内部主题以及仍在等审核的条目。
开始之前： 所有内容都会被带过来：描述和每一条评论，内部评论也在内。这段文字是副本，不是链接，请通读一遍，在保存之前把姓名、电话号码、电子邮件地址和订单号去掉。保存之后，凡是能看到这个主题的人都读得到。
每张工单的右上角都有“Add to knowledge base”。这个按钮打开一条新条目的编辑器，里面预填了工单的标题和它的全部经过：描述作为第一段，下面的每一条评论作为引用。
光这样还没有什么用，它只是原料。要点在于您把它变成一份指南：删到只剩下次真正用得上的内容，如果标题听起来像某一个具体案件，就把它改写一下（“Printer on 2nd floor pulls two sheets”改成“Clearing a paper jam”）。
系统不会预选主题，由您自己选。条目和其他条目一样保存：管理员保存后直接发布，客服人员保存后送去审核。之后条目上会留着内部的“Source: Ticket #1”标注，它是回到那个案件的跳转入口，客户看不到。
客服人员到底能不能撰写，由“Settings → Knowledge Base”里的“Agents can create entries”开关决定。它默认是开的。关掉之后是一道硬边界：“New entry”按钮消失，直接调用编辑器同样会被拒绝。
一共只有两种状态：“Awaiting review”和“Published”，没有那种可以悄悄写、别人看不见的草稿。谁写的决定状态：管理员立刻发布。客服人员写出来的条目带着“Awaiting review”标记，客服人员和管理员看得到，客户看不到。主题卡片上会为此出现琥珀色的“1 awaiting review”标记。
只要有条目待审核，管理员还会额外收到一封邮件。它是补充，不是必需：没有配置发信时，标记就是发现待审核条目的途径。审核在条目自己的页面上用“Approve & publish”完成；之后那里会写明是谁批的。
如果客服人员之后改动了一条已发布的条目，它会重新进入审核，改动要到下一次“Approve & publish”之后才重新对客户可见。已经在等待中的人再保存一次，不会触发第二封邮件。
在“Settings → Knowledge Base”里，“History”卡片在最下面。它列出最近 200 条事件，最新的在最上面：发生了什么、涉及哪条条目或哪个主题、谁做的、什么时候。
一共记录七种事件：条目的创建、更新、审核通过和删除，加上主题的创建、更新和删除。所以被删掉的条目不会不留痕迹地消失，那一行仍然在，哪怕条目已经没了。
一次出现两行不是错误：管理员创建条目时，那里写着“Entry created”，正上方紧跟着“Entry approved”，因为他们发布时不用绕审核这一道。客服人员那边一开始只出现“Entry created”，审核之后才出现，并带着管理员的名字。
只有能打开知识库设置页面的人才看得到这份历史，默认是管理员。它是整个知识库的一份历史，不是每条条目各有一份。
备份有一个自己的程序。它随系统一起提供，安装过程会把它配好，所以既不用买，也不用配置。这一块讲的是它保存什么、什么时候运行，以及关键时刻怎么把一切拿回来。这一整块都属于 Basic。
这个程序叫“Ticket System Backup & Restore”。它挨着工单系统，桌面上有自己的快捷方式。
有 Windows 版和 Linux 版。是同一个程序，只是分别为各自的操作系统构建。
它有五个标签页。“Restore”列出您已有的备份，“Create Backup”生成一个新的，“Schedule”管定时，“Settings”显示各个路径，“Log”显示日志。
设置已经填好了。程序第一次启动时会自己找出工单系统装在哪里。
备份文件夹在“Backup directory”下面。您可以改它，比如改到另一块磁盘上。
开始之前： 在 Windows 上注册定时任务需要管理员权限。没有的话，程序会建一个只在有人登录时才运行的任务，并且会告诉您。
安装过程会自己配好每日备份。它按服务器的时钟在 23:00 运行。
定时任务放在操作系统里。Windows 上是任务计划程序，Linux 上是 cron 服务。所以不会有一个只为备份而常驻的额外服务。
备份不需要有人登录。在一台从来没人登录的服务器上，它照样运行。
按钮下面那一行告诉您这个任务在操作系统里是否真的存在。打了勾只说明保存过什么。
备份按五个层级保留：14 天、4 周、12 个月、4 个季度和 5 年。一个备份只要在某个层级里是它那一段时间里最新的，就会被保留下来。
算的是日历天，不是文件数。同一天的两个备份算一天。
您手工创建的备份永远不会被自动删除。“Keep manual”那里的 0 就是这个意思。
如果您改了定时任务，您的改动会挺过更新。安装过程只在还没有定时任务时才去设置它。
一个备份包含构成您系统状态的一切。也就是数据库、文件附件、归档和密钥。
密钥是最容易被漏掉的那一部分。它们用来解密保存下来的凭据，比如您邮箱账号的凭据。没有它们，还原回来的就是一堆失效的凭据。
每个备份是一个 ZIP 文件。里面是作为文本文件的数据库、每个卷一个文件，以及一份校验和清单。
这期间系统照常运行。您的客服人员根本察觉不到有备份在做。
“Estimate size”会事先告诉您数据库有多大。做好的文件更小，因为它被压缩过。
什么都不会被覆盖。每个备份都是一个单独的文件，只有清理才会删掉旧的。
开始之前： 还原会覆盖今天的状态。所选备份之后产生的一切，之后就没有了。
在“Restore”标签页里选出您想要回来的那个备份。然后点“Restore”。
程序会先问一句。它说明会发生什么：今天的状态被覆盖，程序会重启各个容器。
“Wipe target volumes before restore”这个勾会先把卷清空。这样就不会留下备份当时并不存在的文件。
各个步骤显示在“Log”标签页里。您可以在那里逐条看到程序做了什么。
完整的状态会回来。工单、评论、历史、文件附件、记录的工时和知识库，都和备份当时一模一样。
之后系统又可以用了。在一套小规模的安装上，这用不了一分钟。
服务器常常没有桌面。所以同一个程序也能当命令用。
您需要的是五个命令：“backup”做备份，“list”显示已有的备份，“restore”把某个拿回来，“schedule”设定时，“config”显示设置。
它们背后是和窗口里一样的那个程序。不存在第二条做别的事情的路。
程序在“/opt/smitey/Backup”里。您用“sudo”调用它，后面加上命令。容器是以“root”运行的，所以备份也需要这些权限。
下面四个方框可以直接复制。它们覆盖了日常真正用得上的内容。
还原在这里同样会问一句。只有加上“--yes”它才会真的执行。
服务器上有一个文件可以把这些看个明白。它叫“BACKUP-RESTORE.txt”，放在“/opt/smitey”里。它把定时任务、每个命令和还原的路子按您自己的节奏再讲一遍。它用的是您在安装时选的语言。其他语言的版本在“/opt/smitey/docs”下面。
sudo /opt/smitey/Backup/TicketSystemBackup list每一行都带时间、原因、大小和文件名。和窗口里是同一份列表。
sudo /opt/smitey/Backup/TicketSystemBackup schedule --show第一行写着设定的时间。最后一行说明这个任务在操作系统里是否真的存在。如果写着“NO”，就没有任何东西会自己运行。
sudo /opt/smitey/Backup/TicketSystemBackup schedule --daily 23:00 --keep 14时间用的是服务器自己的时间。“--keep”说明保留多少个每日备份。“schedule --off”把每日备份关掉。
sudo /opt/smitey/Backup/TicketSystemBackup backup这个备份算作“Manual”。手工做的备份永远不会被自动删除。
开始之前： 放在系统旁边的备份挡不住磁盘损坏。请定期把这些文件复制到别的地方。
备份是您设定的那个文件夹里的文件。那个文件夹和工单系统在同一台机器上。
对常见的情况来说这没问题。误删的数据、失败的更新或者数据里的错误，都能覆盖到。
它挡不住磁盘坏掉。磁盘没了，备份也跟着没了。
所以请把文件复制到别处。一个网络驱动器、第二台服务器或者网络里的存储就够了。
复制出去的文件在任何地方都能加载回来。用“Import backup file…”把它重新放进列表。
更新会事先做一个自己的备份。这和您的定时任务无关，也不用您勾任何东西。
它保存的和平常一样：数据库、附件、归档和密钥。
这个备份属于更新。它放在系统旁边一个单独的文件夹里，所以不会出现在程序的列表中。
更新前的提示会告诉您这一点。您不用自己记着先做备份。
更多内容见这张卡片： 一键更新
可以直接复制。全部用 sudo，安装程序和容器都需要 root。
sudo apt install -y unzip没有 unzip，安装程序就没法解开安装包。
curl -fsSL https://files.smitey.eu/download/get-smitey.sh | sudo bash下载安装包，并带着您回答一系列问题。重复运行是安全的：配置和数据都会保留。
sudo /opt/smitey/smitey-install check-https只在有公网域名时有用。它会告诉您证书在不在，如果不在，还会给出日志里的原因。证书也可能在安装之后几分钟才到。
sudo cat /opt/smitey/SMITEY-credentials.txt首次登录之后请修改密码并删除这个文件。
sudo podman ps显示系统的每一个部分及其状态。
sudo podman logs -f container-backend-1实时显示后端报告的内容。按 Ctrl+C 停止。
systemctl status smitey-supervisor这个服务让系统持续运行，并执行您在程序内部触发的更新。
sudo /opt/smitey/install.sh --support-bundle把日志和系统状态收集到一个 zip 文件里。密码和密钥会被去掉。
sudo /opt/smitey/install.sh --reconfigure设置一个新域名并重启，好让系统为新名称申请证书。
sudo /opt/smitey/install.sh --uninstall会分别询问数据和 Podman，不问就不会删任何东西。
备份由 /opt/smitey/Backup/TicketSystemBackup 负责（list、backup、restore）；每日备份会自己运行。详细说明在 /opt/smitey/docs/en/BACKUP-RESTORE.txt 里。
返回功能对比图片取自 0.46.0 版本。