Monitor capital projects and plant investment signals for sales timing
Collect and qualify expansion, brownfield, line-launch, permit, incentive, hiring, equipment, and capacity signals into a governed plant-level buying-window monitor.
What you will have
A continuously refreshed plant-investment signal register with evidence, confidence, product relevance, urgency, account owner, and seller action.
Setup time
10-14 hours
Time saved
10-18 hours per month
Estimated cost
$150 to $900 per month
Tools used
4 tools
Why this works
Plant investment signals become useful only when they are linked to a canonical company, site, program, timing window, and plausible operational need. The automation removes repetitive collection work while explicit evidence, deduplication, expiry, and human qualification prevent a press-release feed from being mistaken for purchase intent.
Step-by-step workflow
Preview the workflow
The first 2 steps are open. Pro unlocks the remaining steps, copy-paste prompts, pro tips, tool-by-tool setup guidance, and implementation details.
1
Define the monitored market and signal taxonomy
45-60 min
45-60 min
Use Airtable to set account, geography, industry, program, plant, project, source, language, and time-window boundaries plus signal classes. Create or update the exact fields `monitor_id`, `account_scope`, `geography`, `industry`, `signal_type`, `source_tier`, `language`, `lookback_days`, `expiry_days`, `owner`, retaining the native account, opportunity, contact, site, program, requirement, and source IDs instead of matching on display names alone. Apply the operating rule that only in-scope sources and signal classes enter the production monitor and every class has an expiry rule, and write every proposed change to a dated change log rather than replacing the prior approved value. Validate the work by testing sample articles against inclusion, exclusion, and expiry rules and resolving ambiguous cases; assign each warning or exception an owner, severity, due date, and evidence link, and hold records that fail the check. The completion gate is sales leadership and research ownership approval of scope and taxonomy; document the rollback or fallback path if the source is unavailable, the connector fails, or the buyer disputes the record.
Output
An approved monitoring charter and signal taxonomy.
Airtable
Pro tip
Separate confirmed investment, proposed investment, rumor, and hiring proxy; they imply different confidence and timing.
2
Create the versioned plant-signal Claude Project
45-60 min
45-60 min
Use Claude and Airtable to package extraction rules, site and account dictionaries, relevance rubric, examples, source register, test cases, and changelog. Create or update the exact fields `project_version`, `instructions_file`, `field_dictionary`, `entity_dictionary`, `relevance_rubric`, `source_register`, `test_cases`, `changelog`, `owner`, retaining the native account, opportunity, contact, site, program, requirement, and source IDs instead of matching on display names alone. Apply the operating rule that the project contains stable folders and required files with `vYYYY.MM` naming, primary and backup owners, refresh policy, tests, and maintenance calendar, and write every proposed change to a dated change log rather than replacing the prior approved value. Validate the work by running ten historical signals through the package and comparing classification to expert judgment; assign each warning or exception an owner, severity, due date, and evidence link, and hold records that fail the check. The completion gate is the research owner approving the production version; document the rollback or fallback path if the source is unavailable, the connector fails, or the buyer disputes the record. Run this template in Claude within the approved plant-signal Claude Project after attaching the source records named for this step; store the returned JSON beside the source register before any downstream action. Maintain the Claude Project with `instructions.md`, `field-dictionary.json`, `source-register.csv`, `review-rubric.md`, `approved-examples.md`, and `changelog.md`; name releases `vYYYY.MM`, assign a primary and backup owner, refresh source exports before each operating review, and review permissions and maintenance quarterly.
Output
A maintained signal-analysis workspace with repeatable rules.
ClaudeAirtable
Pro tip
Include both strong and deceptive examples, such as headquarters announcements that do not identify the affected plant.
Prompt template
ROLE
You are the governed sales-execution analyst supporting an industrial enterprise account executive or territory manager. You work inside the “Monitor capital projects and plant investment signals for sales timing” operating system, where source traceability, stable CRM identifiers, buyer-safe language, and human authority are more important than producing a polished but unsupported answer.
OBJECTIVE
Complete workflow step 2, “Create the versioned plant-signal Claude Project,” and produce this operational outcome: A maintained signal-analysis workspace with repeatable rules. Execute only this step; do not silently broaden the task, fabricate buyer facts, or make external changes.
INPUTS
1. APPROVED SOURCE RECORDS: {{create_the_versioned_plant_signal_claude_project_source_records}}
2. FIELD DICTIONARY AND ALLOWED VALUES: {{create_the_versioned_plant_signal_claude_project_field_dictionary}}
3. ACCOUNT, OPPORTUNITY, OR PROGRAM CONTEXT: {{create_the_versioned_plant_signal_claude_project_deal_context}}
4. OPERATING RULES, PERMISSIONS, AND APPROVAL MATRIX: {{create_the_versioned_plant_signal_claude_project_operating_rules}}
5. PRIOR APPROVED VERSION OR CURRENT STATE: {{create_the_versioned_plant_signal_claude_project_prior_state}}
6. DEADLINES, OWNERS, AND REVIEW CADENCE: {{create_the_versioned_plant_signal_claude_project_approval_context}}
WORK TO PERFORM
1. Perform the exact job described by “Create the versioned plant-signal Claude Project” using the supplied IDs and field names.
2. Separate observed facts, direct buyer statements, operator-entered decisions, calculations, and model inferences.
3. Preserve account_id, opportunity_id, contact_id, site_id, program_id, requirement_id, source_id, owner, and effective_date whenever supplied; do not merge records merely because names look similar.
4. Populate the requested fields, identify missing values, and flag contradictions, stale evidence, duplicate entities, unsupported claims, permission issues, and dependencies.
5. Return records that can be copied into the declared system of record without renaming identifiers, flattening one-to-many relationships, or overwriting an approved value.
6. Provide a compact change summary, exception queue, approval request, and next-action list with owner and due date.
7. Apply the step-specific instructions: package extraction rules, site and account dictionaries, relevance rubric, examples, source register, test cases, and changelog.
OUTPUT SCHEMA
Return valid JSON only with this exact top-level structure:
{
"workflow_slug": "capital-project-plant-investment-signal-monitor",
"step_number": 2,
"step_title": "Create the versioned plant-signal Claude Project",
"run_status": "pass|warning|hold|fail",
"source_register": [{"source_id":"string","source_type":"string","captured_at":"ISO-8601|null","authoritative":true,"notes":"string|null"}],
"records": [{
"project_version": "value|null",
"instructions_file": "value|null",
"field_dictionary": "value|null",
"entity_dictionary": "value|null",
"relevance_rubric": "value|null",
"source_register": "value|null",
"test_cases": "value|null",
"changelog": "value|null",
"owner": "value|null",
"evidence_source_ids": ["string"],
"confidence": "high|medium|low",
"review_status": "approved|needs-review|held"
}],
"exceptions": [{"record_id":"string|null","exception_type":"string","severity":"low|medium|high|critical","evidence":"string","owner":"string","required_action":"string"}],
"changes_from_prior_state": [{"record_id":"string","field":"string","prior_value":"value|null","proposed_value":"value|null","reason":"string","source_ids":["string"]}],
"review_summary": {"facts":["string"],"inferences":["string"],"open_questions":["string"],"next_actions":[{"action":"string","owner":"string","due_date":"YYYY-MM-DD|null"}]},
"qa": {"schema_valid":true,"ids_preserved":true,"evidence_complete":true,"human_approval_required":true}
}
GUARDRAILS
- Treat the supplied field dictionary, approval matrix, security policy, commercial rules, and prior approved state as binding.
- Do not invent quotes, dates, metrics, relationships, customer permissions, product capabilities, legal positions, security answers, pricing authority, or approvals.
- Do not perform, simulate, or claim an external write. Return proposed records or actions for the named operator or governed automation to apply.
- Do not collapse conflicting evidence into one confident statement. Preserve each source and route the conflict to the exception queue.
- Do not expose confidential margin, personal data, security detail, or contract language to an audience not authorized in the inputs.
- Mark any record that could change scope, price, legal obligations, security posture, implementation effort, or buyer commitment as human-approval-required.
EVIDENCE REQUIREMENTS
- Every material claim must cite one or more supplied source_id values and include the source date when available.
- Direct buyer statements must remain distinguishable from seller interpretation and model inference.
- Calculations must show inputs, units, formula, and rounding rule; relationships must show the evidence supporting the match.
- A record without adequate evidence must be marked needs-review or held, never approved by default.
UNCERTAINTY HANDLING
- Use high confidence only for current authoritative records or direct, corroborated buyer evidence.
- Use medium confidence for a plausible interpretation supported by one credible source, and low confidence for hypotheses requiring validation.
- When two sources disagree, list both values, explain the conflict, and name the person who must resolve it.
- If required inputs are absent, return run_status “hold” and state exactly what is missing instead of guessing.
HUMAN REVIEW
The named operator must review the source register, exceptions, inferred fields, proposed changes, and audience permissions. Require explicit approval before any CRM write, buyer-facing publication, pricing or scope commitment, legal or security response, pilot promise, or external notification. Return the approval decision, reviewer, timestamp, rejected items, and required revisions in the final review summary.
Pro workflow preview
Previewing 2 of 13 steps
Pro membership
Unlock the full workflow
Get the remaining 11 steps, copy-paste prompts, pro tips, tool-by-tool setup guidance, and weekly new workflows.
$9/month
Build the canonical account, site, and program tables
Configure Feedly sources and collection queries
Design the n8n trigger and credential model
Map and normalize incoming signal payloads
Deduplicate articles, announcements, and repeated signals