Customer-facing department playbook

This playbook illustrates how the agent blueprint pattern applies to a department whose primary job is handling inbound communication from outside the organisation — enquiries, complaints, status requests, and similar interactions. The department type is generic; you might recognise it as a customer service team, a client success function, or a frontline support desk. Use this as a reference when mapping the blueprint to your own equivalent department. Every placeholder (“Department A”, “VM-1”, “your CRM”) stands in for the real names you would substitute during a scoping engagement.

This playbook describes a structural pattern, not a finished implementation. Exact scope, timelines, and fit for your situation are determined during the consulting process. See Scope & Boundaries for how scoping works.

Department profile

Dimension	Example value
Department name	Department A (customer-facing)
Primary role	Receive, classify, and resolve inbound external communication
Primary input sources	Shared email inbox, web contact form, internal ticket queue
Primary outbound interfaces	Your CRM, shared email outbox, escalation notification channel
VM designation	VM-1

Role definition

Before any SOP is written, the agent needs a clear role statement — a single sentence that defines what it is responsible for and, equally, what it is not. For a customer-facing department this might read:

VM-1 is responsible for receiving, classifying, and resolving routine inbound messages from external contacts. It does not make commercial commitments, issue credits, or access account payment data.

This role statement is the foundation everything else is built on. It determines which SOPs the agent follows, which tools it is permitted to use, and where its escalation boundaries sit. See What is an agent? for more on how role definitions shape agent behaviour.

Standard operating procedures

The agent follows SOPs defined during the design phase. For a customer-facing department, a minimal SOP set typically covers the following situations:

SOP 1: Classify inbound message

Trigger: A new message arrives in the monitored input source (e.g. shared inbox or contact form submission).Steps:

Read the full message content.
Assign one of the defined categories: status enquiry, complaint, general question, escalation required, or unclassified.
Log the classification against the message record in your CRM.
Route to the appropriate next SOP based on category.

Escalation rule: If the message cannot be confidently classified, route to the human review queue rather than guessing.

SOP 2: Resolve a status enquiry

Trigger: Inbound message classified as “status enquiry”.Steps:

Extract the reference identifier from the message (e.g. order number, case reference, account ID).
Look up the current status in the connected system (e.g. your ERP system or CRM).
Compose a reply using the approved response template for status updates.
Send the reply from the shared outbox.
Update the CRM record with the action taken and timestamp.

Escalation rule: If the record cannot be found or the status is in an exception state, route to the human review queue with a summary of what was found.

SOP 3: Handle a complaint

Trigger: Inbound message classified as “complaint”.Steps:

Acknowledge receipt using the approved acknowledgement template. Do not attempt to resolve at this step.
Log the complaint in your CRM with category, contact details, and message content.
Assign a severity level (standard or elevated) based on the defined criteria in the SOP configuration.
Route to the human review queue with the classification and a draft response for the responsible team member to review and send.

Escalation rule: All complaints route to a human before any substantive response is sent. The agent drafts; a person approves.

SOP 4: Handle unclassified or out-of-scope messages

Trigger: Inbound message classified as “unclassified” or containing a request outside the agent’s defined role.Steps:

Send an acknowledgement to the sender confirming the message was received.
Route the full message to the human review queue flagged as “requires manual triage”.
Log the routing action in your CRM.

Escalation rule: The agent never attempts to respond to messages it cannot confidently classify.

Input sources

The agent monitors the following input sources. During setup, each source is connected and tested before go-live.

Input source	What it delivers	Format
Shared email inbox	Inbound external messages	Unstructured text
Web contact form	Submitted enquiries	Structured JSON fields
Internal ticket queue	Escalations from other departments	Structured ticket objects

Input source configuration is covered in Agent Structure → Integrations.

Outbound interfaces

The agent writes to the following systems as outputs of its SOPs. It only writes to systems explicitly connected and approved during setup.

Outbound interface	What the agent writes	Requires human approval?
Your CRM	Classification logs, contact records, action history	No
Shared email outbox	Status replies using approved templates	No (for status SOPs), Yes (for complaints)
Escalation notification channel	Human review queue items with full context	N/A (routing only)

Escalation rules

Escalation rules are configured as hard limits in the agent’s guardrails layer. For this department archetype, the following situations always result in a human handoff regardless of any other condition:

Complaint messages of any kind
Messages referencing payment, refunds, or credits
Messages where classification confidence is below the defined threshold
Messages from contacts marked as “VIP” or “sensitive” in your CRM
Any message that generates an error during CRM lookup

When an escalation is triggered, the agent passes the full message, the classification result, any CRM data retrieved, and a plain-language summary to the human review queue. The contact receives an acknowledgement confirming their message was received. See Agent Structure → Components for how guardrails and handoff rules are configured.

JSON message flow (simplified)

Each SOP step produces a structured message passed to the next step or to an outbound interface. A simplified example for a status enquiry:

{
  "event": "inbound_message",
  "source": "email_inbox",
  "contact_ref": "CONTACT-0001",
  "message_id": "MSG-20240801-004",
  "classification": "status_enquiry",
  "extracted_reference": "ORDER-00123",
  "lookup_result": "found",
  "action_taken": "reply_sent",
  "template_used": "status_update_v2",
  "escalated": false,
  "timestamp": "2024-08-01T09:14:00Z"
}

This record is written to your CRM as an activity log entry. Every step the agent takes is traceable back to a specific SOP and a specific input event.

Staged evolution

This department typically starts narrow and expands in defined phases:

Phase	What is automated	What remains manual
Phase 1	Classification and logging only	All replies
Phase 2	Status enquiry replies added	Complaints, escalations
Phase 3	Complaint acknowledgement added	Resolution and credits

Starting at Phase 1 lets the team validate the classification SOP before any outbound action is taken. This is the recommended approach for any department where outbound errors carry reputational risk.

Cross-references

What is an agent? — role definitions and the three layers of every agent
Agent Structure → Overview — inputs, intelligence, and actions
Agent Structure → Components — guardrails and handoff rules
Agent Structure → Integrations — connecting input sources and outbound interfaces
Scope & Boundaries — how the scope of a department agent is defined and controlled

Get Started

Agent Structure

Implementation Blueprint

Small Business Playbooks

Consulting Process

Customer-Facing Department Playbook

Customer-facing department playbook

Department profile

Role definition

Standard operating procedures

Input sources

Outbound interfaces

Escalation rules

JSON message flow (simplified)

Staged evolution

Cross-references

​Customer-facing department playbook

​Department profile

​Role definition

​Standard operating procedures

​Input sources

​Outbound interfaces

​Escalation rules

​JSON message flow (simplified)

​Staged evolution

​Cross-references

Customer-facing department playbook

Department profile

Role definition

Standard operating procedures

Input sources

Outbound interfaces

Escalation rules

JSON message flow (simplified)

Staged evolution

Cross-references