Ask a team lead what they check every Monday and you get a familiar list. Which projects are behind. Who has not been contacted lately. What is expiring. What changed since last week. Each check takes twenty minutes of opening files and comparing numbers, and each is done from memory, so each is done slightly differently every time.
A routine is that check written down once.
What a routine is
A routine has three parts: a name, instructions in plain language, and a schedule. "Weekly enrollment check. List every active study that is behind its enrollment commitment; for each, give the numbers, the reason the files record, and the next planned step; cite the files. Every Monday at nine."
When it runs, the system searches the knowledge base the way a careful analyst would, reads what it needs, and writes the result with citations. The result is saved with the run, so there is a record of what was known when.
Writing good instructions
The instructions are the whole design, so it is worth being specific about three things.
What to look at. Name what to look at and the condition. "Active studies where randomized is below committed." "Clients with no contact in sixty days." Vague instructions produce vague results.
What the output must contain. List the columns. Numbers, reason, owner, next step, source. A routine that says "summarize the situation" will summarize differently every week; one that says "for each item give these five things" is comparable across weeks.
What to do about gaps. Say whether an item with missing data should be listed with the gap noted, or left out. Listed with the gap is usually right; the gap is often the finding.
Standing reference files versus files for one run
Some routines need material that is not in the knowledge base: a scoring rubric, a template, a checklist. Attach these to the routine as reference files and they go into every run. Other runs need something one-off: today's protocol to assess, this week's RFP to compare against past work. Attach those to the run itself, and they apply once and are recorded with that run.
Keeping the two separate matters. A rubric is part of the routine's definition; a protocol is an input. Mixing them means either the rubric has to be re-attached every time or last week's protocol contaminates this week's run.
Where scheduled work goes
A scheduled result nobody reads is a scheduled result nobody needed. Decide at the start who receives each routine's output and how: in the knowledge base's run history, by email, in a channel. Then review the routine itself after a month. Routines that always come back empty can run less often; routines whose results people act on can carry more detail.
Start with three
Pick the three checks the team does most often and write them as routines. Run each once by hand to see the output and tighten the instructions. Then schedule them. The measure of success is simple: on Monday morning, the answers are waiting, and they say where they came from.
How Desk helps
Desk routines are a name, instructions, and a schedule.
- Write the check once in plain language. Desk runs it on demand or every day, weekday, week, or month, in your time zone.
- Attach standing reference files such as a rubric to the routine, and one-off files such as this week's protocol to a single run; each run records which it used.
- Every result is saved with citations, so the team can see what was known on any given Monday.
Thinking about how this would work for your team?
Let’s chatKeep reading
"Have we done this before?" is the most expensive question in your company
It gets asked a dozen times a week, it is almost always answerable from files you already have, and the answer usually arrives too late to matter.
Read more →Tribal knowledge: what it costs and how to capture it without a reorg
The knowledge that walks out the door is rarely written nowhere. It is written somewhere unfindable. The fix is not asking people to document more.
Read more →