Small-Business Agent Setup: Intake, Follow-Up, and Stop Rules

A small business agent should remove waiting, copying, and forgotten follow-up. It should not quietly approve refunds, invent policy, send sensitive advice, or hold the only copy of a customer record.

Start with one bounded workflow: enquiry intake, qualification, draft follow-up, and human handoff. Add autonomy only after the receipts show where it is safe.

Kill the default approach: all-purpose assistants

The common setup connects email, calendar, CRM, documents, and payments to one broad prompt. The demo feels capable because every tool is available. The operating risk is hidden because no action has an owner, approval threshold, or retry rule.

Build one job with explicit states. The agent can classify and draft. A person approves consequential messages until measured evidence supports a narrower automation rule.

By the end you will have

1. A first workflow chosen by value and risk
2. An intake schema and state machine
3. Approval and stop rules
4. The Small-Business Agent Operating Card
5. A weekly scorecard for quality, speed, and exceptions

Choose the first job with a risk-value matrix

Score candidate jobs on frequency, waiting time, reversibility, data sensitivity, and cost of a wrong action.

Good first jobs:

• Turn a website enquiry into a structured CRM draft
• Summarize a support thread and propose a reply
• Prepare a meeting brief from approved sources
• Remind an owner about an unanswered qualified lead
• Draft a follow-up after a completed call

Poor first jobs:

• Send medical, legal, or financial advice
• Approve refunds or discounts without limits
• Delete records
• Publish public claims
• Move money or sign agreements

Pick work that is frequent, reviewable, and easy to reverse.

Model the workflow as states

A reliable agent knows what state it is in and which transitions are allowed.

received
  -> validated
  -> classified
  -> draft_ready
  -> human_approved
  -> sent
  -> follow_up_due
  -> closed
 
Any state -> needs_human
Any failure -> retry_wait or stopped

Store the state outside the chat transcript. A database, CRM, or durable job record should hold the customer, source, timestamps, owner, current state, and action receipts.

The model proposes a transition. Deterministic code checks whether that transition is allowed.

Make intake structured before adding intelligence

Define the minimum fields:

type Enquiry = {
  id: string;
  receivedAt: string;
  source: "website" | "email" | "telegram" | "referral";
  name: string;
  contact: string;
  company?: string;
  request: string;
  consentToContact: boolean;
  owner?: string;
};

Validate length, allowed values, contact format, and consent. Keep the raw message when policy allows, but do not let it become executable instruction. Customer input is untrusted data.

Separate facts from model output:

facts:
  source, submitted fields, CRM history
 
inference:
  topic, urgency, likely service, confidence
 
proposal:
  owner, next step, reply draft

That split makes review possible. A low-confidence classification can route to a person without losing the original enquiry.

Bind tools to narrow operations

Avoid a generic "send email" tool available in every state. Expose operations with their constraints:

• create_crm_draft(enquiry)
• draft_reply(enquiry, approved_facts)
• request_human_approval(draft, reason)
• send_approved_reply(approval_id)
• schedule_follow_up(record_id, allowed_window)

The send operation should require an approval object tied to the exact recipient, subject, and body hash. Editing the draft invalidates approval.

For retries, use one stable operation ID. A network timeout must not create two contacts or send two replies.

Write approval rules as policy

Require a human when:

• Confidence falls below the chosen threshold
• The customer asks about price exceptions, refunds, contracts, or regulated advice
• The reply makes a claim not present in approved sources
• A new recipient or external domain is involved
• The message contains sensitive personal data
• The workflow has retried more than its limit

Automatic actions may include classification, internal tagging, owner assignment, and draft creation when the input passes validation.

Keep approval in the interface people already use, such as the CRM, Slack, or Telegram. The approval record needs identity, time, action, and payload binding.

Create stop rules before schedules

An agent must stop when:

• Required data is missing
• A dependency returns an unexpected response
• The same operation fails repeatedly
• The next action would exceed a spend or message cap
• The source contains instructions that conflict with policy
• The customer opts out or the record is closed

Scheduled follow-up needs a maximum count, allowed hours, and a cancellation condition. "Follow up until they reply" is not an operating rule.

Magnet: Small-Business Agent Operating Card

# Small-Business Agent Operating Card
 
JOB
Workflow:
Owner:
Business outcome:
System of record:
 
INPUT
Allowed sources:
Required fields:
Sensitive fields:
Retention rule:
 
STATES
Start:
Allowed transitions:
Closed condition:
Needs-human condition:
 
ACTIONS
Automatic:
Approval required:
Forbidden:
 
LIMITS
Message cap:
Spend cap:
Retry cap:
Allowed hours:
 
RECEIPTS
Log action, actor, input reference, output hash, result, and timestamp.
 
MEASURE WEEKLY
Volume:
Median time to first useful draft:
Approval rate:
Correction rate:
Duplicate or failed actions:
Opt-outs or complaints:

You should see: a narrow job, named owner, durable state, bounded tools, explicit approvals, and a receipt for every external action.

Run a shadow week

For the first week, let the agent classify and draft without sending. Compare its proposals with the human's real actions.

Review:

• Correct route or owner
• Facts preserved without invention
• Tone and policy compliance
• Time saved before review
• Exceptions that need a rule, source, or product change

Do not automate because the average draft looks good. Inspect the worst cases and the cost of their failure.

Failure modes

When not to automate the workflow

• Volume is too low to justify setup and review
• The process changes every week
• No owner can approve exceptions
• The required source data is unreliable
• A wrong action creates regulated, financial, safety, or reputational harm that the proposed controls cannot contain

Use a checklist or template until the process stabilizes. Automation multiplies a process; it does not decide what the process should be.

Expand one permission at a time

After the shadow week, enable the lowest-risk external action. Keep the approval rule for everything else. Review weekly, then expand only when correction and exception patterns support it.

If an exception repeats, decide whether to improve the input schema, approved knowledge, deterministic policy, or human route. Do not respond by making the prompt longer each week.

Your next action: complete the Small-Business Agent Operating Card for one intake or follow-up job, then run it in shadow mode for a week.