Module 3. Claude apps for knowledge work

Most SMB clients start here. No code, no API key, a team of non-technical people. Your job is not to show them features. It is to get Claude used every day by most of the team, and to prove it with numbers.

3.1 The building blocks of the Claude app

A new user sees an empty chat box and does not know what to type. The building blocks below turn that empty box into a prepared workplace. Learn them in this order, because it is the order you will introduce them to a team.

The Project is the most important block for a rollout. It is the unit you design, document and hand over. A good Project has three parts:

• Instructions: who the users are, what the Project is for, the tone, the rules, what to do when information is missing
• Knowledge files: the few documents Claude must rely on: price list, procedures, FAQ. Fewer and cleaner beats more
• Starter prompts: three to five prompts people copy, written in the instructions or on a shared page

Artifacts matter more than they look. A published page is private until someone shares it, so you can tell worried owners that sharing is an explicit act. Check the current sharing options in the help center before you promise anything specific.

3.2 Connectors and least privilege

Without connectors, people paste data into chats. With connectors, Claude reads the source directly. That is more useful and more risky, so connect deliberately.

Custom connectors use MCP, the open protocol from Module 1. You will build servers in Module 6. For now, know that a client with an in-house system is not stuck: it can be connected later, once the basic habit exists.

Least privilege, in practice

A connector acts with the permissions of the person who connects it. So the safest design is to limit what that person can reach, and then limit what Claude is asked to do.

1. Start with the smallest set. Two connectors that serve the first use cases. Add more only when someone asks for a specific job.
2. Prefer read access. Where a connector gives a choice between read and write, choose read first. Where it does not, say in the Project instructions that Claude must draft and never send, delete or change.
3. Clean the source. If a shared drive is open to everyone, Claude can surface what everyone can already open. Fix permissions first. This is a real finding to bring to the client.
4. Use a clear owner. One named person decides which connectors are allowed and reviews them quarterly.
5. Keep a record. A one-line register: connector, who approved it, why, date.

3.3 Claude where the team already works

Adoption is easier when people do not have to open a new tool. Three surfaces bring Claude to tools the team uses already.

Many Israeli SMBs use a mix: Gmail or Outlook for mail, WhatsApp for customers, and a few web portals (customs, carriers, banks, government) without APIs. Ask during discovery which tools people have open all day. That tells you which surface to put in front of them first.

3.4 Skills, plugins and scheduled tasks

Packaging a repeated procedure

When the same procedure appears in every Project, in the same words, it deserves to be packaged. A skill is a procedure written down once (instructions plus any helper files) that Claude loads when the task calls for it. A plugin bundles related capabilities so a team can install them together. You will build both properly in Module 8. At user level, the habit to teach is simple:

1. Notice a procedure someone repeats at least weekly
2. Write it as numbered steps with the expected output
3. Test it on three real cases
4. Save it as a skill, or at least as a shared prompt in the Project

Example: "How we write a quote reply" at Tzafon Logistics: check the price list, add the fuel surcharge line, state the validity date, reply in the customer's language, never promise delivery dates.

Scheduled tasks

A scheduled task runs a prompt at a set time and delivers the result, with no one starting it. It is the cheapest way to move from "assist" to "augment" because the habit forms by itself: the report is simply there on Monday morning.

• Good fits: Monday brief, weekly sales summary, a list of open items before a standing meeting
• Write the prompt as if for a new employee: sources, format, length, what to flag, what to leave out
• A scheduled run has nobody to answer questions. State what to do when data is missing, for example "say what is missing, do not guess"
• Review the first four outputs with the owner, then adjust the prompt

Check the current availability of scheduled tasks and where results are delivered in the help center.

3.5 Team and Enterprise admin basics

Before you invite 30 people, the owner or an IT contact must make a few decisions. Do not state details from memory. Walk through the current admin documentation with the client and record the answers.

Start at support.claude.com and search for the Team and Enterprise administration articles. Save the links in the client's rollout folder with the date checked. If a client needs capabilities such as single sign-on or audit logs, confirm which plan includes them in the current documentation.

3.6 The rollout playbook for a 30-person company

Tools do not create adoption. People do. A rollout fails when 30 people get seats on Sunday and nobody mentions Claude again. The playbook below is built around one idea: a few visible wins, supported by named people, checked every week.

Step 1. Pick two or three use cases

Use the screen from Module 1 (weekly, text-heavy, checkable, recoverable, digital, annoying). For a first rollout choose use cases in different departments, so that more people feel the benefit. Write each as "who does what, how often, how long it takes today".

Step 2. Name a champion per department

A champion is a regular colleague, not an IT person, who likes to try things. Their jobs: answer first questions in their team, collect good prompts, report problems to you, and attend the weekly review. Give them time on the calendar. Tell their manager it is part of their job for 30 days.

Step 3. Run one 60-minute training

Step 4. Hand over templates

Each Project has its instructions, its knowledge files and three to five starter prompts. Put a one-page "How we use Claude here" next to them. People copy templates far more than they write prompts.

Step 5. Hold a weekly usage review

Twenty minutes: you, the owner, the champions. Look at the scorecard numbers, read two or three good examples and one failure, and decide one change for next week. Examples of changes: edit a Project's instructions, add a knowledge file, retire a use case, retrain a team.

Step 6. Score day 30

Fill in the adoption scorecard (below). Then recommend one of three things: continue as is, fix a specific blocker, or add the next use case or connector.

"""make_tzafon_samples.py - generate fake knowledge files for the Tzafon Logistics demo."""
import csv, io, pathlib
import anthropic

client = anthropic.Anthropic()          # reads ANTHROPIC_API_KEY
MODEL = "claude-sonnet-5-5"             # check current IDs at docs.claude.com
OUT = pathlib.Path("tzafon_sample")
OUT.mkdir(exist_ok=True)

SYSTEM = (
    "You write realistic but entirely fictional sample documents for a demo. "
    "Company: Tzafon Logistics, a 30-person freight and warehousing firm in Haifa, Israel. "
    "Services: domestic trucking, port pickups from Haifa port, 3PL warehousing, same-day courier. "
    "Use fake names, fake phone numbers and fake figures. Output only the file content, "
    "with no commentary and no code fences."
)

PROMPTS = {
    "price_list.csv": (
        "Create a CSV price list with header exactly: service,zone,unit,price_ils,notes. "
        "About 18 rows covering the services above, zones north/center/south/Eilat, "
        "units like per pallet, per kg, per trip, per month. Include a fuel surcharge row "
        "expressed as a percentage in the notes column. Values are invented for a demo."
    ),
    "sop_container_pickup.md": (
        "Write a standard operating procedure in Markdown, in English, titled "
        "'Container pickup from Haifa port'. Sections: Purpose, Before you leave, "
        "Documents needed, Steps (numbered), Common problems and what to do, Who to call. "
        "Around 500 words. Use invented role names, not real people."
    ),
    "customer_faq_en.md": (
        "Write a customer FAQ in English in Markdown with 10 questions and short answers: "
        "quotes, delivery windows, damaged goods, invoices, customs documents, tracking, "
        "storage fees. Never promise an exact delivery time. Tell customers to contact "
        "the operations desk (fake address ops@example.com)."
    ),
    "customer_faq_he.md": (
        "Write the same kind of customer FAQ in natural business Hebrew in Markdown, "
        "10 questions and short answers on quotes, delivery windows, damaged goods, "
        "invoices, customs documents, tracking, storage fees. Do not translate word for "
        "word; write it as an Israeli logistics company would. Use ops@example.com."
    ),
}

def generate(prompt: str) -> str:
    msg = client.messages.create(
        model=MODEL,
        max_tokens=3000,
        system=SYSTEM,
        messages=[{"role": "user", "content": prompt}],
    )
    return msg.content[0].text.strip()

def check_csv(text: str) -> None:
    rows = list(csv.reader(io.StringIO(text)))
    assert rows[0] == ["service", "zone", "unit", "price_ils", "notes"], "bad header"
    assert all(len(r) == 5 for r in rows), "row with wrong column count"

if __name__ == "__main__":
    for name, prompt in PROMPTS.items():
        text = generate(prompt)
        if name.endswith(".csv"):
            check_csv(text)
        (OUT / name).write_text(text + "\n", encoding="utf-8")
        print(f"wrote {name}: {len(text)} characters")

You are the sales desk assistant for Tzafon Logistics, a 30-person freight and
warehousing company in Haifa. Users are sales reps and the sales manager.

Purpose
- Draft replies to customer quote requests and follow-ups.
- Answer pricing questions using only the attached price list.
- Answer service questions using only the attached FAQ files.

Rules
1. Reply in the language of the customer's message (Hebrew, Russian or English).
2. Prices come only from price_list.csv. If a service or zone is not in the file,
   say so and list what you need to quote. Never invent a price.
3. Always show the calculation: line item, quantity, unit price, fuel surcharge, total.
4. Never promise a delivery date or time. Offer a delivery window and say it is
   subject to confirmation by the operations desk.
5. Write drafts only. Do not state that anything has been sent or booked.
6. Keep replies short: greeting, answer, next step, signature "Tzafon Logistics sales".

Output for a quote request
- Part 1: the draft reply, ready to paste.
- Part 2: "Check before sending": assumptions you made and missing information.

You are the operations assistant for Tzafon Logistics. Users are dispatchers,
warehouse staff and drivers' supervisors.

Purpose
- Answer "how do we do X" questions from the attached procedures.
- Turn a rough description of a process into a clear SOP in our format.
- Prepare short checklists for a shift or a task.

Rules
1. Base answers only on the attached documents. Quote the section name you used.
2. If the documents do not cover the question, say "Not covered in our SOPs" and
   suggest who should decide. Do not fill the gap with general logistics practice.
3. Use short numbered steps. One action per step.
4. For safety, customs or legal questions, add: "Confirm with the operations manager."
5. When writing a new SOP use these sections: Purpose, Before you start,
   Documents needed, Steps, Common problems, Who to call.
6. Write in the language of the question. Keep technical terms (container, bill of
   lading, pallet) in English if that is how staff say them.

You are a month-end assistant for the finance team at Tzafon Logistics.
Users are the bookkeeper and the finance manager.

Purpose
- Help prepare the month-end checklist and track what is still open.
- Draft variance commentary from numbers the user provides.
- Draft polite payment reminders for overdue customer invoices.

Rules
1. Use only numbers the user has pasted or uploaded in this chat. Never estimate
   or round silently. If a number is missing, ask for it.
2. Show every calculation so a person can check it.
3. Variance commentary: for each line state the amount, the percentage change versus
   the comparison period, and a one-sentence factual reason only if the user supplied
   one. Otherwise write "reason to be confirmed".
4. Payment reminders: three tones (friendly, firm, final). Never threaten legal action;
   write "we will need to review the account" instead.
5. You do not give tax or legal advice. Flag questions for the accountant.
6. Output tables as Markdown. Dates as DD/MM/YYYY. Amounts in ILS with thousands separators.

You are preparing the Monday brief for the management team of Tzafon Logistics.

Sources
- Google Calendar: events for the coming 7 days (Monday to Sunday).
- Google Drive: files in the "Tzafon demo" folder modified in the last 7 days.

Write the brief with these sections, in this order
1. The week at a glance: a table with date, time, event, who attends. Mark with
   "(!)" any day with more than four meetings or any event with no named attendee.
2. Documents that changed: file name, what changed in one sentence, who changed it.
   If you cannot tell what changed, write "changed, details not visible".
3. Items needing a decision this week: only things you can see in the calendar
   entries or the changed files. Maximum five.
4. What I could not check: any source that was empty, missing or not accessible.

Rules
- Use only what you can read from the two sources. Do not guess or fill gaps.
- Maximum one page. Plain sentences, no marketing language.
- Write in English. Keep Hebrew names and file names as they appear.
- Do not send, edit, delete or create anything. This is a read-only report.
- If both sources are empty, say so in one line and stop.

Deliverable: rollout playbook and adoption scorecard

Two files you reuse with every SMB client. Fill them in for Tzafon Logistics so you have a worked example.

1. One-page rollout playbook

1. Company and goal: size, tools in use, one sentence on what success looks like in 30 days
2. Use cases: two or three, each as "who, what, how often, minutes today"
3. Champions: one name per department, with the hours per week they have
4. Workspace setup: Projects, connectors (with owner and date), admin decisions made, links to current documentation
5. Calendar: prepare, training date, weekly review slot, day-30 review
6. Training: the 60-minute agenda adapted to this company
7. Templates: where the instructions, starter prompts and usage policy live
8. Risks and rules: what must not be pasted, who reviews external text, who owns connectors

2. Adoption scorecard template

One row per metric. Fill the target in week 0 and the actual at each weekly review.

Below the table add three lines: What worked, What blocked us, Decision for next 30 days. Label hours saved clearly as an estimate and show how you computed it. A modest, honest number is more convincing to an owner than a large one.

Self-check

1. The owner of a 30-person firm wants to connect Gmail, Drive, Slack and the CRM for everyone on day one. What do you recommend and why?
   Model answer

   Start with the one or two connectors that serve the first use cases, read access where possible, and clean up source permissions first. Add others when a specific job needs them. Each connector widens what can be reached by mistake, and a small start makes problems easy to find.
2. A Project exists for every employee and answers vary wildly. What is the design fix?
   Model answer

   Move to one Project per job (Sales desk, Ops SOPs, Finance) with shared instructions and a small set of clean knowledge files. Then the whole team gets the same rules and the same sources, and improvements benefit everyone.
3. Why does the playbook name a champion per department and hold a weekly review?
   Model answer

   Adoption depends on peer support and feedback, not on seats. Champions answer questions where people work and collect good prompts. The weekly review turns scorecard numbers into one concrete change per week, which keeps use from fading after the training.
4. After 30 days: 30 seats, 27 tried it, 9 active weekly. Which problem is that and what do you do?
   Model answer

   Training worked, but the use cases do not fit enough people's routine, so use fades. Interview the 18 who stopped, pick use cases from their real weekly tasks, adjust the Projects and starter prompts, and ask champions to demonstrate them in team meetings.
5. Write two rules you would put in the prompt of an unattended weekly scheduled task, and say why.
   Model answer

   "Use only what you can read from the listed sources; do not guess" and "Include a section listing what you could not check." Nobody is there to answer questions, so the prompt must stop invention and make gaps visible. A "read-only, do not send or change anything" rule is also a good answer.

Further reading

• Claude Help Center (Projects, connectors, scheduled tasks, Team and Enterprise administration)
• Model Context Protocol in the Claude docs (preview of Module 6)
• Anthropic news (product announcements; check before each client project)
• Anthropic Academy (free courses)