The Troubleshooting Ladder base skill applied to an application with no playbook of its own
— nine stages ending in a vendor package complete enough that the vendor can act.
1. History first. Past tickets for this app at this client: LOB apps repeat and the prior
ticket often holds the local fix. Check the knowledge base.
2. Documentation second: vendor and support contract, server and database location, config
notes, where vendor-portal credentials live (location only, never the credential),
runbooks. Missing LOB documentation is its own follow-up.
3. Identify the software precisely: vendor, product, exact version and build (Help → About),
server and client components with both versions, the database beneath. Client/server
mismatch after a partial update is a top LOB failure — compare them now.
4. Scope and change correlation. One user or all, one workstation or everywhere? What
changed — an app update, Windows patches, an AV or EDR rollout, server maintenance,
licensing? LOB apps are usually broken BY their environment.
5. Get the log and error: the error verbatim, the app's own log (vendor docs say where), the
Windows Application log at failure. Never work from "it errors out".
6. Known-issue search: the exact error string plus product and version on the web, and the
vendor's support site. Their KB and release notes outrank forum folklore; never pass one
off as vendor guidance.
7. Branch on what the desk can own.
a. Environment-side, yours: connectivity to the app server or database, share and folder
permissions, security-agent interference (check quarantine and exclusions against the
vendor's published list; exclusion changes go to the security-policy owner), and
workstation repair per vendor procedure.
b. Application-side, theirs: defects, database corruption, licensing, upgrades. Never
operate on an LOB database or files outside the vendor's documented procedures: it
risks the client's data and their support. Go to 8.
c. Update-correlated: follow the vendor's rollback guidance, and never improvise a
rollback of an app that owns a database. If a Windows patch broke it, the interim is
the vendor's compatibility fix; only they ship the real one.
8. Vendor-escalation package, the framework's real product. Send a case they can act on at
once: client and server versions, OS versions, verbatim error, app-log excerpt at
failure, scope (who, how many, since when), change correlation, what you tried and what
happened, business impact, contract identifiers. Open it through the entitled channel,
capture the case number, set a follow-up.
9. Verify and note. The user runs the actual failing workflow, not just app-opens. Note it
(PSA Note Discipline base skill): app and version, scope, change correlation, error,
branch, findings, case number, verification.
Magic Library