Setting a communication cadence and keeping it

The account that interrupts constantly is usually not staffed by unreasonable people. It is staffed by people who do not know when they will next hear from you and cannot afford to wait and find out.

Test this before changing anything. Take the last twenty unscheduled client messages and sort them into three piles: things that would have been answered by the next scheduled contact, things that were genuinely time-sensitive, and things that were chasing something already promised.

In most accounts the first pile is the largest by some distance, and the third is bigger than anyone expects. Both are cadence failures rather than client behaviour. The first means the scheduled contact is too infrequent or does not carry the right content. The third means something was committed to without a date.

The second pile is the only one that a cadence cannot fix, and it is usually small. Sizing it honestly matters, because most communication policies are designed around the second pile and then break under the weight of the first.

A cadence that lives in somebody's head does not survive a busy month. Commit only to things that a system can hold for you.

Response targets are the clearest example. In Jira Service Management, an SLA calendar sets the working days and time slots against which a goal is measured, defaulting to nine to five and configurable down to a lunch break and public holidays. That is the difference between promising a four-hour response and promising a four-hour response during working hours, and the second is the one you can actually keep.

The same tooling decides when the clock stops. You set the conditions on which a goal starts counting, finishes counting and pauses, and the pause condition is the one that matters for client work: when a request is waiting on the client, your clock should not be running. Configure it, then say so in plain words, because a client who does not know the clock pauses will read a slow resolution as your delay.

Reporting is the second example. Looker Studio can schedule a report to be delivered as a PDF on a fixed cadence to a set list of recipients, which converts a promise into a calendar entry that runs whether or not anyone remembers.

The pattern is the same in both cases. Do not promise a behaviour. Promise an artifact that arrives on a date.

Most published cadence advice produces a matrix with a weekly, a fortnightly, a monthly and a quarterly touchpoint per stakeholder type. Nobody runs it. Design for three.

The first tier is the operational channel, used daily, for questions and small requests. It should be one channel, and it should be the one the client already lives in rather than the one you prefer.

The second is a standing call. Once a week or once a fortnight depending on the size of the account, with a fixed agenda and a hard stop. Its job is to prevent things from accumulating, not to review status.

The third is the periodic review, monthly or quarterly, where the report is discussed and decisions get made. This is the one that gets cancelled first and should be cancelled last.

Atlassian's stakeholder communications play runs the mapping exercise that decides who belongs in which tier, and the useful discipline it enforces is naming the decision each audience makes with the information. A stakeholder who makes no decision from a given update does not need to be in that tier.

The formats are not interchangeable and choosing wrongly costs real time. A RAG dashboard reads fast and hides how close amber sits to red; a written narrative carries reasoning and takes real effort to produce. The trade-offs are in status report formats, compared.

Every account eventually develops an implicit definition of urgent, and if you do not write one down the client writes it for you.

A workable definition has two parts: a description of what qualifies, and the specific thing that happens when it does. Money is being spent incorrectly, data is not being collected, or something client-facing is broken. Those three cover most of what genuinely cannot wait in marketing operations.

The second part is where policies fail. If the urgent channel is the same as the normal channel, urgency is signalled by tone, and tone escalates. Give urgency its own route and make it slightly effortful. Not obstructive, effortful. A short form or a specific subject line is enough, because it makes the sender consider whether the thing is actually urgent.

Then honour it absolutely. An urgent route that sometimes gets a slow answer is worse than no urgent route, because it teaches the client to escalate everything in the hope of being noticed.

For genuine outages there is a separate discipline, because a tracking failure is not recoverable by restoring service: every hour of missing events is data no fix brings back. Route those through your incident process rather than through the cadence, and say at kickoff which of the two a given problem will get.

Channel choice is usually treated as a preference and it is actually a policy, because the channel determines what is searchable later and who can join.

Email produces a record and no shared context. A shared chat space produces context and a poor record. A ticketing queue produces both and feels bureaucratic for a two-line question. Most accounts need two of the three, and the mistake is running all three at once.

If the client works in Microsoft Teams, the mechanics matter more than people expect: guest access, shared channels and external federation behave very differently in terms of who can see what and what happens at the end of the engagement. The differences are laid out in running client collaboration in Teams.

Whatever you choose, write down what belongs where and then be consistent for a month. Consistency does more than the choice does. A client will learn any reasonable system if it behaves the same way twice in a row.

One rule that saves a great deal of trouble: decisions do not count until they exist outside a chat thread. A message in a channel is a conversation, not a record, which is why meeting notes that count as a decision record need to be a deliberate artifact rather than a by-product.

Cadence costs money and almost nobody prices it. Do the arithmetic before committing, because a cadence that erodes margin gets quietly abandoned and abandonment is worse than never offering it.

For each account, count the recurring hours the cadence consumes per month: the standing call and its preparation, the report and its commentary, the operational channel monitoring, and the periodic review. Multiply by your delivery cost per hour, then divide by the monthly fee.

That percentage is the share of the fee spent on communication. There is no correct number, and knowing yours changes decisions. If it is large on a small account, the honest options are a lighter cadence or a higher fee, not heroics.

The cost also falls as the reporting gets cheaper to produce, which is why automating the mechanical half is worth more than it looks: it does not just save time, it buys the cadence. That trade is the substance of the client reporting cycle that eats your first week.

Response-time promises deserve the same scrutiny. A tightened response target is a real change in cost even when nothing else moves, and it is one of the specific mechanisms by which a retainer erodes without anyone noticing.

A cadence fails in a predictable way. The standing call gets cancelled once because there is nothing to discuss, then again because somebody is travelling, and by the sixth week it no longer exists.

Do not cancel the call. Shorten it. A ten-minute call that confirms nothing is wrong preserves the slot and costs almost nothing, and the slot is the asset. Once it is gone, reinstating it requires a reason, and the reason is always something going wrong, which makes the reinstated call feel like an escalation.

The second failure is the report that keeps arriving after nobody reads it. Check this directly rather than by open rates: if nobody has quoted a number from the report back to you in a quarter, the content is wrong, and the fix is fewer pages rather than a new schedule.

The third is drift in who attends. A recurring call that gradually loses the decision-maker becomes a status update, and status updates belong in a document. When that happens, the honest move is to shorten the call and move the decisions to a properly constituted forum, which is the argument in running a steering committee that decides things.