Every support stack has a residue: the tickets that survive the knowledge base, the chatbot, and the macro, and land on a human anyway. Look closely and the residue has a shape, issues whose diagnosis lives in the user's screen state, not in any article. These are the deflection-proof tickets, and they're exactly what screen-aware support exists to resolve.
What makes a ticket deflection-proof?
Deflection works when the answer is knowledge: documented question, documented answer, delivered faster. It fails structurally when the answer depends on state: what this account has configured, what this screen actually shows, what this user actually did. The knowledge-layer bot can only respond to the user's description of that state, and the user, confused, mid-failure, lacking the product vocabulary, is the least reliable sensor in the loop. So the conversation loops ("which page are you on?", the screenshot volley) until a human with screen access does in one glance what the text exchange couldn't do in twenty minutes.
The taxonomy of state-dependent tickets
Five families recur everywhere. Misconfigurations: the setting is wrong, the user doesn't know which one, and the article describes the happy path they think they followed. Context-dependent errors: the message means three things depending on account state the user can't see or read. User-error-in-context: the workflow is right, the execution has one wrong turn the user can't self-observe. Data-shape problems: the import fails because of what's in the file, not what the docs said about files. And multi-step drift: something went wrong three steps ago and only symptoms are visible now. Every one is trivial with eyes on the screen and nearly unsolvable through description, which is why they're your escalation queue's regulars.
What resolution looks like with eyes and hands
The agent sees the live screen with consent: the actual page, the actual config, the actual error. Diagnosis collapses from an interrogation into a glance, "your webhook is pointed at the staging URL, that's why nothing arrives", and the fix happens right there: guided, or performed with permission, narrated so the user learns, verified working before the session ends. Deflection answers the question; resolution on the user's screen finishes the job, and this ticket family is precisely where the difference stops being philosophical.
What to do with your own residue
Audit last quarter's escalations and tag the state-dependent share, most teams find it's the majority of their expensive tickets and nearly all of their long ones. That share is your screen-aware opportunity, sized in your own numbers. (Disclosure: this ticket family is what Skippr's support agent is built for, live on the user's screen, resolving or escalating with the diagnostic picture attached.)
Questions buyers actually ask
Does screen-aware support replace the knowledge-layer bot?
No, documented Q&A stays deflected at the knowledge layer. Screen-aware resolution takes over where knowledge stops: state.
What about privacy during screen sessions?
Consent, visible indicators, scoped access, and certification (SOC 2 Type II / ISO 27001) are table stakes, evaluate the permission model before the resolution rate.
How do we measure the difference?
Track resolution rate and time-to-resolution on the state-dependent tag specifically, that's where the delta lives; blended averages dilute it.
See it handle a real question
A support answer either resolves the thing or describes it. Fifteen minutes is enough to see which one you are getting.