> ## Documentation Index
> Fetch the complete documentation index at: https://docs.m9tz.de/llms.txt
> Use this file to discover all available pages before exploring further.

# Customer-Facing Department Playbook

> See how the agent blueprint applies to a customer-facing department — role definition, SOPs, input sources, escalation rules, and outbound interfaces.

# 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.

<Note>
  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](/consulting/scoping) for how scoping works.
</Note>

***

## 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?](/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:

<Accordion title="SOP 1: Classify inbound message">
  **Trigger:** A new message arrives in the monitored input source (e.g. shared inbox or contact form submission).

  **Steps:**

  1. Read the full message content.
  2. Assign one of the defined categories: status enquiry, complaint, general question, escalation required, or unclassified.
  3. Log the classification against the message record in your CRM.
  4. 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.
</Accordion>

<Accordion title="SOP 2: Resolve a status enquiry">
  **Trigger:** Inbound message classified as "status enquiry".

  **Steps:**

  1. Extract the reference identifier from the message (e.g. order number, case reference, account ID).
  2. Look up the current status in the connected system (e.g. your ERP system or CRM).
  3. Compose a reply using the approved response template for status updates.
  4. Send the reply from the shared outbox.
  5. 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.
</Accordion>

<Accordion title="SOP 3: Handle a complaint">
  **Trigger:** Inbound message classified as "complaint".

  **Steps:**

  1. Acknowledge receipt using the approved acknowledgement template. Do not attempt to resolve at this step.
  2. Log the complaint in your CRM with category, contact details, and message content.
  3. Assign a severity level (standard or elevated) based on the defined criteria in the SOP configuration.
  4. 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.
</Accordion>

<Accordion title="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:**

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

  **Escalation rule:** The agent never attempts to respond to messages it cannot confidently classify.
</Accordion>

***

## 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](/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](/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:

```json theme={null}
{
  "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?](/what-is-an-agent) — role definitions and the three layers of every agent
* [Agent Structure → Overview](/agent-structure/overview) — inputs, intelligence, and actions
* [Agent Structure → Components](/agent-structure/components) — guardrails and handoff rules
* [Agent Structure → Integrations](/agent-structure/integrations) — connecting input sources and outbound interfaces
* [Scope & Boundaries](/consulting/scoping) — how the scope of a department agent is defined and controlled