Back to Resources
STRATEGY • By The Shore Group Team

The Back-Office Work Nobody Schedules

Where automation actually pays in a community bank, and how to spot a candidate.

TL;DR

A lack of data and operational metrics is now a top technology challenge for nearly half of banks, up sharply in a single year. The work causing that is rarely the work on anyone's project list. It is the recurring, rules-based, documented jobs that have to get done and never get better, because everybody is too busy doing them to own fixing them. That category is also where the cheapest automation wins tend to be hiding, and there is a straightforward test for telling a real candidate from a bad one.

Cornerstone Advisors reported this month that a lack of data and operational metrics was a top technology challenge for 48% of banks this year, up from 27% the year before. The figure comes from the firm's annual banking research, cited in a report on core technology that was commissioned by a core provider, so take the report's conclusions about cores with the appropriate pinch of salt and keep the underlying number.

Nearly doubling in twelve months is the part worth sitting with. Institutions are not losing visibility into their own operations because nobody cares about operational data. They are losing it faster than they are fixing it, during a period when most of them have been actively investing in technology. From our experience, that gap has a fairly ordinary explanation. The work that generates operational blind spots is almost never the work that makes it onto a project list, because it is not visible enough to compete for one.

The projects that get funded, and the work that does not

Digital account opening gets a steering committee. It has a vendor, a timeline, a board update, and somebody whose name is attached to whether it succeeds.

While exception clearing gets a spreadsheet and whoever is free on Thursday. The difference between those two is not importance. An institution can survive a mediocre account opening flow for a year. It cannot survive an exception population nobody has looked at. The difference is visibility. One of them has a shape that a leadership team can see, discuss, and fund. The other is distributed across a dozen people's weeks in increments too small to name.

Work like that develops a particular immunity. It never fails loudly enough to trigger a response, so it never gets improved, so it continues to consume the same hours next quarter. It is nobody's fault and nobody's project. It is simply the water the department swims in.

Three jobs that fit the pattern

The pattern is easier to recognize with examples than with a definition. Post-close quality control is the clearest one. The review has to happen, the deadline is external, the procedure is written down, and the work scales directly with how many loans closed. Nobody has ever described QC as strategic, and nobody has ever been allowed to skip it.

Exception and break clearing is the second. Something does not match, somebody has to work out why, and the queue grows faster than it shrinks in any month where volume rises. The individual items are small. The population is not.

Document retrieval out of archive storage is the third, and it is the one most often dismissed as trivial. Somebody needs a signature card from four years ago. Somebody else needs the disclosures for a batch of accounts an examiner has asked about. Each request takes twenty minutes, each one interrupts something, and the total never appears anywhere. All three share the same four properties, and those properties are the test.

How to tell a real candidate from a bad one

  • The first property is that a written procedure already exists. If the institution can hand someone a document describing how the work is supposed to be done, the work is a candidate. If the only description lives in one person's head, the first job is writing it down, and that is a different project with a different timeline.

  • The second is that the output is a decision rather than a judgment. Checking whether a required document is present and matches the core record is a decision with a correct answer. Deciding whether a borrower's explanation of a credit event is credible is a judgment, and judgment should stay where it is.

  • The third is that the work scales with volume rather than with complexity. Doubling the number of accounts should roughly double the work. If doubling the accounts makes the work five times harder because every case is different, the pattern does not hold and automation will struggle in the same places people do.

  • The fourth is the most useful and the least technical. Somebody should be able to describe the entire job in a meeting without opening a system. If explaining it requires screen sharing and forty minutes, the job is not one job, it is several tangled together, and untangling them comes first.

✅

A job that passes all four of these is worth looking trying to automate. A job that fails the second one is usually worth leaving alone, regardless of how much time it consumes.

Where people still decide

There is a version of this conversation that ends with fewer people, and that is not the version worth having at a community institution.

Take a $610M credit union running post-close deposit review with three people. The work those three do breaks into two halves. One half is fetching, comparing, and recording. Pulling the documents, lining them up against the core extract, noticing that something is missing, and writing that down in a form somebody else can act on. The other half is deciding. Looking at a flagged item and determining whether it is a real break, a documentation gap that needs chasing, or a false alarm that should be waived with a note explaining why.

The first half is mechanical and it consumes most of the hours. The second half is where the three people's experience actually lives, and it consumes the least. The useful goal is moving the ratio, not moving the people. The reviewer is not the bottleneck. The hunting is. An institution that automates the fetching and comparing has the same three reviewers spending most of their time on the part that needed a person in the first place, which is also the part that gets rushed today when a cycle runs tight.

There is one requirement that comes with this, and it is not optional. A system doing the mechanical half has to say plainly when it could not check something. A check that cannot run because a document is missing is a finding in its own right. A tool that passes it silently has made the population look cleaner than it is, which is worse than not running the check at all.

Start with the most annoying process, not the biggest

The instinct when a leadership team finally looks at this category is to pick the largest consumer of hours and attack it. That instinct is usually wrong. The biggest job is typically the most entangled, touches the most people, and has the most exceptions to its own rules. It takes the longest to show a result, which means it is still unfinished when attention moves on, and an unfinished first attempt makes the second attempt harder to fund.

The better first candidate is the one people complain about most relative to its size. It is small enough to finish, contained enough that one department owns it end to end, and irritating enough that finishing it is noticed. A contained win that lands creates the permission to do the next one. We have made this argument before in the context of AI pilots, and it holds for operations work generally, which is why your first AI win should solve one small problem is a useful companion to this piece.

It is also worth saying that the goal of the first project is not the hours it saves. It is the measurement it creates. Most of this work is invisible precisely because nobody has ever counted it. The first automated version of a manual job produces a record of how much of it there was, which is often the first time an institution can see the size of the category it has been absorbing. That visibility is what the Cornerstone number is really describing, and it is the thing that makes the second and third projects easy to justify.

The related problem, that the data underneath these processes is frequently not trustworthy in the first place, is one we have written about separately in your operations don't have a staffing problem, they have a data problem.

Have a Problem to Solve?

Most institutions that make progress here did not start with a plan to modernize the back office. They picked one recurring job that everybody complained about, got it off people's desks, and used what they learned to choose the next one.

We handle automated QC and data quality review of exactly this kind for community banks and credit unions, running against the institution's own written procedures with its own team making the calls. If there is a job in your operation that has to get done every month and has never once gotten better, reach out to Shore Group and we can talk through whether it fits the pattern.

Frequently Asked Questions

What counts as back-office work in a community bank?

The practical definition is work that supports a product or a control without touching the member or customer directly. Post-close quality control, exception clearing, document retrieval, reconcilement, and reporting all sit here. The common thread is that the work is required, recurring, and invisible to anyone outside the department performing it.

How do you decide what to automate first?

Look for a job where a written procedure already exists, the output is a decision rather than a judgment call, the work scales with volume rather than complexity, and somebody can describe the whole thing without opening a system. Among the jobs that pass, pick the smallest one people complain about rather than the largest consumer of hours.

Does automating this kind of work mean fewer staff?

No, and at an institution of this size it rarely could. Most community banks and credit unions are running these functions with two or three people who are already stretched. The realistic outcome is the same team covering more of the population and spending a larger share of their time on the decisions that required their experience in the first place.

What does human in the loop actually mean here?

It means the system narrows and the person decides. Fetching documents, comparing them against a record, and writing down what does not match is mechanical work. Determining whether a flagged item is a genuine break, a gap to chase, or a false alarm is not, and that call should sit with a reviewer who can also record why they made it.

How long before a small automation project pays back?

That depends on the job and we would be making up a number if we gave one. The more useful early return is measurement. A first project produces a record of how much work the job actually involved, which most institutions have never had, and that record is usually what makes the case for the next one.