Use Case

Business Process Automation

Automate the boring parts of operations without giving up control: intake, routing, checklists, documentation, and approvals — all as code.

The “Tuesday” problem

A small business gets a steady stream of operational pings: “please refund this,” “delete my data,” “someone logged in from a weird location,” “why did the site go down,” “can you send an invoice copy.” None of it is intellectually hard — it’s hard because it’s constant, interrupt-driven, and full of rules that only exist in someone’s head.

The goal of business process automation is not to replace people. It’s to make sure that the right steps happen every time: the request is categorized, the checklist is followed, the documentation is captured, and risky actions require an explicit approval.

Where agents shine

  • Intake + routing: turn messy language into an explicit work queue.
  • Policy + checklists: “Don’t escalate until fields X/Y/Z exist” is enforceable code.
  • Audit trails: capture what happened, why, and who approved side effects.
  • Iteration: add new detectors as new regulations and failure modes appear.

A simple, high-leverage automation

Start with something boring and measurable: classify inbound requests and return a structured plan. This is “just routing,” but it’s the beginning of a defensible operations workflow: the output is constrained, testable, and easy to extend.

The example below shows an operations router that buckets requests into explicit labels like privacy_request or security_alert, then emits a short plan that humans (or downstream agents) can execute. The important part is the contract: if your output is always one of a fixed set of labels, you can build reliable automation around it.

Real-world example

A finance ops workflow processing ~100 Stripe refunds/day started as a supervised Claude Skill, then got hardened into governed automation with tool use, human checkpoints, and audit trails. Read the case study.

-- Business Process Automation (SMB-friendly)
--
-- Pattern:
--   1) Normalize intake (email/chat/forms)
--   2) Classify into explicit workflow buckets
--   3) Return a structured "next action" plan
--   4) Add guardrails: validation + specs + evals

Procedure {
  input = {
    channel = field.string{required = true, description = "Where it came from: email | chat | form"},
    message = field.string{required = true, description = "Raw customer or internal message"}
  },
  output = {
    case = field.string{required = true, description = "One of: privacy_request, security_alert, billing_dispute, support, other"},
    priority = field.string{required = true, description = "One of: low, normal, high"},
    next_steps = field.string{required = true, description = "Short structured plan for a human or downstream agent"}
  },
  function(input)
    local classify_case = Classify {
      name = "bpa_router",
      method = "llm",
      classes = {"privacy_request", "security_alert", "billing_dispute", "support", "other"},
      prompt = [[
You triage operational requests for a small business.

Return only one label:
- privacy_request: GDPR/CCPA "delete my data", "forget me", "data access request"
- security_alert: suspicious login, phishing, compromise, ransomware, leaked credentials
- billing_dispute: invoice dispute, refund, chargeback, double charged
- support: regular product/service support
- other: anything else
]],
      model = "openai/gpt-4o-mini",
      temperature = 0,
      max_retries = 3
    }

    local classify_priority = Classify {
      name = "bpa_priority",
      method = "llm",
      classes = {"low", "normal", "high"},
      prompt = [[
Assign priority (low, normal, high) based on urgency and risk.
High for security incidents or regulatory deadlines.
Return only one label.
]],
      model = "openai/gpt-4o-mini",
      temperature = 0,
      max_retries = 3
    }

    local c = classify_case(input.message).value
    local p = classify_priority(input.message).value

    if c == "privacy_request" then
      return {
        case = c,
        priority = "high",
        next_steps = "Open a privacy case. Confirm identity. Record request type (delete/access). Locate systems of record. Start an evidence log. Prepare an approval before deleting anything."
      }
    end

    if c == "security_alert" then
      return {
        case = c,
        priority = "high",
        next_steps = "Open a security incident. Preserve logs. Identify affected accounts/systems. Rotate exposed credentials. Prepare a containment plan and request approval for disruptive actions."
      }
    end

    if c == "billing_dispute" then
      return {
        case = c,
        priority = p,
        next_steps = "Open a billing ticket. Gather invoice IDs and payment processor evidence. Propose a resolution (refund/credit/explain) and request approval before issuing credits."
      }
    end

    if c == "support" then
      return {
        case = c,
        priority = p,
        next_steps = "Route to support. Ask for missing context (order ID, account email, screenshots). Suggest troubleshooting steps from the runbook."
      }
    end

    return {case = "other", priority = "normal", next_steps = "Route to an operations inbox with a short summary and recommended owner."}
  end
}

Guardrails to add next

  • Validation: enforce the label set and required output fields.
  • Behavior specs: lock down “must ask for approval before deletion/refunds.”
  • Evaluations: measure accuracy and drift on a real inbox dataset.

If you want a runnable, end-to-end example of the same pattern, start with Text Classification.

Next: agent-based incident response

See how the same automation patterns apply to IT service management and escalation.