The owner is away. Why does the whole process stop?

“Automate it” is not enough to hand to engineering.

Nexon’s public case describes connecting existing systems and approvals to reduce manual handoffs and dependence on particular staff in account-protection work. My brief is to make a request transferable: another authorized person should be able to continue from its evidence.

I would put the problem, purpose, proposed change and expected benefit on one page. Each change should address a specific delay. Beside each benefit, I would write the measure to check after release.

Observed problem

For this proposed case, assume the request and rationale are scattered. People repeat explanations and ask separately for status.

Purpose

Reduce handoff and status-checking effort while checking that incorrect account actions do not increase.

System change

Connect evidence, review, approval and execution results within one request. Reuse an existing approval system if it meets the requirements.

Expected effect

Less waiting and rework. Measure elapsed time, active handling time, review returns, incorrect actions and recovery separately.

This scope covers the handling of protection requests. A new detection policy or AI deciding whether an account is legitimate belongs in a separately validated project.

The request arrives as “automate this because work stops when the owner is away.” I ask for a recent delayed request before turning that proposed solution into a feature list. I separate the customer impact from the work the operator had to repeat.

The intake record captures the requesting role, affected task, recurrence, workaround, requested date and reason. For this example, CP-01, I keep account-detection policy outside the handoff improvement. The first deliverable connects the observed problem to a proposed change and the measure that would show whether it helped.

Find the wait before speeding up the task.

Ask operations for both completed requests and held or failed ones. Trace receipt, missing-information requests, review, approval, execution and result confirmation. Count requests as requests; several messages about one case are not several independent cases.

Suppose a request takes six hours from receipt to completion, including ten minutes of actual checking. I would investigate the other five hours and fifty minutes first. Was the team waiting for an owner, evidence or approval? Each cause calls for a different change. Where approval is the bottleneck, improve routing and waiting while keeping the required controls.

• Operations: repeated questions, absence cover and the purpose of the current manual list.
• Engineering: existing request, approval, account-state and execution records that can be connected.
• Security and privacy: policy ownership, access boundaries, retention rules and the customer’s review route.

Use business labels that operations and engineering both understand: request state, approved scope and execution result. Agree the database fields and APIs with engineering after checking the existing system.

Ready to proceed: the current flow, accountable roles, source information and unanswered questions fit into a shared working document.

I walk through a routine case, an absence-related delay and a case returned for more information. I compare the documented procedure with the screens and handoff records actually used.

At each step I ask who produces the input, where receipt is recorded, how the next person is notified, who covers an absence and where data is entered twice. Conflicting accounts become a question tied to a case and a responsible role, rather than an assumed answer.

Separate waiting time from handling time.

A long turnaround does not identify the fix. I request timestamps for intake, review start, approval, execution and result confirmation. Hands-on handling time is collected separately so a slow approval queue is not mistaken for slow execution.

The data request states the period, request types and inclusion rules. Five messages belonging to one request still count as one request. Open requests need their own age and count; looking only at closed cases hides the longest waits. I distinguish recorded causes from explanations supplied in interviews.

Before comparing options, I reconcile a sample against the source records. Missing timestamps become a collection requirement. The definition below is a request for data, not a set of measured results.

Name the work each option would remove.

I compare connecting the existing request and approval tools, building a new request interface and automating judgment and execution. For each option I list the work that disappears and the work that remains.

For CP-01, I examine integration first. A second approval inbox could create duplicate administration. If the existing tools cannot track target and evidence changes, I add the missing request-detail capability. Engineering must confirm this constraint before the scope is fixed.

The comparison also covers query cost, peak-load latency, rule maintenance and fallback work. Changing detection criteria needs its own validation and remains a separate decision.

Translate privacy requirements into screen decisions.

For each compliance question, record the rule to check and the screen decision it affects. This Korea-based case starts with processing grounds and purpose under PIPA Article 15, minimum collection under Article 16, and the safety-measures standard. Then check the service’s terms, privacy notice, retention schedule and access rules. The table links each check to its owner and design consequence.

I would propose separate requester and approver roles, then confirm the arrangement with security. Set retention by the purpose and applicable requirements of each data category. Record the decision owner and confirmation date in the access and retention tables.

“Is this privacy compliant?” is too vague for a review. I provide the displayed fields, viewing roles, purpose, storage and deletion plan so the reviewer can assess the actual design. I check whether the existing processing basis covers the proposed use.

Each review item has a question, supporting document, responsible role, dated answer and the design location it changes. A request to expose raw evidence in a list becomes a proposal for masked list entries and access-controlled detail views. The answer updates both the permission matrix and screen specification.

Retention and delegated approval follow the applicable service policy and legal review. Unresolved items name an owner and the evidence needed, so implementation does not silently decide them.

Start with what lets a request change state.

The proposed main flow is Missing information → Review → Approval → Ready to execute → Confirm result → Complete. Rejection, cancellation and renewed review are separate branches. “Complete” means the observed result matches the approved action, not merely that someone clicked a button.

Sketch one request-detail screen first. Put state, responsible role and last update at the top; reason and evidence in the body; currently available actions below. Show when evidence was checked and which policy version applies. Enforce state and permission checks on the server as well as in the interface.

Keep the targets and evidence seen at approval so they can be compared with the request just before execution. I call that bundle a review snapshot. Agree storage, request identity and result lookup with engineering; ask the policy owner how long the evidence remains valid.

Follow one hypothetical request.

Operations submits protection requests for accounts A and B. A reviewer checks the evidence and targets; an approver authorizes those two accounts. Before execution, operations adds account C. I would replace the old approval status with a visible comparison: 2 approved targets / 3 proposed targets, then return the request to review. A similar-looking reason for C does not extend the old approval.

After the revised scope is reviewed and approved, execution loses its response. Operations first queries the result for A, B and C through the capability agreed with engineering. Successful targets are skipped. Only confirmed unprocessed targets follow the defined retry procedure. Customer support uses these confirmed outcomes too.

Change the approval and target-change conditions in the side-panel demo to see when execution is available. On mobile, open the demo below.

A state table defines who can perform an action with which evidence and what changes afterward. I start with the normal path, then add missing information, rejection, post-approval changes, duplicate clicks, lost responses and partial success.

For each transition I specify permissions, checks and the record left behind. Approval attaches to a version of the targets and action. Before execution, the current request is compared with that approved version. A change routes the request back to review; the interface and server must apply the same rule.

Design the request another person can pick up.

I specify one request-detail screen first. Its header shows the request, state, owner role and last update. The main area shows targets, reason, evidence and the approved version. Available actions and history sit below. Links to other systems include a clear return path.

For each button I record visibility by role and state, preconditions, in-progress behavior and success or error feedback. A hidden button is separate from server-side authorization.

The example below approves targets A and B, then adds C. It shows approved and current targets together, highlights the difference and requires review again. A lost execution response leads to result lookup rather than an immediate retry.

Ask AI to organize the decision, then inspect its assumptions.

I ask AI to organize the workflow and identify missing conditions. Then I compare its draft with the source and take open decisions to operations, engineering and security. The time saved on organizing the document goes into checking exceptions and execution conditions.

Prepare the public case and sample requests, remove customer information, and separate the current workflow, agreed rules and open questions. Here is the request I would use for this issue.

Issue: account-protection requests stop when a particular owner is absent.
Separate confirmed information from assumptions.
Set out the observed problem, purpose, proposed change and expected effect.
For evidence collection, review, approval, execution and result confirmation,
state who can advance the request and under which conditions.
Include changes after approval, lost responses, duplicate execution and partial success.
Use plain business terms; do not invent database fields or API names.
For unknowns, name the responsible role and the information needed.
Separate existing work that disappears from work that remains.

If the answer says “execute automatically after approval,” I check what happens if the targets changed. If it claims 99% success, I ask for the denominator, definition of failure and measurement. Remove the number when there is no evidence.

Operations checks exceptions, engineering checks actual system states, and security/privacy reviews access and data scope. Feed agreed changes back into the same requirements. The AI draft and the meeting notes must not become two competing policies.

I give AI the organized D01–D07 inputs and ask for contradictions and missing exceptions, then separate the work into states, screen behavior and test candidates. The input version travels with the task.

The review record keeps the reason for an edit. “Execute after approval” overlooks a changed target list. “Retry on failure” overlooks a completed action whose response was lost. The entries below are review examples, not a transcript of a new model run.

Proposed database or API names are checked with engineering. Until then, the working document uses confirmed business terms and leaves implementation mapping to the technical review.

1 · Align vocabulary and scope

Work only on CP-01 from evidence checks to the approval request.
A node is one box; the node title names it; its description states the check; the branch label belongs on the connecting line.
Separate evidence availability from approval status.
First describe your understanding of the start, checks, actions and next step. Do not change the screen yet.

2 · Apply one reviewed segment

Apply the agreed evidence-check segment and leave the post-approval flow unchanged.
Give each node a title and description, label each branch and merge paths only when their outcomes match.
Align node dimensions, spacing and starting positions; route lines clear of boxes and labels.
Verify the rendered start, branches, merges and next-stage connection after editing.

3 · Challenge the missing behavior

Why does every lookup failure end the process?
Separate cases that can continue with verified information from cases blocked by missing essential evidence.
For each case specify the displayed message, next responsible role and recorded event.
Update the specification and affected tests with the agreed rules.

Hand over decisions and open questions together.

A meeting note must say what was decided, why, for which scope, and what remains open. Each open question needs an owner role and target date. Rejected alternatives also keep their reasons so the next meeting does not restart the same debate.

I connect each requirement to its screen behavior and verification. R-03 requires the version difference in D07 and the old-approval block in T-03. Editing only one document leaves contradictory instructions.

Engineering estimates and constraints inform priority. Scope removed from a release is removed from its screens and communications too. Later exceptions update the decision record and every affected requirement, policy and test.

One successful click does not cover the workflow.

Before escalating an issue, record the account and request states, permissions, steps, expected result and actual result. For a screen issue, include device, OS, browser and version. Other teams should not all have to rediscover the conditions behind “it does not work.”

Record a result for each acceptance check above. If a later project changes detection rules, keep rule-development data separate from validation data. A rule changed during validation needs checking on fresh data.

Keep measurement units explicit: request time per request, incorrect account action per account. Multiple messages in one case are not independent successes. Any incorrect action needs a cause and recoverability review.

I test role and state combinations, not just one successful path. T-03 starts with v1 approval for A and B, adds C and requests execution under the earlier approval. The expected result is a return to review and blocked execution.

For a defect I record device, OS and browser versions, role, request state, input, reproduction steps, expected and observed results, time and evidence location. An intermittent issue keeps its attempt count and conditions. Observations and possible causes stay separate.

After a fix I repeat the original conditions and related paths: unchanged approval, rejection and resubmission. A test becomes passed only when an observed result and evidence support it.

Name the manual work that can finally stop.

Operations, engineering and security review the same state table and test evidence. Unresolved data scope, authority, result confirmation or recovery blocks deployment of that part. Begin with a limited operating scope and reconcile outcomes with existing records.

A temporary comparison period is useful; permanent duplicate work is not the goal. Define when the manual handoff list will stop and how to revert if the new flow fails. Reject an additional approval inbox if the existing tool can meet the conditions. Fully automated account judgment stays outside this project because a wrong action has a greater impact than ordinary waiting.

• Improvement: compare median and 95th-percentile elapsed time plus active handling time for equivalent request types.
• Side effects: track review returns, missing information, incorrect actions and recoveries, with counts, rates, total volume and observation period.
• Work removed: check whether status questions, copying and duplicate manual entry actually decline.

I would call the work complete when another authorized person can continue from the evidence, actions outside the approval are blocked, and results and recovery history are visible in the same request. After release, use the measures above to check whether waiting and repeated follow-ups decline.

Handoff: the one-page proposal; current and proposed flow; data and permission review; states and screens; QA criteria; release, recovery and measurement plan. Each document should remove a question the next person would otherwise have to ask again.

The release record contains the version, scope, prerequisites, sequence, checking roles, stop conditions and recovery steps. Operations also needs to know which old task ends and when. A comparison period without an exit condition leaves duplicate manual work in place.

Restoring the old interface does not undo account actions already applied. Recovery starts by checking actual target outcomes; reversing an account action follows its own authorization and procedure.

I begin with a limited operational scope and expand after review. Access by role, handoffs, version comparison, result lookup and operational acceptance are recorded. A major control defect stops expansion.

Leave a decision trail another person can use.

The output is more than a folder of documents. It connects the initial problem, evidence, choice, consultations, screen rules and verification. A new owner should be able to tell what can change and what needs another review.

I compare the same request types using D03 definitions. Alongside turnaround, I check repeated enquiries, manual work, incorrect actions and recovery effort. Changes in volume, request mix or observation period belong in the interpretation.

If the desired change is absent, I return to the remaining wait: incomplete evidence, private-message handoffs or approval queues. The next issue carries that bottleneck and the information still needed.

References

The starting point is Nexon’s account-security workflow article (December 1, 2023). This article sets out how I would plan that work; the demo and A/B/C requests are illustrative examples.

Legal references checked September 24, 2026: Korea’s PIPA Articles 15–16 and the safety-measures standard. Apply them to the service’s actual processing purpose, data and permissions during review. Official provisions · Safety-measures standard

The Korean, English and Chinese editions describe the same proposal under Korean rules.