Company know-how out of your head: AI interviews, Lucid, and Notion

I'm the owner of a metalworking workshop with 12 people: custom
fabrication (gates, railings, steel structures, staircases),
on-site installations, and service. I want to list all the
recurring processes in the company so I can pick which ones to
document first.

Walk me through it area by area: sales (inquiries, quotes,
contracts), jobs and production, purchasing and stock, installation
and service, finance (invoicing, payments, reminders), people
(hiring, onboarding, attendance), operations (machines, inspections,
workplace safety, vehicles). For each area, ask me 3-5 "what happens
when..." questions and build a list of processes from my answers
as we go. A process = a repeated activity with a start and an end,
not a department.

Ask me about one area at a time so I can keep up. At the end, give
me one list: process name, what it is in one sentence, how often
it runs (daily / weekly / monthly / occasionally), and who actually
does it today — names, not job titles.

Here's our list of processes from the inventory [paste the list].
Help me pick 10 to document first.

For each process, ask me (one at a time, briefly):
1. How many people can do the whole thing today, without help?
   (bus factor)
2. What happens if that person is out for 14 days — does the
   process wait, does someone half-cover it, or does it stop and
   cause damage?
3. How often does the process run?
4. Has this process ever cost money because it was done wrong or
   late? Roughly how much, order of magnitude?

Build a table from the answers: process, bus factor, impact of an
outage (stops / slows down / waits), frequency, history of mishaps.
Propose a documentation order: process with a bus factor of 1 that
stops completely on an outage and runs often go first. Justify each
row's ranking in one sentence — I'll make the final call.

We have a ranked list of 10 processes to document [paste it] and
three people who hold them in their heads: owner (quotes,
complaints, purchasing), foreman (production, planning,
collaboration, shipping), bookkeeper (invoicing, reminders). We all
know the onboarding process in bits and pieces.

Build a 6-week interview schedule: 2 interviews a week, 45-60
minutes each. For each one, note: the process, who's being
interviewed, what they should prepare beforehand (the last concrete
case, materials — notebook, spreadsheets, sample documents), and
who will review the interview (a second person who knows the
process at least partially). Spread out one person's interviews
over time so they don't get three evenings in a row. I want the
output as a table I can print and pin up in the workshop.

You'll run a structured interview with me about one company
process. I'm [the owner of a metalworking workshop, 12 people] and
the process is [a price quote for custom fabrication]. Goal:
capture how we ACTUALLY do this here, so a capable new hire could
follow it from the record. A diagram and a knowledge-base page will
be built from this interview later.

Interview rules:
- Ask ONE question at a time and wait for the answer. No
  questionnaires.
- Start with the trigger: what starts the process and how I'd
  recognize that it started.
- Then walk me through the steps. For each one, ask: what gets
  done, who does it, in what / where (system, spreadsheet, paper),
  what the step ends with, and how the result gets handed off.
- When I say something vague ("I just calculate it"), stop me and
  ask for specifics: based on what, where do the numbers come
  from, what if something's missing.
- After the main path, ask about exceptions: "When does it go
  differently?" — rush jobs, a big customer, missing material,
  vacations. For each exception: how I'd recognize it and what
  happens instead of the standard.
- At the end: what has historically gone wrong in this process,
  what it cost, and what's been done differently since.
- Keep structured notes as we go. If I contradict myself, flag it.

When I say "done," end the interview and summarize what's still
missing.
Start with the first question.

Change of technique: instead of a general description, let's walk
through ONE concrete, recent case. Take the last [price quote] I
did — [a railing for an apartment building, last week] — and walk
me through it step by step: what exactly did I do first, then
what, where did I look things up, who did I call, what slowed me
down.

Ask about the timeline and facts, not opinions. If I describe a
step that differed from the usual procedure in that job, ask what
the more common version is and how often it comes up. At the end,
compare: this is how the last case went vs. this is what the
standard looks like — and list the differences. Differences aren't
a mistake, they're the most valuable part.

We'll do the interview by voice. I'm the production foreman, and
as I walk through the shop I'll tell you how I plan the production
week and release jobs onto the machines. Ask me following the
structure: trigger, steps, who, systems, exceptions, mishaps — but
one short question at a time, we're talking, not writing. If I
mention a machine, a whiteboard, or a sheet of paper, ask exactly
what's on it and who's allowed to write on it. Don't summarize what
I said after every answer — just keep asking. Give me the full
summary only when I say "done."

Here are two interview transcripts about the SAME process [order
intake and release into production]: the owner's version [paste]
and the foreman's version [paste].

Compare them and give me three lists:
1. Agreements — what both describe the same way (keep this brief).
2. Contradictions — where the versions disagree: who does what,
   order of steps, who's responsible for what. Quote both versions
   for each contradiction.
3. Blind spots — what one version describes and the other doesn't
   mention at all.

Don't judge who's right — for each contradiction, prepare one
question we can clarify together at the table.

Build a structured record in markdown from our whole conversation
about the [price quote] process:

## Basics
Process name, purpose in one sentence, trigger, what the process
ends with (definition of done), how often it runs.
## Roles
Who appears in the process and what they do — attach a real name to
each role.
## Main-path steps
Numbered list: step, who, in what/where, output of the step. Keep
it brief — details go in notes below.
## Decision points
Where the process branches, what the decision is based on, who
decides.
## Exceptions
Off-standard situations: how to recognize it → what happens
instead.
## Systems and artifacts
Where things live (spreadsheets, notebooks, programs, binders) — no
passwords.
## Known risks and past mishaps
What went wrong, what it cost, what safeguard exists since.
## Open questions
What the interview didn't cover, or where I contradicted myself.

Write only what came up in the interview — don't guess at anything.
Where information is missing, write OPEN instead of filling in a
plausible answer.

From the attached record of the [price quote] process, create a
new document [Process: price quote] via the Lucid connector with a
flowchart.

Rules:
- Only the main path and decision points from the record — no
  exceptions, those will be in the text documentation. Target max
  12-15 steps.
- Start: trigger (an inquiry comes in). End: definition of done
  (a quote sent and logged).
- Steps as rectangles, decisions as diamonds with a question and
  branch labels (yes/no, under 30k / over 30k).
- Step text: verb + object ("measure on site," "calculate
  material"), no paragraphs.
- Where the record says who does a step, add the role in
  parentheses under the step text.
- Don't guess anything — where you're missing information for a
  connection, ask me instead of quietly filling it in.

When done, send me the document link and a short list of what you
did NOT include from the record, so I can check it.

In the same Lucid document, create a second version of the [order
intake and release into production] process as a swimlane diagram.

- Lanes by role: owner, sales rep, foreman, production, bookkeeper.
  Only roles that actually appear in the process.
- Put each step in the lane of whoever DOES it (not whoever's
  officially responsible for it — if those differ, tell me as a
  note).
- Arrows between lanes = a handoff. Label each one with WHAT gets
  handed off (paper, email, a spreadsheet entry, verbal).
- Highlight handoffs labeled "verbal" in color — those are our risk
  spots.
Then give me one list of all the verbal handoffs.

Update the [Process: price quote] diagram in Lucid based on the
review with the foreman:
- Split the "calculate material" step into two: "list material
  items" and "check what's in stock, price the rest with the
  supplier."
- After the "job over 30k?" decision, on the YES branch, add a
  step "30% deposit before starting" (done by the bookkeeper).
- Rename "send quote" to "send quote and log in the quote
  register."
- Remove the "check with production" step — it doesn't happen in
  practice, it was an idealization.
Don't change anything else. Afterward, give me a list of the
changes you made so I can check them off against my notes.

Create an org chart of our company via the Lucid connector in a new
document [Organization]. Structure:
owner (sales, quotes, key customers) → production foreman
(planning, production, collaboration, shipping) → [list of
production people with their trade: 2 welders, 2 metalworkers,
bending machine operator...]; alongside the foreman, an
installation crew [installation lead + 2 installers]; directly
under the owner, a bookkeeper (invoicing, payroll, reminders) and
a sales rep (inquiries, quote register).
For each person, add 2-3 main responsibilities on the second line —
not their job title from a contract. Don't leave anyone out, even a
part-timer belongs here.

Create a mind map [Company process map] via the Lucid connector:
company name in the center, our domains at the first level [paste],
processes from the inventory at the second level [paste the list].
Highlight the processes from the top ten. For processes that
already have a finished map and page, add a checkmark after the
name. Don't add anything else — this is an overview, not content.

We're going to build our company's knowledge base [metalworking
workshop, 12 people] via the Notion connector. Don't create ANYTHING
yet — propose a structure:
- root page [How We Do Things Here]
- domain sections following this list from our inventory [paste
  domains]
- within each domain, space for process, procedure, and template
  pages
- a [Process register] database with properties: name, domain,
  owner (person), status (interviewed / mapped / written / verified),
  criticality (bus factor 1 / important / routine), last review
  (date), next review (date), link to the Lucid diagram (URL)
Give me the proposal as a tree, so I can see what goes where, and
ask me questions wherever you're unsure about the placement. Build
the structure once I approve it.

From the attached record of the [price quote] process, create a
page via the Notion connector in the [Sales] domain, following our
template:

1. Summary — 3 sentences: what the process is for, what starts it,
   what it ends with.
2. Process map — insert a link to the Lucid diagram here [paste
   URL] and a note: "See the map for the detailed flow; this page
   carries the details."
3. Steps — a numbered list of the main path; for each step, who,
   in what, and a link to the procedure if a separate guide exists.
4. Decision rules — exact criteria from the record (limits, rates
   linked to the rate sheet, who approves).
5. Exceptions — a "when..., then..." list from the record,
   including who's allowed to authorize the exception.
6. Where things live — systems and artifacts: what's in which
   spreadsheet, binder, program. No passwords — where access is
   needed, write "access: see password manager."
7. What's historically gone wrong — lessons from mishaps in the
   record.
8. Open questions — unresolved points; for each, who needs to
   resolve it.

Keep the phrasing from the record, don't polish it into corporate
language — "send it to zinc" is our actual term. At the end of the
page, add a line: Owner: [name] · Last review: [date] · Source:
interview [date]. Then create a row in the Process register and
link it to this page.

Check the consistency of our process documentation:
1. Go through the Process register in Notion and, for each entry,
   verify that the Lucid diagram link points to an existing
   document.
2. Search our Lucid folder and list diagrams that have no matching
   page in Notion (orphans).
3. For processes with status "verified," compare the diagram's
   steps against the page's Steps section: list the differences (a
   step missing from the page or the map, different order,
   different names).
Give me a clear table of findings. Don't fix anything — I'll
approve fixes one at a time.

From our Notion knowledge base, build an onboarding plan for a new
welder-metalworker [Ondřej], starting [date]. He'll work in
production under the foreman, and do installations over time.

1. Go through the Process register and pick the processes where the
   production or installation role appears.
2. Build a 3-week plan: what to read which day (links to specific
   pages), what to look through in the maps, what to have shown to
   him physically in the shop, and by whom (names from the org
   chart).
3. For each week, add 5 check questions he should be able to answer
   by the end of it — the foreman will go through them with him on
   Friday.
4. Separately, list what's missing from the base for his role (a
   process where his role is mentioned but has no page or
   procedure) — that's our gap, not his problem.
Create a page [Onboarding: Ondřej] in the People domain from this.

Go through our swimlane diagrams in Lucid and find all the lanes
with the [production] or [installation] role — that'll be the new
hire's [Ondřej] role. Derive his onboarding rounds from the maps:
1. List every handoff he'll be part of: what he takes from whom,
   what he hands to whom, in what form (paper, log entry, verbal) —
   with a link to the process.
2. Build a "walk it through in person" checklist from that: for
   each handoff, who he should walk through it with once, in the
   shop, and what to have shown to him.
3. Put handoffs marked "verbal" in the maps at the top — that's
   where a new hire most easily loses information, and nobody
   notices.
Save the output as a subpage of [Onboarding: Ondřej] in Notion.

You answer our company's operational questions EXCLUSIVELY from the
Notion knowledge base. Rules:
- For every answer, cite the page you're drawing from.
- When the answer isn't in the base, or is ambiguous, say so
  explicitly and point to the process owner from the Process
  register — never guess an answer.
- When the question involves values (prices, rates, limits), quote
  the value along with the page's last review date, so it's clear
  how fresh it is.
- Keep collecting questions the base couldn't answer; list them for
  me on request as items to fill in.
Question: [when does a deposit get taken on a job, and how much?]

From the [outbound inspection and shipping] process page in our
base, build a shipping checklist: one A4 page, items in the order
the check is actually done, a checkbox and a note space next to
each item. Last lines: who checked it, date, signature. Shop-floor
language, no formal wording. Save it into the Templates section in
Notion and add a link from the process page. Put a version and date
in the checklist's header — when the process changes, the checklist
has to be regenerated too.

The owner will be unreachable [August 3-17], covered by the foreman
[Franta] with support from the bookkeeper [Jana]. Build a coverage
manual for that period from our knowledge base:

1. Go through the Process register and list the processes where the
   owner is the only role — for each, exactly who will do what
   instead in August, with a link to the page and the relevant
   step.
2. Decision authority: pull every "owner approves" spot from the
   pages' decision rules, and propose an August mode for each — the
   stand-in can decide up to a limit / it waits / call the owner.
   The owner reviews and edits the proposals.
3. Build a "call the owner only if" list — situations that,
   according to the base, nobody else is allowed or able to
   resolve.
4. At the end: contacts, deadlines falling due in that period (from
   the register and the pages), and what's deliberately being
   pushed to after the vacation.
Save it as a page [Coverage: August] and share it with Franta and
Jana.

The [steel stock purchasing] process changed: [new supplier —
orders go through a portal instead of by phone, order by Wednesday
12:00, the minimum order changed, pricing is on the portal].

Make the change across the whole documentation:
1. Update the Lucid diagram: replace the "order by phone" step with
   the portal steps, update the timing note.
2. Update the Notion page: the Steps section, "Where things live"
   (add the portal, access "see password manager"), and "Decision
   rules" (new minimum).
3. Add a line to the page's change history: date, what changed, why,
   who approved it [Petr].
4. Update the last-review date in the Process register.
5. Check whether any other page or template still references the
   old procedure — list what still needs to change.
Before you start, summarize the changes you're about to make — I'll
approve them.

Quarterly documentation review. Go through the Process register in
Notion and:
1. List the processes whose next-review date has passed, sorted by
   criticality, with the owner for each.
2. For each owner, prepare a short check questionnaire (max 5
   questions) tailored to their process: "Does step X still hold?
   Did Y change? Any new exception?" — base it on the page's
   content.
3. List pages with a status other than "verified" that are older
   than a month — those are unfinished loose ends.
4. List the open questions from every page, in one place.
From items 1-4, build a 30-minute review meeting agenda: what to
cover, in what order, and what can be settled with just a "no
change" confirmation.

Run a security review of the Notion knowledge base:
1. Search all pages for anything that looks like a password, PIN,
   access code, API key, or login credentials — including in notes
   and page change histories.
2. Look for customer personal data: names paired with an address,
   phone number, email, national ID numbers, license plates. Sample
   examples on pages should be fictional — flag any that look real.
3. List pages shared outside the company workspace or via a public
   link.
4. List guests and external accounts with access, and which pages.
Give me the findings in a table: where, what, severity, suggested
fix (move to the password manager / anonymize / revoke sharing).
Don't delete or touch anything — we'll resolve every finding by
hand.

You have access to our Notion knowledge base and our Lucid maps.
Play the role of an experienced operations manager taking over
running the company starting Monday — the owner is unreachable for
14 days. You may not ask any human, only the base.

Go through the documentation and answer:
1. Which everyday situations over the next 14 days could you handle
   from the base alone? (an inquiry comes in, a complaint, missing
   material, a welder calls in sick)
2. Where would you get stuck — what won't the base tell you? Be
   specific: which piece of information, on which page, is missing.
3. Which three pages are the weakest, and why?
4. Be strict: could this company actually be handed over based on
   this documentation? What would have to exist for the answer to
   be yes?
Don't go easy on us — every gap you find now is a gap the stand-in
won't find in August, or the buyer won't find during due diligence.