business-operations-skills

---
name: business-operations-skills
description: Use when diagnosing or designing internal business operations: process bottlenecks, vendor SLAs, capacity planning, internal comms, SOP/runbook authoring, or procurement spend.
category: Business Operations
version: 1.0.0
tools: []
---

# Business Operations Overview

Internal operations — how a company actually runs, as distinct from external go-to-market motion. This skill covers six internal-ops domains and how to diagnose which one applies to a given problem.

## The Six Domains

Process mapping addresses work that stalls or waits between handoffs (bottleneck diagnosis, cycle time, workflow analysis). Vendor management addresses a vendor possibly missing its SLA (SLA tracking, contract renewal, third-party risk tiering). Capacity planning addresses whether headcount matches demand (queueing math, utilization, hiring sequencing). Internal comms addresses a change that needs to be announced internally (change-management messaging, all-hands, FAQs). Knowledge ops addresses SOPs or runbooks that are missing or stale (SOP authoring, runbook validation, KB hygiene). Procurement optimization addresses software or vendor spend that looks bloated (spend categorization, supplier rationalization).

## Routing signals

Classify the inquiry by keyword signals; a strong match on two or more signals is enough to proceed confidently, one signal warrants a single clarifying question.

Process signals: bottleneck, cycle time, waiting, handoff, process map, workflow. Vendor signals: vendor, supplier, SLA, contract, third-party, MSA, subscription, renewal. Capacity signals: headcount, capacity, utilization, planning, hiring sequence, FTE. Comms signals: all-hands, internal newsletter, announcement, change management, FAQ, town hall. Knowledge signals: SOP, runbook, knowledge base, wiki, playbook, documentation, onboarding doc. Procurement signals: spend, procurement, purchase, supplier rationalization, software audit, spend sprawl.

If the inquiry legitimately spans two domains (e.g., "vendor SLA + spend audit" = Vendor + Procurement), address the higher-confidence domain first, deliver findings, then explicitly ask whether to proceed into the second domain rather than silently chaining into it.

## Working discipline: explore, then ask one question at a time

Before asking a clarifying question, check whether the inquiry already disambiguates the domain from context (e.g., "vendor SLA review" needs no question). If the domain is still ambiguous, ask exactly one forcing question naming the two most likely candidates, paired with a recommended answer and a one-sentence rationale — never bundle multiple questions, and never default to "what do you think?" without offering a recommendation. Wait for confirmation before proceeding.

Within a domain, continue this discipline for the decisions that shape the analysis — one question per turn, each with a recommended default and, where relevant, a citation to the underlying framework. Examples: in process mapping, ask whether cycle times are measured or estimated (insist on measured data for the top three longest stages — mapping estimates optimizes the wrong constraint, per Goldratt's Theory of Constraints); in vendor management, ask whether criticality tiering is by spend or by operational dependency (recommend operational dependency — spend-only tiering misses critical low-spend vendors); in capacity planning, ask whether the target is utilization or throughput (recommend throughput via Little's Law — planning to more than 80% utilization destroys throughput through queueing effects).

## Reporting back

After analysis, return a concise digest: what was analyzed; the top three findings, each anchored in a named framework or citation (e.g., "Theory of Constraints: optimize the bottleneck, not the non-constraint"); the top three next actions with owners where possible; and one pointed challenge back to the user, grounded in a cited benchmark (e.g., "a 12% value-add ratio is classified as waste-heavy under lean canon (Womack & Jones) — what's blocking process redesign: political, technical, or budget?").

## Assumptions

The organization has roughly 10+ employees — smaller teams rarely need formal BizOps analysis. The user has or can get access to the underlying data (process timings, vendor list, spend export) — work with reasonable estimates if not, but say so explicitly. Favor deterministic, repeatable analysis grounded in named frameworks over unanchored prose.

## Distinct from

External sales motion (customer success, sales engineering, revenue operations) is a different surface — this skill is internal-only. Strategic executive judgment ("should we restructure?") is also different — this skill is tactical (here is the process map with bottlenecks), not strategic.

## Anti-patterns

Do not analyze all six domains "to be thorough" — pick one based on signal strength, report findings, let the user decide whether to chain into another. Do not silently decide a vendor or process change — surface findings and let the human decide. Do not propose overwriting existing process documentation — propose the change and let the user approve it. Do not skip the concise-digest step in favor of dumping the full analysis.