Most firms have solved the problem of moving work around. A job finishes one stage, the tool pushes it to the next person, the status changes, everyone can see where it sits. That part is handled.
What almost no firm has solved is moving the other thing. Not the task, but everything you know about the client that never made it into the task. Why this one deposit is always owner equity and not income. Which contact actually answers an email. The quirk in how they invoice that would take an hour to re-explain and thirty seconds to already know. That knowledge lives in one person’s head, and a workflow tool does not move it anywhere.
It stays invisible right up until the moment it matters. Someone is out sick. Someone new picks up the file. Someone is working at a different time of day, on the other side of the world, and cannot just lean over and ask. Suddenly the work stalls, not because the person could not do it, but because the context they needed was sitting in a colleague’s memory, three time zones away and fast asleep.
What is actually missing when a remote handoff goes wrong?
Picture onboarding a new client. On paper it is a clean handover: here are the logins, here is the app, here is the work. Then the real questions start, and the gaps show up fast.
How many apps are actually in the stack? The answer that starts at three often ends at nine once someone asks the right follow-up. Who is allowed to talk to the client directly? What does this client do when something unusual happens with their money, and how do they tell you? None of this is on the setup checklist, but every bit of it decides whether the work runs smoothly or grinds to a halt the first time something is not routine.
The uncomfortable realisation for a lot of firms is that they rely on proximity to paper over all of this. When everyone sat in one office, the missing context did not hurt, because you could always walk down the hall and ask. The moment the team is distributed, hybrid, or working different hours, the hallway disappears, and every gap that proximity was hiding becomes a real cost.
The fix is almost embarrassingly simple: write the client a story
Here is the practice worth stealing. Before the work starts, write a short story about each client. Not a form, not a field in a database. A story: what kind of business this is, what they actually do, what you do for them, every app in the stack, and the operating quirks that a new person would otherwise learn the hard way.
It used to be that capturing this meant sitting down and typing it all out, which is exactly why nobody did it. That excuse is gone. You can record yourself walking through the client in a few minutes, let the software transcribe it, and drop both the recording and the transcript into the client file as page one. Anyone who later touches that client, remote, new, or just covering for a day, starts from the story instead of starting from nothing.
And it is not only for firms that outsource. It is for any firm with a hybrid team, anyone hiring someone across the country, anyone bringing on a new person at all. Even if the new hire is sitting right next to you, the honest instruction is the same: read the client story first.
Why does context include the language, not just the facts?
There is a subtler gap that catches firms by surprise. A firm handed some client work to an administrative staffer who was perfectly capable, but could not interpret the questions coming back, because the questions were full of accounting-software terminology she had never been taught. The facts were all there. The shared language was not.
This is worth sitting with, because it points at a role most firms underfund. You do not need everyone touching a client to be a qualified accountant. But you do need someone who owns the client relationship without doing the books: a person who can field the back-and-forth, translate between the client and the technical team, and make sure a question lands with enough context that the person answering it actually understands what is being asked. Give that person a quick walkthrough, record it, and the terminology gap closes for good instead of resurfacing on every handoff.
Ask in real time, and tell the client why
The same context problem shows up at the other end of the relationship, with the client. The old habit is to save up a list of puzzling transactions and send it at month end, by which point the client has no memory of a payment from five weeks ago. The better habit is to ask the moment the transaction appears, inside whatever tool the client already uses, so the question reaches them while it is still fresh.
But timing is only half of it. The part most firms skip is the why. “I need this information” is a weak ask. “I need this because if we record it wrong, it affects you in this specific way, and getting it right keeps you on track for the goal we agreed” is a request a busy client will actually answer. Context flows both directions: your team needs the client’s story, and the client needs to understand why their quick answer matters. Train the client to flag the unusual the moment it happens, and train your own people to look for those answers where they already live instead of pinging a colleague who then has to go and look it up anyway.
Map the administration, not just the accounting
One more move the best firms make. Everyone talks about automating transactions and data entry. Far fewer think to look at the administrative layer, the moving of information, the chasing, the “who needs to know this” routing, that quietly eats the day. Sit down with the team and map how a piece of client information actually travels from the inbox to the right place. You will usually find you already own most of the tools to automate that routing. A few rules, a few connections, and a large slice of the manual shuffling disappears, freeing your people for the work that genuinely needs a person.
And then do the unglamorous part on a schedule. Processes written once and never revisited drift out of date as tools, clients, and responsibilities change. Someone has to own going back in, refreshing the client stories, and keeping the record of how the work actually gets done honest. It does not have to be the owner, and it should not be the most senior technical person. It just has to be someone.
The real shift: it is not where your team works, it is when
Underneath all of this is a change in what a distributed firm is really for. The first promise of the cloud was that people could work anywhere. The more useful promise turned out to be that people can work whenever they do their best work: early in the morning before the house wakes up, late at night, around school runs and a dozen other lives. A great deal of outsourced and remote accounting work gets done exactly this way, and it gets done well, because the people doing it can focus when they are able to focus.
That only works if the context travels with the file. Capture the client’s story, move the knowledge and not just the task, ask the client the right questions at the right time, and your firm stops depending on everyone being awake in the same room at the same hour. Skip it, and the first snowstorm, sick day, or time-zone gap brings the whole thing to a stop.
If it would help to have a second set of eyes on how client context moves through your firm, and where it quietly gets stuck, that is a conversation our outsourced back office accounting support team has with firms all the time. It is also the groundwork behind CAS support built for distributed teams, where getting the context right is the difference between work that flows and work that waits.
For more on building a better accounting practice, MoneyPenny hosts Beyond Numbers, a podcast of practical conversations on capacity, workflow, pricing, technology and the realities of running a firm. Watch on YouTube, or listen on Apple or Spotify.
