日本語

Scalar Account Plan

Use references/scalar/workflow-contract.md for shared safety, Drive, approval, and QA rules. references/scalar/sales-playbook.md remains the only source for phases, gates, and checkpoint definitions — phases and gates are §2, the checkpoint questions and their ledger fields §7. Open that section, not the 20KB file.

One ledger per customer. The ledger is the single source of truth; the deck is just a rendering of it. Append to the ledger after every visit, and refresh the deck at the same URL.

Two kinds of deck come out of the ledger. They have different lifespans and inputs, so don't mix them. This skill covers the left one.

Working directory: the slide-forge root. Run commands with .venv/bin/python.

Boundaries

This is an internal document

The activity plan records judgments about named individuals (influence, position, whether they've been contacted). Never hand it to the customer or a partner. On Drive, 00_活動計画 and 90_社内 are never shared. Only what has been placed under 01_顧客提示 / 02_顧客提案 may be shown to the customer.

Locations

config/sales.json                       Drive ルートと既定 AE 名（gitignore 済み）
accounts/<AE 名>/<顧客名>/account.json   ★ 正本（gitignore 済み。コミットしない）
accounts/<AE 名>/<顧客名>/aps.json       APS デッキの内容（別スキルが使う。同上）

Drive: <ルート>/<AE 名>/<顧客名>/
  00_活動計画/  活動計画デッキ（URL 不変）・account.json のコピー・action-plan.md
  01_顧客提示/  顧客提示用
  02_顧客提案/  顧客提案用
  90_社内/      社内説明用

Workflow

1. Prepare the ledger

Read it if it already exists. Create it if it doesn't.

.venv/bin/python scripts/scalar/account_ledger.py init --ae "<AE 名>" --customer "<顧客名>" \
    --opportunity "<商談名>"

Ask for the Drive root only the first time and build the hierarchy from it (after that, use the setting in config/sales.json). Always confirm with the user when the root is not set. Never create it under My Drive root on your own.

.venv/bin/python scripts/scalar/account_workspace.py ensure \
    --ledger accounts/<AE>/<顧客>/account.json [--root "<Drive フォルダ URL>"]

2. Fill it in from material at hand (read before asking)

Read minutes, meeting notes, emails, and CRM exports first. Only then, ask for what's still missing, in a single batch (references/interactive-intake.md §0, §5).

When writing to the ledger, always distinguish facts[].kind:

Status rules follow b2b-account-maps's discovery-map.md. Don't define them twice.

Never do this:

• Place someone you haven't met at the center of the influence map as "neutral" (put not-yet-contacted people in gaps)
• Mark something confirmed based on a guess (confirmed entries with no evidence fail validation)
• Write down a number the customer never said

3. Validate

.venv/bin/python scripts/scalar/account_ledger.py validate accounts/<AE>/<顧客>/account.json

Inconsistencies get caught here — an unsubstantiated confirmed, a met gate with no evidence, an action with no due date or completion condition, a Commit forecast when BANT isn't complete. Fix the ledger. Don't loosen the validation.

4. Turn open items into actions (the heart of this skill)

.venv/bin/python scripts/scalar/account_ledger.py gaps accounts/<AE>/<顧客>/account.json

Of the 10 questions in playbook §7, the ones that can't be answered come out with who to confirm with and the completion condition. Never fill in the answer yourself. Leave open items open, pull them into actions with --carry-over, and only let the user set the due date (the due date is the AE's commitment, not something this tool decides).

--carry-over is a flag on the following two commands (both rewrite the ledger before printing output):

# アクションプランの Markdown を出すついでに取り込む
.venv/bin/python scripts/scalar/account_ledger.py actions <account.json> --carry-over

# デッキ生成（§5）のついでに取り込む
.venv/bin/python scripts/scalar/build_account_plan.py <account.json> --carry-over

Unfinished actions from last time carry forward as-is. Overdue ones trigger a validation warning.

5. Build / update the activity plan deck

# 検証（API を呼ばない）
.venv/bin/python scripts/scalar/build_account_plan.py <account.json> --dry-run --strict

# 初回 — 00_活動計画 フォルダに新規作成
.venv/bin/python scripts/scalar/build_account_plan.py <account.json> --folder <00_活動計画 の ID>

# 2 回目以降 — 同じ URL の中身を差し替える（台帳の meta.decks.activityPlan を自動で使う）
.venv/bin/python scripts/scalar/build_account_plan.py <account.json>

The default 9 pages (excluding the cover) are ordered to be read in this sequence:

account-snapshot (where things stand now) → phase-gate (what's not yet met) → bant-risk (where the risk is) → discovery-map (what's unknown) → pain-chain (why it works) → influence-map / buying-committee (who to move) → activity-timeline (who's been reached so far) → action-plan (what to do next)

A page with insufficient material is automatically dropped. Dropped pages are listed in the report. Don't build a thin page with blanks filled in — it's correct for what's missing to show up in action-plan instead.

--pages can add visit-plan / win-plan / discovery-gaps. These 3 are for a single visit or a single WPS and have a different lifespan, so they don't belong in the standing activity plan.

Updates after the first one are destructive

--into deletes all pages of the existing deck before rebuilding it. Secure a version snapshot before running it:

.venv/bin/python scripts/snapshot_version.py "<デッキ URL>"

build_account_plan.py prints the pre-edit revision ID. To roll back, use "File → Version history" in the Slides UI.

What --into refuses (all of these are intended behavior):

Take the replace-target URL from the ledger's meta.decks.activityPlan. When pasting a URL by hand, always confirm it's a generated deck, not the master.

6. Annual / half-year review (APS)

The annual/half-year account review and executive review materials belong to scalar-account-planning-session. Its input is not the ledger but accounts/<AE>/<customer>/aps.json, built by adding the customer's public information (mid-term business plan, org chart, executive roster) to the ledger.

This skill does not go that far. The ledger (§1–4) is a prerequisite for APS, so bring the ledger up to date first, then hand off to the APS side.

7. When there are more than 9 stakeholders

Don't cram them onto a slide. As with b2b-account-maps's default, output the whole graph to draw.io and put an extracted version on the slide, always noting the number of people dropped and where to find the full version (the more slot).

Decide the layout first. The default tree layout spreads horizontally by the number of roots. With many roots, like a corporate group, it becomes an unreadable band (49 people at 18,000 × 709px).

# 企業グループ。people[].entity ごとの枠に格子で並べ、法人をまたぐ線は枠の外を通す
.venv/bin/python scripts/build_account_graph.py <graph.json> --layout grouped \
    --title "<顧客> インフルエンスマップ（全体）" \
    --out out/account-plan/<顧客>/influence-map-full.drawio

# 1 社なら既定のままでよい
.venv/bin/python scripts/build_account_graph.py <graph.json> \
    --out out/account-plan/<顧客>/influence-map-full.drawio

# PNG に書き出す（drawio CLI が要る）
drawio -x -f png -s 2 -b 8 \
    -o out/account-plan/<顧客>/influence-map-full.png \
       out/account-plan/<顧客>/influence-map-full.drawio

• entity is the legal-entity name (entityOrder sets the frame order). Use the same unit as the org chart
• For connections between people (links), put only the number on the line and list the wording below the diagram. A label placed on the line itself overlaps the card the longer the line gets, and becomes unreadable
• Always put the .drawio and PNG in the deck's Drive folder. A PNG alone can't be edited

8. Account-plan visual checks

Apply the shared QA procedure. In addition, check:

• On the influence map, does the person to move next catch the eye first (squint test)?
• Do table rows overlap the logo band at the bottom edge?
• Do person labels hide each other? If so, fix the coordinates in the ledger (not the template)

9. Report, together with Drive

.venv/bin/python scripts/scalar/account_workspace.py ensure --ledger <account.json>
.venv/bin/python scripts/drive_folder.py upload <00_活動計画 の ID> \
    accounts/<AE>/<顧客>/account.json out/account-plan/<顧客名>/action-plan.md

Always include in the report:

1. The deck URL and the Drive folder URL
2. The stage/forecast and its basis
3. The shortest list of what to confirm next (who, by when, and what completion looks like)
4. If any page was dropped for insufficient material, its name and what's missing

Item 3, not the URL, is the point of the report. The deck is a means; the AE's next action is the deliverable.

Rules

• The ledger is the source of truth. Never edit the deck directly. If something needs fixing, fix the ledger and rebuild.
• Never replace the CRM. Stage, amount, expected date, and Next Action live in the CRM as the source of truth. When you update the ledger, keep the CRM in sync too (playbook §8).
• Evidence, or else unconfirmed. confirmed and met require a source (who, when).
• Never fill in an answer. A blank is the AE's next action, not a hole to fill.
• An outdated activity plan is worse than none. If it can't be kept updated, retire the ledger along with it.
• Do not commit accounts/ or config/ (they contain customer names, personal names, and judgments). Keep working files under the gitignored out/.