Knowledge onboarding

Documented processes rarely capture what people actually do. The written procedure says invoices are matched to purchase orders in the system. The real procedure adds: except when the purchase order was never created, in which case someone emails the department head for a retroactive one, unless it is under five hundred dollars, in which case it gets coded to the general expense line and flagged.

A run built on the written version breaks the first time it meets the real one. Knowledge onboarding is the work of writing down the second version.

What belongs in Knowledge

• Citation standards, brand voice, and formatting conventions.
• Approval policies and the thresholds that trigger them.
• Deployment and release procedures.
• Client-specific or account-specific rules.
• Calculation rules, tolerances, and how exceptions are classified.
• The names of the systems that hold each record.

Small entries beat one large manual

Small, targeted entries are easier to retrieve correctly. A trigger describes when an entry should be loaded, so a citation standard arrives during research and drafting and stays out of an unrelated infrastructure task.

One large document with everything in it retrieves badly, because most of it is irrelevant to any given run and the relevant part competes with the rest.

Where to get the material

The fastest source is a completed run. After a job finishes and a reviewer corrects it, the corrections are the unwritten rules becoming visible. Classify each one and store the durable ones.

The second source is sitting with the person who does the work. Watch the exceptions rather than the happy path, because the happy path is usually already documented and the exceptions are where the tribal knowledge lives.