# Care coordinator workload: count the minutes spent catching up before each contact A large part of care coordinator workload is catching up: reading through WhatsApp and the inbox before each contact. To size it, multiply the clients a coordinator carries by the touchpoints each gets in a week, then by the minutes spent catching up before each one. The result is the hours a week a system could hand back to them. Date: 2026-10-20 Reading time: 4 min Author: OCTYN No. 11 Before a coordinator rings a client, there is a stretch of reading that appears on nobody's calendar. It starts with the WhatsApp thread, scrolled back to wherever it last made sense, then moves to the inbox and to whatever got typed into the CRM after the previous call, if anything did. Then the phone gets picked up. Workload reports fold all of that into the contact itself, so a caseload gets described as a number of conversations and the catching up between them never shows. ## What the posting is asking for Pull up a care coordinator posting and read only the duties. The same phrases turn up from one company to the next: "maintain records of", "track interactions", "follow up across", "keep notes on each". Postings for case managers, patient navigators and intake coordinators tend to carry them as well, since the job underneath is the same one. Nearly every line is an instruction to put a client back together from pieces, and the posting often says where the pieces are kept, in a list of channels that runs long: WhatsApp, email, phone, SMS, an app, a spreadsheet and a CRM. Read that way, a posting is a candid document. The company has looked at its own operation and decided that client context needs a person whose whole job is reassembling it, which is a decision with a salary attached. That decision is usually right. Somebody has to notice that a client went quiet after the last session, or that the plan agreed on a call never happened, and noticing takes a person who knows the client. What that person does not need is to spend the start of every contact finding out what they already knew last week. ## The sum, using your own numbers The arithmetic has three inputs, and every one comes out of your own operation. Start with the clients one coordinator carries. Multiply by the touchpoints each client gets in a week, across every channel, counting the two line WhatsApp reply as well as the booked call. Then multiply by the minutes spent catching up before each touchpoint. What comes out is hours a week, per coordinator, spent rebuilding context. There are no example numbers in this post, and the figure at the top leaves the boxes as words. A borrowed caseload produces a borrowed total, and the only version worth anything is the one built from your own week. Two of the inputs are easy to find. The client count lives in the CRM or on somebody's sheet, and the touchpoints can be counted off the calendar and the message history for one ordinary week. The minutes are harder, because catching up rarely feels like a task while it is happening. It feels like getting ready. To get the minutes, have each coordinator write down two times for every contact across that week: the moment they first opened anything about the client, and the moment the contact began. The gap is the number. Measured this way, the total usually comes out larger than the people doing the work expected. Count the small touchpoints as well. A message confirming Thursday still sends somebody back up the thread to check what Thursday was for. Asking in the team chat whether anyone has spoken to this client lately counts too, and so does opening the spreadsheet to see which session they reached. Writing the note after the contact is a real cost, but it belongs in a different sum. A week of those times is a [baseline measurement](/glossary/baseline-measurement), dated and kept in your own records, and it gets used later. Whatever system claims to have handed hours back should be held against the number from before it existed. [The page on what a system gives back](/what-it-costs) runs the same three inputs and carries the result through to hours and money. ## Where the hours go once they come back Most software sold into an operation like this is sold on needing fewer people. Read the sum that way and the hours become a fraction of a salary, with the coordinator as the line that goes. OCTYN reads it the other way round. The hours belong to the coordinator, and the time with clients is the part of the job that needs a human, which at the moment gets whatever is left after the reading. In practice, giving them back means the context is already assembled when the coordinator opens a client: every WhatsApp message, email and call note in one record, each with its date, written in from whichever channel it arrived through. The minutes before each contact shrink. What they turn into is up to the coordinator, perhaps a longer call with the client who is slipping, or the follow up that has been moved to Friday more than once. OCTYN had the same problem in its own work. The context of more than twenty codebases had to be rebuilt every morning, and the planning now runs on a [Company Brain](/systems/company-brain): one memory that keeps each project's material apart and shows where every answer came from. Running it taught one lesson that carries straight over to a caseload, about which failure costs the most. A thin answer costs little, since someone asks again with a pointer. A blended one, two projects merged into a single confident reply, stays invisible until somebody acts on it. On a caseload that is two clients folded into one summary, so whatever assembles the record has to show the coordinator where every line came from. Why a CRM on its own does not settle this, even when everyone fills it in, is covered in the other [client context](/blog/topic/client-context) posts. Run the sum on one ordinary week before deciding anything else. If the total comes out small, leave the operation alone and let the coordinator keep the reading, which will at least have been counted once. ## Related **Systems this bears on** - [Company Brain](https://octyn.co/systems/company-brain) **Case studies cited** - [Brain](https://octyn.co/casestudies/octyn-brain) **Terms used here** - [Baseline measurement](https://octyn.co/glossary/baseline-measurement) **The longer argument** - [Doing it by hand, or building a system](https://octyn.co/compare/doing-it-by-hand-vs-a-system) **Read next** - [How to hand off a client without losing context starts before anyone resigns](https://octyn.co/blog/how-to-hand-off-a-client-without-losing-context-starts-before-anyone-resigns) - [A company knowledge base that answers questions, and the answer it must never give](https://octyn.co/blog/a-company-knowledge-base-that-answers-questions-and-the-answer-it-must-never-giv) - [Why a CRM does not fix client context, even when everyone fills it in](https://octyn.co/blog/why-a-crm-does-not-fix-client-context-even-when-everyone-fills-it-in) - [How to stop rebuilding client context before every call](https://octyn.co/blog/how-to-stop-rebuilding-client-context-before-every-call) More on client context: [Client context](https://octyn.co/blog/topic/client-context) Canonical: https://octyn.co/blog/care-coordinator-workload-count-the-minutes-spent-catching-up-before-each-contac