Claude Use by Department: What Public Data Shows

What you will have at the end

One Python file, departments_claude_usage.py, that fetches Anthropic’s public Economic Index files itself, maps every task that has an occupation to a department, checks its own result and writes two CSV files: departments_claude_usage.csv (13 departments and an “Other occupations” group, plus the share that no occupation could take) and major_groups_claude_usage.csv (the 22 occupation groups against US employment). It needs only the duckdb Python module, no account and no API key. It does not call Claude.

The question behind it is one a CDO can expect in a Claude rollout: which departments use it, and for what? Anthropic’s Economic Index does not answer that by department, because its categories are occupations. We did the translation in the open, so you can change it.

Method

The data

The Anthropic Economic Index, folder release_2025_02_10, pinned to dataset commit 4e5f69fab13a9c3f7d0dcc31a6f893a9818738f6, at huggingface.co/datasets/Anthropic/EconomicIndex (read 2026-10-18). The dataset card says “Data released under CC-BY, code released under MIT License”; its metadata header says license: mit. We credit Anthropic either way. We use four files from the folder:

• onet_task_mappings.csv: the percentage of conversations involving each O*NET task (3,514 rows).
• onet_task_statements.csv: O*NET’s task text and the occupation code that lists each task.
• SOC_Structure.csv: the occupation hierarchy, used for the group titles.
• bls_employment_may_2023.csv: US employment by occupation group, from the Bureau of Labor Statistics.

Per Anthropic, the analysis covers about one million Free and Pro conversations on Claude.ai and excludes API, Team and Enterprise usage. Anthropic used its automated analysis tool Clio to match each conversation to the O*NET task that best fit Claude’s role, so researchers did not read the conversations (Anthropic: The Anthropic Economic Index (read 2026-10-18)). The pages we read do not state the period the conversations were collected in. The folder name dates the release, not the conversations.

From task to department

1. Each O*NET task carries a share of conversations. The 3,514 shares add up to 100%.
2. A task can be listed by several occupations. We split its share equally across the occupation codes that list it. Anthropic’s method for this step may differ, and the choice matters for tasks that many occupations share (see Limits).
3. Each occupation code goes to a department by the longest matching prefix in the table below. We wrote this table. It is a judgment, not a fact about your company: an “Operations” occupation in the SOC code list is not your Operations department.
4. Shares are summed per department. One task in the file is the text none, which has no occupation; its share is reported on its own line, not hidden.

The mapping, as written in the script (longest prefix wins)

The prefixes are Standard Occupational Classification (SOC) codes, the system O*NET builds on. Edit the DEPARTMENT_BY_PREFIX dictionary at the top of the script, run it again and every number below changes with it.

The core of the script

DuckDB reads the CSV files straight from the pinned URL. This is the step that assigns codes to departments and splits each task’s share:

Python and SQL: map codes, split shared tasks (excerpt of the script)

con.execute("""
CREATE TABLE occ_dept AS
SELECT DISTINCT code,
       coalesce(first(department ORDER BY length(prefix) DESC), 'UNMAPPED') AS department
FROM (SELECT DISTINCT "O*NET-SOC Code" AS code FROM statements) o
LEFT JOIN dept_map d ON o.code LIKE d.prefix || '%'
GROUP BY code""")

con.execute("""
CREATE TABLE task_occ AS
SELECT DISTINCT lower(trim(Task)) AS task, "O*NET-SOC Code" AS code FROM statements""")

con.execute("""
CREATE TABLE weighted AS
SELECT m.task_name, m.pct, t.code, d.department, t.task AS matched,
       m.pct / greatest(count(t.code) OVER (PARTITION BY m.task_name), 1) AS weight
FROM mappings m
LEFT JOIN task_occ t ON lower(trim(m.task_name)) = t.task
LEFT JOIN occ_dept d ON t.code = d.code""")

DuckDB reads CSV files over HTTPS with read_csv (DuckDB: CSV import (read 2026-10-18)). We ran this version:

python3 -c "import duckdb;print(duckdb.__version__)"
1.5.6

The script checks its own result

Before it writes a CSV, the script checks that the department shares sum to 100%, that the number of rows loaded equals the number in the source file, that no task appears twice, that each task’s share is handed out in full across its occupations, that every prefix in the mapping table matches a real occupation code (so a prefix that matches no real code is caught, not silently ignored), that every occupation code maps to a department, and that the only task with no occupation is the recorded none. If any check fails it prints the failure, writes no CSV and exits with code 1.

Run 2. A planted fault the checks must catch

The same script with the --fault flag changes its input after loading. It duplicates five rows of the task-share file and adds one occupation code, 99-9999.00, that no department prefix covers. Nothing about the source files changes; the faults are made in memory. The script must say so and refuse to write a CSV.

Output from our run: python3 departments_claude_usage.py --fault (first 8 lines)

Checks
  [PASS] shares sum to 100%: departments total 100.000000%
  [FAIL] mapping rows match the source file: 3519 rows loaded, 3514 in the source file
  [FAIL] no duplicate task in the mapping file: 5 duplicated task name(s)
  [PASS] every task's share is spread in full: largest gap between a task's share and what its occupations received: 4.16e-17
  [PASS] every department prefix matches a real code: all prefixes used
  [FAIL] every occupation code maps to a department: 974 of 975 codes mapped, 1 unmapped
  [PASS] tasks with no occupation are only the recorded 'none': 1 task(s) without an occupation, carrying 0.4816% of conversations

Three of the seven checks failed: the row count (3,519 loaded against 3,514 in the source), the duplicate task names, and the unmapped occupation code. The script exited with code 1 and wrote no CSV (its last line read 3 CHECK(S) FAILED: no CSV written). The sum-to-100% check still passed, because a duplicated task halves each copy’s weight when the share is split, so the total stays at 100%. That is why the script does not rely on one check.

Limits

• This is not a client result and not an enterprise result. It describes Anthropic’s published sample of Claude.ai Free and Pro conversations. API, Team and Enterprise usage is excluded (Anthropic (read 2026-10-18)). Companies that roll out Claude to chosen departments may look nothing like it.
• It is an old snapshot. The release is dated 2025-02-10. The dataset card lists later releases, which we did not use, so the picture may have moved.
• Occupation is not department. A person in a Marketing department may hold an occupation we map elsewhere, and the reverse. The mapping table is our judgment. Change it and the department shares change.
• The equal split is a choice. Many tasks are listed by dozens of occupations. For example, the largest “Other occupations” task is a generic program-modification task, which the equal split spreads across occupations outside IT. Another split rule would move shares between departments.
• Conversations are not outcomes. The data counts what people asked Claude to do. It does not say whether the answer was used, whether time was saved or whether the work was better.
• Coarse by construction. Departments are inferred from O*NET occupations, not recorded. HR is three occupation codes. The shares are rounded in the CSV to two decimals.
• We took Anthropic’s mapping as given. We did not check how well each conversation was matched to its task.