Channels and async work

A team without agreed channels sends everything everywhere, and people end up reading five messages at 23:00 to find one question. Two questions pick the channel for any message: how urgent is it? and does it need back-and-forth?

Urgent and tangled: a call. The payment page is down and families can't pay: post in the team chat with the urgent tag, then get on a call if it needs several people. Urgent and simple: the urgent tag alone. Not urgent: the ticket thread or a written update, answered within the agreed time. One family's refund question that can wait until tomorrow goes in the ticket thread, written in full.

Two cases need judgement. A person who is upset needs a human voice, a call or a one-to-one, not a chat thread. A new reply template is information people read when their shift allows, so it goes in writing.

Everything that doesn't need people at the same moment is asynchronous communication, and for a team across Kyiv, Lviv and two hours west it's the default, not the exception.

Async only works when a message is complete: the reader can act on it without a follow-up. Five parts make it complete: the context (which family or ticket, what happened), what you've tried, what you need (a decision, an answer, a review), and by when.

Compare Taras's five lines ("hi", "got a sec?", a question, "never mind", "actually, still need it") with one message: "Family X, refund for 3 lessons lost to a tutor no-show. Policy covers 2. Can I approve the third? They're waiting; tomorrow 10:00 is fine." The second can be answered at 8:00 without a single follow-up, and its deadline tells the reader nobody needs a reply at 23:00.

The bare "hi" is the classic async mistake: it asks the other person to be online at the same moment just to find out what you want. Olha's request makes a good team rule: no more bare "hi" messages; put the question in the first line.

A team spread across time zones always has inconvenient hours: early calls for the people to the west, late evenings when families abroad write. Somebody covers them, and the question is whether that's decided or left to default.

The default is usually unfair. At Klasna two coordinators work two hours behind Kyiv: their morning starts when Kyiv's queue is already full, and a 9:00 Kyiv meeting is 7:00 for them. EU families write in their own evening. It's tempting to hand all of that to whoever seems "closer", but the same people then carry every awkward hour, month after month.

Rotate the inconvenient slots across the whole team, visibly and in advance, with swaps allowed. Move meetings so the early hour doesn't always fall on the same two, or replace them with written updates. The lead shouldn't absorb every evening either: that rebuilds the bottleneck and tells the team that working all hours is expected.

In Ukraine, power and connection cuts are part of normal planning, not an emergency. Assume any person can lose power mid-shift, and ask what the team needs so that no family waits.

Three habits cover it. A short handover note in each open ticket: what's been done and what's next, so anyone can pick it up. A backup channel, such as the team chat on mobile data, and one line when you go dark: "No power, buddy has my queue, back around 15:00." Thirty seconds, and nobody has to guess. A named buddy who takes the queue.

When Bohdan loses power with six open tickets, this setup keeps families from waiting without anyone watching anyone. The alternatives fail: holding the tickets until the power returns punishes families; watching online status and reassigning after an hour is surveillance that reacts late; routing everything to the lead rebuilds the January bottleneck.

The AI draft assistant is good at routine writing work: first drafts of standard replies, summaries of long threads, turning rough meeting notes into a tidy list of decisions and action items. These save time, and a person still checks every word before anything goes out.

A useful test: is this work about wording or about a decision? A reply on how to reschedule a lesson is wording around a clear rule, so a draft helps. A summary of a 40-message ticket thread for the person taking over is wording, and saves them twenty minutes of reading. Tidying meeting notes is wording.

A written warning to a coordinator about missed shifts is a decision about a person, and needs the lead's own judgement and words. Whether a family gets a refund outside the policy is a decision, and it's Iryna's, not a tool's. The time a tool saves on routine replies is what makes room for that kind of careful, personal work.

Some work stays with people however good the tool gets, and a human check at the end doesn't change that.

Decisions about people: feedback, evaluations, warnings. They need the lead's own judgement and words; a generated warning tells the person their case wasn't worth your time. Bad news to a person, and replies to a family that's upset: when someone needs to feel heard, a person writes it, as Bohdan insists. Decisions outside a rule: a refund outside the policy is Iryna's decision, not a tool's suggestion.

And personal data: a family's or child's details never go into a tool the company hasn't approved. Checking the draft afterwards fixes the wording, not the fact that the data has already left. If you're unsure whether a tool is approved, ask before pasting, not after.

The point of the tool is to save time on routine work so that there's time for the work only a person should do.

A common misreading of async is that a reply can wait as long as the reader finds convenient. It can't. Async frees people from being online at the same moment, not from deadlines.

Iryna puts the risk plainly: if a family's question waits two days in a thread, that's not async, that's lost. The family doesn't care which channel the question sat in; they care that nobody answered.

So async needs two things written down. First, an agreed response time per channel, known to everyone: the urgent tag within 15 minutes on shift, ticket threads the same working day, written updates read within a day. Second, every message says by when it needs an answer, so the reader can sort their queue. With both in place, people can work in their own hours and nothing important falls through the gap between them.

Async frees people from being online at the same moment. It doesn't free anyone from deadlines, and it doesn't mean everyone is reachable all the time. Two agreements make it work.

Response times per channel. Iryna's warning: if a family's question waits two days in a thread, that's not async, that's lost. So each channel gets an agreed time: the urgent tag within 15 minutes on shift, ticket threads the same working day, written updates read within a day. Every message says by when it needs an answer.

Quiet hours. Outside someone's shift, nobody expects a reply. You can still write: schedule the message for the morning, or say "no need to answer tonight". Taras's 23:00 refund question was fine to send as one complete message with "tomorrow 10:00 is fine"; it just shouldn't need an answer at 23:00.

How it fits together: pick the channel by urgency and back-and-forth, write complete messages, plan for time zones and outages, keep people's decisions away from tools, and agree response times and quiet hours. Next, Bad news up, decisions down: the news that doesn't travel through any channel because nobody dares to send it.