# Request to Dispatch

A service request has to be understood, enriched with asset and contract history, checked against SLA and parts availability, and assigned — before anyone can actually fix anything.

## About this page
- Canonical: https://quarkcs.io/automation-blueprints/service-operations
- Type: AutomationBlueprint
- Published: 2026-09-06
- Updated: 2026-09-06

## Problem
A service request has to be understood, enriched with asset and contract history, checked against SLA and parts availability, and assigned — before anyone can actually fix anything.

## Agent Loop
- Trigger: A service request arrives by phone log, portal or email.
- Context: Customer, asset history, warranty and contract terms, SLA clock, technician skills and rota, parts stock.
- Agent: Classify the fault, pull the asset's history and propose an assignment or escalation with reasoning.
- Policy: SLA breach risk, warranty status and technician certification are checked deterministically.
- Human checkpoint: A dispatcher confirms any assignment that breaches SLA or needs an uncertified technician.
- Action: Create the assignment, reserve parts and notify the technician and customer.

## Tools
- read_asset_history
- read_sla
- search_technicians
- read_parts_stock
- create_assignment

## Flow
1. Request received
2. Classify fault
3. Pull asset and contract context
4. Check SLA and parts
5. Confirm exception (human approval)
6. Create assignment and reserve parts
7. Notify technician and customer

## Systems
- ERPNext
- Framework M
- SMS gateway
- Email

## Framework M DocTypes
- Customer
- Asset
- Service Level Agreement
- Issue
- Stock Entry