The automation everyone gives up on

Most back-office automation projects stall on the same wall: the system that actually needs automating - an old ERP module, a vendor portal, an internal tool built a decade ago and never touched since - has no API, no export function, and no vendor left to ask for one. The usual answer is "we'll do it manually" or "we'll budget for a replacement system," both of which mean the workflow stays manual indefinitely.

Computer use changes that calculus. It's a capability that lets Claude operate a computer the way a person does: take a screenshot, decide where to click or what to type based on what's actually on screen, act, and repeat. The absence of an API stops being the blocker, because Claude isn't calling one - it's using the interface directly, the same way the employee doing this manually today does.

Computer use is not the first tool to reach for. If a system has a real API, an integration is faster, cheaper per run, and more reliable. Computer use earns its place specifically in the gap - the legacy tool, the no-API vendor portal, the one screen a partial integration doesn't cover.

Where this actually pays off in a back office

Legacy desktop software

An on-premise ERP, an accounting tool with no modern integration layer, or an industry-specific system whose vendor stopped building APIs years ago.

Vendor portals with no API

Supplier ordering portals, government filing sites, and benefits-administration tools that were built for a human in a browser and nothing else.

Cross-system data reconciliation

Manually copying data between two systems that don't talk to each other - a task that's tedious specifically because both interfaces exist but neither integrates with the other.

The gap in a partial integration

A system with an API that covers 80% of a workflow, where computer use handles the remaining screen the API was never extended to reach - instead of rebuilding the whole flow.

Have a back-office workflow stuck behind a system with no API? Talk to us about scoping a computer-use automation against the actual screens involved.

Why this needs more caution than an API integration

An API call either succeeds or returns a clear error. Screen operation is inherently less predictable - a layout change, a slow-loading page, or an unexpected popup can throw off a screen-reading agent in ways an API contract never would. That's not a reason to avoid computer use; it's a reason to design it the way you'd design any agent with real-world consequences: run it against a staging environment first, and put any action with a lasting effect - submitting a form, confirming a transaction, deleting a record - behind a human approval step until the workflow has a genuine track record of getting it right.

A realistic first automation

The workflows that succeed first aren't the highest-value ones - they're the ones with the clearest success criteria and the lowest cost if something goes wrong. A recurring, read-heavy task (checking a status, pulling a report, reconciling two lists) is a better starting point than a write-heavy one (submitting orders, processing payments). Prove the pattern works reliably on something reversible, then extend it to workflows with real consequences once you trust it.

Key takeaways

  • Computer use lets Claude operate software directly - screenshot, click, type - for systems with no usable API.
  • Reach for an API integration first whenever one exists and covers the workflow; computer use is for the specific gap where no API does.
  • Screen operation is less predictable than an API call - design it with human approval gates on any consequential action, and test against staging first.
  • Start with a read-heavy, reversible workflow to prove the pattern before extending it to anything with real financial or data consequences.
Every legacy system's screens and failure modes differ - this is a general framework, not a guarantee it fits your specific tool. Scoping against the actual interface is the right first step.