1. Treat the pilot as a learning boundary
Suggested workflow practice: use an exception review log after a limited workflow pilot has a named purpose, a dated scope, and a small group of intended users. A pilot can reveal useful needs, but discovery is not approval. The log gives the team a place to capture those needs without silently changing the work being tested.
Start each review by opening the agreed pilot record. It should identify the workflow being tried, the records and statuses included, the people using it, the start and review dates, and the acceptance examples already agreed. Keep this record stable. If the team changes it without recording a decision, later observations cannot show whether the original workflow was actually tested.
An exception is anything that prevents, changes, or questions the expected pilot path. It may be a missing detail, a confusing instruction, an apparent defect, a new report request, an unusual real-world case, or a request to connect another process. Capture it even when the answer seems obvious. The purpose is visibility, not bureaucracy.
Do not use the log to reopen broad system selection or to turn the pilot into a wish list. A request may be sensible for a later phase while remaining outside the present pilot.
- Name the pilot workflow and its intended outcome.
- Keep the dated scope and acceptance examples accessible.
- Set one review owner and one decision owner.
- Choose a regular review point and an urgent escalation route.
- Create one log entry per exception rather than combining unrelated requests.
2. Capture an exception before discussing a solution
Record the observation in neutral language. State what happened, who encountered it, which pilot record or step was involved, when it occurred, and what information was available at the time. Link the entry to the relevant agreed workflow step or acceptance example. A clear observation is more useful than a proposed feature name.
Separate evidence from interpretation. For example, “the coordinator could not save the job because the assigned-person field was empty” is evidence. “The system needs a new scheduling module” is an interpretation and may be premature. Preserve screenshots, messages, sample records, or a short reproduction path only when appropriate for the pilot and safe to share.
Give the exception a temporary status such as new, needs clarification, under review, decision recorded, trial change, or closed. Temporary status does not decide whether work is included. It tells the team what must happen next.
Record operational impact without inventing a business result. Describe the immediate effect: a user could not complete a step, a record was unclear, the team used a manual fallback, or the request concerns work outside the tested path. Note any temporary workaround and its owner so it does not become an invisible permanent process.
- Assign a unique log ID and date.
- Describe the observed event, not only the requested solution.
- Link it to a pilot step, record, or acceptance example.
- Attach relevant evidence or state that none is available.
- Record immediate impact and any temporary workaround.
- Mark the entry as unreviewed until a named person considers it.
3. Classify the request with four practical decisions
Use four decisions: clarification, pilot defect, pilot adjustment, or later-scope request. A clarification asks what the existing agreement means. It needs an answer from the responsible people before the team changes behaviour. A pilot defect is a reproducible failure against an agreed acceptance example. Record the evidence and route it for correction within the agreed responsibilities.
A pilot adjustment changes how an included workflow is configured, labelled, trained, or tested while preserving its agreed purpose and boundary. It should state why the adjustment still belongs to the pilot, who accepts it, and whether earlier evidence must be retested. Do not call a change an adjustment merely because it is small.
A later-scope request adds a new record type, role, integration, report, workflow branch, policy, or outcome not covered by the agreement. Keep it visible in a candidate backlog, but do not build it, promise timing, or represent it as part of the pilot unless the appropriate authority makes a new written decision.
When evidence is incomplete, choose “needs clarification” rather than guessing. When a safety, privacy, access-control, financial-control, or legal concern is raised, pause the affected pilot action and involve the person responsible for that risk. The exception log supports decisions; it does not override business controls or contractual terms.
- Does the agreed wording already answer the request?
- Can the stated acceptance example be reproduced and checked?
- Does the request add a new actor, record, branch, integration, report, or control?
- Who has authority to decide inclusion or deferral?
- What must be retested if a pilot adjustment is accepted?
- Does the exception require risk or policy review before pilot use continues?
4. Run a short, evidence-led review meeting
Review only entries ready for a decision. The facilitator reads the observation, linked pilot boundary, evidence, operational impact, and proposed classification. The group should decide the next action, not design every possible future feature. If the conversation becomes a design workshop, park that item as later scope and return to the pilot evidence.
For each entry, write one decision sentence that can be checked later. For example: “Classified as pilot defect because the agreed user can reproduce the failed save path; correction will be checked against acceptance example A3.” Or: “Classified as later scope because the request adds a supplier approval workflow not named in the pilot boundary.” Avoid vague conclusions such as “we will look into it.”
Name an owner, due or review point, and closure evidence. Closure evidence may be a clarified agreement, a successful repeat of an acceptance example, a documented workaround accepted for the pilot, or a formally deferred request. A closed entry should retain its original observation and decision; do not overwrite history to make the log look simpler.
At the end of each review, check for repeated exceptions. Repetition may indicate unclear training, an unclear status definition, missing pilot data, or a boundary that needs a formal decision. It is a prompt to investigate, not proof that a new feature is required.
- Review the agreed boundary before considering solutions.
- Read evidence and impact before discussing implementation.
- Write a testable decision sentence.
- Name the action owner and next review point.
- State the closure evidence.
- Preserve deferred requests without treating them as approved work.
5. Fictional example: a useful request that stays deferred
Fictional example: Northline Repairs is testing one pilot workflow for recording incoming repair jobs, assigning an internal coordinator, and marking the job as new, in progress, or completed. During the second week, a coordinator asks for customers to receive automatic message updates whenever a job status changes.
The review entry links the request to the status-update step. The observation says that coordinators currently send customer messages manually after checking the job record. The request does not show that the agreed internal status workflow failed. It asks for an outward communication channel, message content, consent handling, timing rules, and exception handling that the pilot did not include.
The decision owner classifies it as a later-scope request. The pilot continues with the current internal record and a documented manual communication step. The entry records the request, the reason for deferral, the person who may assess it after the pilot, and the evidence needed for a future discussion, such as examples of status changes and the intended customer communication rule.
If the coordinator instead could not see a status that the agreed workflow required them to update, the team would classify the issue differently. They would reproduce the path, compare it with the relevant acceptance example, and treat it as a possible pilot defect. The same conversation can contain both types of item; the log keeps their decisions separate.
- Label the example or scenario as fictional.
- Identify the current agreed path before judging the request.
- Separate internal workflow evidence from a new outward-facing capability.
- Record why deferral is appropriate without dismissing the request.
- Specify what future evidence would make a later review useful.
6. Close the pilot with a decision trail, not an expanded promise
Before ending the pilot, group entries by decision: clarified, corrected pilot defect, accepted pilot adjustment, deferred later scope, and unresolved. Compare the pilot only against its agreed acceptance examples and the decisions recorded during review. Do not describe unbuilt requests as delivered capability.
Prepare a concise closeout record for the owner and implementation team. It should list the final pilot boundary, the acceptance checks performed, any accepted adjustments, manual workarounds still in use, deferred requests, unresolved risks, and the person responsible for each next decision. This creates a clean starting point if a later phase is considered.
A deferred item is not lost. Keep its original context, request date, impact, and decision reason, then revisit it only when the business chooses to plan another scope. Reassess it against the then-current workflow; a request that was outside a pilot may later be appropriate, unnecessary, or differently framed.
This practice supports clearer conversations and records. It does not promise outcomes, replace a formal agreement, or decide technical, legal, security, or commercial responsibilities on behalf of the people accountable for them.
- Confirm which acceptance examples were actually checked.
- List accepted pilot adjustments separately from original scope.
- List open workarounds and their owners.
- Keep deferred items as candidates, not commitments.
- Record unresolved risks and escalation owners.
- Share the closeout record with the people who must decide the next scope.
中文指南
1. 把试点当作学习边界
建议的流程做法：当一个有限流程试点已有明确目的、带日期的范围，以及少量指定使用者时，再使用异常复核日志。试点可以发现有价值的需求，但发现不等于批准。日志让团队能记录需求，而不会悄悄改变正在验证的工作。
每次复核先打开已同意的试点记录。记录应说明正在试用的流程、包含的记录和状态、使用人员、开始及复核日期，以及已同意的验收示例。保持这份记录稳定；若团队没有记录决定就改变它，之后便无法判断原流程是否真的经过测试。
异常是指任何阻碍、改变或质疑预期试点路径的事项。它可能是缺少资料、说明不清、疑似缺陷、新报表要求、罕见的实际情况，或要求连接另一项流程。即使答案看似明显也应记录。目的在于可见性，不是增加行政负担。
不要用日志重新讨论广泛的系统选择，也不要把试点变成愿望清单。某项要求可以适合下一阶段，但仍不属于当前试点。
- 写明试点流程及其预期结果。
- 保留可查阅的带日期范围和验收示例。
- 指定一名复核负责人及一名决定负责人。
- 设定定期复核时间和紧急升级渠道。
- 每项异常单独建立日志，不把无关要求混在一起。
2. 先记录异常，再讨论解决办法
以中性语言记录观察到的情况：发生了什么、谁遇到、涉及哪一项试点记录或步骤、何时发生，以及当时有哪些资料。把条目连到相应的已同意流程步骤或验收示例。清楚的观察比功能名称更有用。
把证据与解释分开。例如，“协调员因负责人栏位为空而无法保存工作记录”是证据；“系统需要新的排程模块”是解释，而且可能过早。只在适合试点并且可安全分享时，保留截图、讯息、样本记录或简短重现步骤。
给异常一个临时状态，例如新建、需澄清、复核中、已记录决定、试行变更或已关闭。临时状态不决定工作是否包含在范围内；它说明下一步需要做什么。
记录运营影响时不要虚构业务成果。描述即时影响：使用者无法完成步骤、记录不清楚、团队使用人工替代方式，或要求涉及未测试的路径。也要写下临时替代方式及负责人，避免它无声地变成永久流程。
- 分配唯一日志编号和日期。
- 描述发生的事件，不只写要求的解决方案。
- 连接相关试点步骤、记录或验收示例。
- 附上相关证据，或注明没有证据。
- 记录即时影响和任何临时替代方式。
- 在负责人复核前，将条目标记为未复核。
3. 用四种实际决定分类要求
使用四种决定：澄清、试点缺陷、试点调整或后续范围要求。澄清是询问现有协议的意思；在团队改变做法前，应由负责人员回答。试点缺陷是相对于已同意验收示例、可以重现的失败；记录证据，并按已同意责任安排修正。
试点调整是在不改变已同意目的和边界下，改变已包含流程的设定、标签、培训或测试方式。应说明为何调整仍属于试点、谁接受，以及是否必须重新测试较早的证据。不要因为改动很小就把它称为调整。
后续范围要求新增了原协议未涵盖的记录类型、角色、整合、报表、流程分支、政策或结果。把它保留在候选待办清单，但除非有适当权限的人作出新的书面决定，否则不要开发、承诺时间，或表示它属于试点。
证据不足时，应选择“需澄清”，不要猜测。若出现安全、隐私、存取控制、财务控制或法律问题，应暂停受影响的试点动作，并让负责该风险的人参与。异常日志协助决定，不会取代业务控制或合约条款。
- 已同意的文字是否已回答这个要求？
- 所述验收示例能否重现并检查？
- 要求是否增加新角色、记录、分支、整合、报表或控制？
- 谁有权决定纳入或延后？
- 若接受试点调整，哪些内容必须重新测试？
- 异常是否需要风险或政策复核后才能继续试用？
4. 进行短而以证据为主的复核会议
只复核已经准备好作决定的条目。主持人读出观察、相关试点边界、证据、运营影响和建议分类。小组应决定下一步，而不是设计所有可能的未来功能。若讨论变成设计会议，把该事项列为后续范围，再回到试点证据。
每个条目都写一句日后可核查的决定。例如：“分类为试点缺陷，因为已同意使用者可以重现保存失败路径；修正后将以验收示例 A3 检查。”又例如：“分类为后续范围，因为要求新增试点边界未写明的供应商审批流程。”避免“我们会研究”这类模糊结论。
指定负责人、到期或下次复核点，以及结案证据。结案证据可以是已澄清的协议、成功重做验收示例、为试点接受并记录的替代方式，或正式延后的要求。关闭条目时应保留原始观察和决定，不要为了让日志简洁而覆盖历史。
每次复核结束时，检查是否有重复异常。重复可能表示培训不清、状态定义不清、试点资料缺失，或边界需要正式决定。这是调查提示，不证明一定需要新功能。
- 讨论解决方法前先复核已同意边界。
- 实施讨论前先阅读证据和影响。
- 写出可测试的决定句子。
- 指定行动负责人和下次复核点。
- 说明结案证据。
- 保留延后要求，但不把它当作已批准工作。
5. 虚构示例：有用的要求仍然延后
虚构示例：Northline Repairs 正在试用一项流程，用来记录收到的维修工作、分配内部协调员，并将工作标记为新建、处理中或已完成。第二周时，一名协调员要求每当工作状态改变，就自动向客户发送讯息。
复核条目连接到状态更新步骤。观察记录指出，协调员目前在查看工作记录后手动向客户发讯息。该要求没有显示已同意的内部状态流程失败；它要求的是对外沟通渠道、讯息内容、同意处理、时间规则和异常处理，而这些都不在试点内。
决定负责人将它分类为后续范围要求。试点继续使用当前内部记录和已记录的人工沟通步骤。条目记录该要求、延后的原因、试点后可评估它的人，以及未来讨论需要的证据，例如状态改变示例和预期的客户沟通规则。
如果协调员无法看到已同意流程要求其更新的状态，团队便会作出不同分类：重现路径，与相关验收示例比较，并把它视为可能的试点缺陷。同一次讨论可以有两类事项；日志会把它们的决定分开。
- 明确把示例或情境标记为虚构。
- 判断要求前先确认当前已同意路径。
- 把内部流程证据与新的对外能力分开。
- 记录适合延后的原因，但不否定该要求。
- 说明哪些未来证据会让后续复核更有用。
6. 用决定轨迹结束试点，而不是扩大承诺
试点结束前，按决定整理条目：已澄清、已修正的试点缺陷、已接受的试点调整、已延后的后续范围，以及未解决事项。只以已同意的验收示例和复核期间记录的决定来评估试点。不要把尚未开发的要求写成已交付能力。
为老板和实施团队准备简短的结案记录。它应列出最终试点边界、完成的验收检查、任何已接受调整、仍在使用的人工替代方式、延后要求、未解决风险，以及每项下一步决定的负责人。这会在日后考虑下一阶段时提供清楚起点。
延后项目不会消失。保留它原来的背景、要求日期、影响和决定理由；只有当业务选择规划新范围时才重新查看。它应按当时的实际流程再评估：先前不属于试点的要求，之后可能适合、不再需要，或需要重新定义。
这项做法帮助团队进行更清楚的沟通和记录。它不承诺结果，不取代正式协议，也不会代替负责任的人决定技术、法律、安全或商业责任。
- 确认实际检查过哪些验收示例。
- 把已接受试点调整与原范围分开列出。
- 列出尚未取消的替代方式及负责人。
- 把延后项目保留为候选项，而非承诺。
- 记录未解决风险和升级负责人。
- 把结案记录分享给必须决定下一范围的人。
Sources and next step
Discuss your workflow scope with BossFlow · Compare system categories at SME Systems · All articles