Why do people keep working around the agent?

Follow eligible work past the login

Rina has received and opened case OB-17. Its region setting differs from the requirement, so she needs to check the evidence, hold the case, and find the person who can resolve the disagreement. The two sketches below compare what she could do with an isolated answer and a proposed case record. Neither design has been tested with operators.

Follow Rina's work before counting logins or prompts. Did she receive the case in a place she could use? Could she check the answer, correct it, or leave the work safely held? Who received her question? Those checks locate the obstacle between receiving an answer and being able to act on it.

Customer activation comes later. For a trial, the owner must define the first task the service is meant to help a customer complete and the evidence a separate reviewer will check. An account or login is an earlier event. Count customers whose accounts, configurations, and required sponsors fit that job; track excluded and abandoned requests separately, and don't count repeated attempts as new cases.

The immediate design question here is whether Rina can handle the region-setting disagreement. Completing that step would not establish customer activation or business benefit. Those need their own observations over an agreed period.

Compare what the operator can inspect

Case: OB-17
Answer: Account looks ready. Send the welcome message.
Sources: Not shown
Case status: Not shown
Correction: Send another chat message
Next owner: Not shown
Support handoff: Copy the conversation elsewhere

Rina can't tell which configuration the answer used or whether it has changed. Another chat message might produce another answer without updating the case. To keep working, she has to find the source and copy the conversation into the case system, creating another record to maintain.

Case: OB-17 | Assigned operator: Rina
Status: Blocked, configuration review required
Prepared result: Draft first-task checklist, revision 2
Evidence: Requirements R-3; permitted configuration C-8
Unresolved item: Region setting differs from R-3
Correction: Edit the draft; retain revision and reason
Permitted actions: Hold, reject, ask owner, resume review
Configuration decision owner: Priya
Service support owner: Sam
Completion condition: Customer completes the first task; Leo independently accepts it
Current outcome: Not accepted; first use has not occurred

Sketch B gives Rina the source references and a visible reason the case is blocked. She can correct the draft or ask Priya about the configuration. Sam handles a service failure; Leo checks the completed first task. Until that happens, the case stays unaccepted.

Building Sketch B would still require permission checks on source links, saved correction history, and current evidence when work resumes. The model cannot grant access, change the region rule, or declare the customer's task complete. Those duties stay with the software and authorized people.

Treat the existing tool as a starting hypothesis

I'd put Sketch B beside Rina's current checklist. Which searches, copies, and status updates disappear? Which new ones arrive? Her usual case system is a sensible place to try the change, but test it with representative users and cases before claiming it makes the work easier.

The existing tool may bury questions in comments, lose correction history, or expose a source to the wrong person. Embedding the agent there could keep those problems. A separate review page may work better if it remains connected to the case, evidence, status, and next owner. Compare the work each design requires.

In a rehearsal, ask an operator to find the case, check a source, correct an error, reject a proposal, and resume after an interruption. Bring in the person who receives the handoff too. Watch where they stop. A successful rehearsal would support that design on those cases; sustained use and business benefit need later evidence.

Turn one friction into owned work

For OB-17, invite Rina, workflow owner Leo, service owner Sam, and configuration owner Priya to a short session. Bring the conflicting region setting and requirement. Work out which source applies and what Rina needs to see while Priya resolves it.

Record Priya's source decision where the team keeps approved decisions, put the interface change through the normal backlog and release review, and send service failures to support. The dates above are proposed teaching commitments, not a record of a meeting or trial.

For this change, measure whether Rina can correct or hold a case, how long it waits, and how much she still copies. Later, check completed first tasks, independent acceptance, support work, and cost. Agree what counts before testing and keep the difficult cases in the results.

Respond to the cause you can support

Match the response to the problem you saw. Ask the access owner about a failed login, the source owner about missing evidence, and the product team about a lost correction. Check wrong recommendations against test cases. If reviews are piling up, check staffing and intake. Training helps people learn a working path; it won't repair a missing one.

Take one case to the person who can fix the first obstacle. Agree a change to try and a date to review it. Keep the current checklist available. If access, sources, or support aren't ready, narrow or delay the trial instead of asking operators to work around the gaps.