Existing systems

Adding case automation on top of Zoho Desk, Salesforce or ServiceNow: what stays and what changes

Your case system is not the problem. What happens between it and five other systems is.

In short

An Indian bank with a case backlog does not need to replace Zoho Desk, Salesforce, ServiceNow or Zendesk. The ticketing system is holding the record correctly. The backlog is in the work that happens between it and five other systems.

An operating layer sits on top: it reads from your existing systems, assembles what a decision needs, drafts the response, and writes the outcome back. In one deployment that cut analyst hours per case by roughly 75%.

The ticketing system is not what is broken

Ask an operations head what their case system does badly and the answer is usually nothing in particular. Whether it is Zoho Desk, Salesforce, ServiceNow or Zendesk, it holds the case, tracks the status, assigns the owner and produces the report.

Then ask why the backlog exists and the answer is somewhere else entirely. The analyst opened the ticket, then spent forty minutes in four other systems collecting what they needed to act on it.

The ticket was never the bottleneck. The ticket is where the bottleneck is recorded.

Patched is not trying to rip out a bank's existing tools.

Rohan Sood, CEO, Patched

What stays exactly where it is

  • The system of record. Cases, statuses, ownership and history stay in your case system.
  • Your routing and SLA rules. Whatever your platform already enforces continues to enforce it.
  • Reporting and dashboards. Existing MIS keeps working, and gains categorised outcomes to report.
  • User access and permissions. Analysts log into the same place they logged into last week.
  • Your approval thresholds. The bank keeps the rules, the data sources, the exception categories and the thresholds.

Nothing on that list is worth the disruption of replacing, and any vendor asking you to replace it is solving their problem rather than yours.

What actually changes

The change happens in the gap between the ticket opening and the analyst being able to act.

Today that gap is five systems: the core banking portal, the bank's API, the data lake, the internal service desk and the email inbox. The analyst crosses it manually, on every case.

With an operating layer underneath, the evidence is assembled before the case reaches a person. The transaction history, the account status, the KYC records and the prior contact history arrive attached to the ticket.

The analyst reviews a prepared recommendation and decides. That is a different job from searching, and it is the one their experience is worth paying for.

The before and after, in one row each

Source: CaseLEA operating documentation, 2026.
StageTodayWith an operating layer
Ticket opensAnalyst reads and starts searchingEvidence already attached
EvidenceFive systems, manuallyRetrieved read-only, assembled once
ResponseWritten from scratch in the required formatDrafted, awaiting review
DecisionAnalyst decides after retrievingAnalyst decides, with time to think
RecordUpdated by hand, inconsistentlyWritten back with what was checked and skipped

The measured effect

~75%fewer analyst hours per case
50-60%of cases handled end to end
3 daysto under 1 hour response
98%+audit trail completeness

Figures from one Indian banking deployment, 2026.

The remaining cases still involve a person, but the work per transaction drops from about two minutes of manual handling to under a minute.

That second band is where your senior analysts sit, and speeding them up is worth as much as removing the routine cases entirely.

Six integration questions worth asking

  1. Read or write? Evidence retrieval should be read-only. Writing back should be limited to the outcome and the record.
  2. Where does data rest? CaseLEA stores no transaction or user data on its server, and data is accessed read-only.
  3. What happens if an integration is down? The correct answer is a categorised exception, not a silent failure.
  4. Who maintains the connection when the source changes? If the answer is your team, you have bought a project.
  5. Does it respect existing permissions? An operating layer should never see more than the analyst it works for.
  6. What does the write-back contain? Inputs, checks, decisions, timestamps, outputs and exception reasons.

Why this is the cheaper path

Replacing a case system in a bank is a multi-quarter programme involving migration, retraining, revalidation and a period where two systems run in parallel.

Adding a layer that reads from what you have is scoped in weeks. A CaseLEA pilot typically runs two to four weeks, including time on site, against one high-volume workflow with a baseline the bank defines.

The comparison worth making is not which case system is better. It is how much of your analysts' week is spent outside whichever one you already own - and that number is usually the whole business case.

What your platform team will ask

The conversation with a bank's platform team goes better when the answers are ready, because the objections are predictable and reasonable.

Source: CaseLEA deployment architecture documentation, 2026.
QuestionThe answer that ends the discussion
Are you writing to our system of record?Only the outcome and the record, never the case structure
What happens to our SLA rules?They keep running, because the case stays where it is
Who owns the integration credentials?The bank, scoped read-only, revocable without a support ticket
What if we migrate platforms later?The layer reads from sources, so a platform change is a connector change
Where does the data go?Nowhere. Read-only access, nothing stored on our server

The migration argument nobody makes out loud

There is an uncomfortable reason platform replacements get proposed for backlog problems, and it is worth saying plainly.

A replacement is a project with a budget, a plan and a visible finish. Fixing the seams between systems is continuous work with no ribbon to cut, so it is harder to fund even when it is obviously the cheaper answer.

The test is simple. If a perfect new case system arrived tomorrow, fully configured, would your analysts still open five other systems per case? If yes, the migration was never going to fix the backlog.

Sources

  • Patched data points, 2026: five systems per case, roughly 75% analyst hours, 50 to 60% end to end, 98%+ audit accuracy.
  • CaseLEA deployment architecture documentation, 2026: read-only access, no transaction or user data stored.
  • caselea.com, 2026: 2 to 4 week pilot with a defined baseline.

About CaseLEA

CaseLEA is a managed post-complaint operations service for Indian banks. It works NCRP and I4C complaints, LEA notices and court orders, customer and merchant email, money restoration and grievance redressal as case management on top of the systems a bank already runs, with human review for uncertain cases and a full audit trail. CaseLEA is built by Patched, a Y Combinator-backed company, and runs RBI SAR compliant and SOC 2 certified in the Mumbai region.

32k+complaints closed
95%backlog reduction
3.4xoperational ROI

Production outcomes at a leading Indian payments bank.

Next