FEATURED WORK
AI Intake System
Turning unstructured inbound requests into structured operational intake.
- Context
- FIELD-SERVICE OPERATIONS
- Context
- AI SYSTEMS ENGINEERING
- Evidence
- TESTED · VALIDATED PENDING
Axiom designed and built a bounded AI intake workflow for a field-service operation where the general inbox receives work orders, estimate requests, vendor invoices, and other operational messages that must be interpreted and routed appropriately.
The system monitors incoming email, classifies the message, extracts relevant customer and job information, and creates structured intake data for human review. Its defined classifications include service requests, estimate requests, existing job follow-ups, vendor invoices, subcontractor messages, spam or marketing, other messages, and uncertain cases requiring human review.
EVIDENCE STATUS
- BUILT
- Achieved
- TESTED
- Achieved
- VALIDATED
- Pending verification
- PILOT
- Not achieved
- DEPLOYED
- Not achieved
- MEASURED
- Not achieved
This case study documents engineering and validation work. It does not claim production deployment or measured business impact.
THE OPERATION
One inbox can contain several different kinds of work.
The existing email workflow receives multiple types of operational communication, including work orders, estimate requests, vendor invoices, and messages that require the owner’s review.
Relevant items then need to move into the appropriate downstream process.
That creates an intake problem before it creates an AI problem.
Each message has to be understood:
- What kind of message is this?
- Is it a service or estimate opportunity?
- What information did the sender provide?
- What information is missing?
- Does someone need to review it?
- Where should it go next?
Before a workflow can be automated safely, the system has to understand what entered the workflow in the first place.
BEFORE THE SYSTEM
Intake begins with interpretation.
The general inbox acts as an operational entry point. Work orders and estimate requests arrive alongside invoices and other messages. Items then have to be identified, reviewed, and routed into the appropriate business process.
The engineering opportunity was not simply to automate email. It was to create a more structured intake layer around the inbox.
- INCOMING EMAIL
- READ MESSAGE
- IDENTIFY INTENT
- IDENTIFY RELEVANT INFORMATION
- DECIDE WHAT NEEDS REVIEW
- ROUTE TO THE NEXT PROCESS
THE OBJECTIVE
Give incoming email a structured path forward.
The system was given one defined mission:
Monitor incoming emails, identify legitimate service or estimate requests, extract relevant information, and create a structured lead for human review.
The system was designed to extract fields such as:
- sender information
- service address
- requested service
- urgency
- requested date
- work-order number
- summary
- missing information
- confidence
- recommended next action
This creates a predictable structure from information that originally arrived as free-form email.
SYSTEM BOUNDARY
The first version was deliberately limited.
In Scope
The system can:
- monitor incoming test email
- classify messages
- identify service and estimate requests
- extract relevant customer and job information
- identify missing information
- assign a confidence value
- recommend a next action
- route ambiguous cases to human review
- preserve the original message for verification
- structure intake information for downstream review
Out of Scope
Version 1 does not:
- invent missing customer information
- classify an email as a confirmed job
- promise pricing
- promise availability
- promise completion dates
- automatically respond to customers
- treat attachments or links as trusted by default
- use the production inbox
- automatically schedule work
- approve jobs
- modify the client’s field-management system
Capability is only useful when authority is clearly defined.
ARCHITECTURE
From free-form email to structured operational data.
The workflow separates message interpretation from downstream action.
- TEST GMAIL INBOX
- MESSAGE INGESTION
- CLASSIFY MESSAGE
- EXTRACT STRUCTURED INFORMATION
- EVALUATE CONFIDENCE + MISSING DATA
- CLEAR ENOUGH?
- YESSTRUCTURED RECORD
- NOHUMAN REVIEW
The structured record is designed around fields such as:
- classification
- confidence
- sender information
- service address
- service requested
- urgency
- summary
- missing information
- recommended action
- review status
- original email link
Uncertainty is routed, not ignored.
ENGINEERING DECISIONS
The architecture was shaped by the risks of the workflow.
- 01
Why Classify Before Routing?
Because the inbox contains several different types of messages. A service request, vendor invoice, existing-job follow-up, subcontractor message, and marketing email should not all follow the same operational path.
The classification scheme was defined before downstream routing was built.
- 02
Why Structured Extraction?
Because downstream workflows need predictable fields.
Instead of passing around a free-form AI response, the system captures specific operational information such as service address, requested service, urgency, missing information, and recommended next action.
- 03
Why Preserve the Original Email?
Because extracted information should remain verifiable against its source.
The original email remains available for review.
- 04
Why Human Review?
Because not every message provides enough information for the system to act confidently.
The classification model explicitly includes an uncertain state requiring human review.
- 05
Why Use a Test Environment First?
Because production access should be earned through validation.
The first version proves the workflow in a controlled environment before production access.
HUMAN REVIEW
The system has somewhere to send uncertainty.
The system was not designed to force every email into a confident answer.
Ambiguous messages are routed for human review rather than silently converted into operational records. The system is also prevented from inventing missing customer information.
A system that can recognize uncertainty is more useful than one that only knows how to sound confident.
- INCOMING MESSAGE
- CLASSIFY + EXTRACT
- ENOUGH INFORMATION?
- YESSTRUCTURED INTAKE
- NOHUMAN REVIEW
VALIDATION
The system was tested against defined cases, not just a successful demo.
The original specification established test scenarios covering different message types, including:
- clear service request
- estimate request
- existing-job follow-up
- vendor invoice
- marketing message
- ambiguous request requiring interpretation
The purpose of those cases was to verify whether classification, extraction, routing, and review behavior matched the expected system design.
Validation Loop
- DEFINE EXPECTED BEHAVIOR
- RUN TEST CASE
- COMPARE ACTUAL OUTPUT
- PASS / FINDING
- REFINE SYSTEM
A successful demo shows possibility. Validation builds confidence.
ITERATION
Testing is supposed to find problems.
Axiom treats unexpected behavior as an engineering finding, not something to hide.
When classification, routing, extraction, or system behavior differs from the intended design, the finding should be documented, corrected, and tested again.
Finding a weakness during validation is evidence that the validation process is doing its job.
RESULTS
What the current evidence supports.
- BUILT
- A functioning intake workflow was implemented around the defined mission and structured data model.
- TESTED
- Defined message scenarios were used to exercise multiple classification and intake conditions.
- VALIDATED
- Pending verification
EVIDENCE STATUS
- BUILT
- Achieved
- TESTED
- Achieved
- VALIDATED
- Pending verification
- PILOT
- Not achieved
- DEPLOYED
- Not achieved
- MEASURED
- Not achieved
LIMITATIONS
What this work does not prove yet.
A controlled test can establish system behavior. It cannot substitute for operational evidence that has not yet been collected.
The current evidence does not establish:
- long-term production reliability
- performance against the client’s full real-world email distribution
- measured reduction in administrative time
- measured response-time improvement
- measured financial return
- safe autonomous customer communication
- production readiness for every downstream business action
WHAT COMES NEXT
Move from controlled validation toward operational evidence.
Future versions will depend on real email patterns, sanitized examples, sender behavior, required downstream information, review ownership, urgency expectations, attachment patterns, and known mistakes in the current process.
Future capability remains future capability until it is built and validated.
Potential future work may include:
- controlled pilot use
- validation against sanitized real-world messages
- expanded routing behavior
- improved human-review workflows
- deeper downstream integration where justified
- operational performance measurement
- carefully bounded increases in system responsibility
START AN ASSESSMENT
Have a workflow that depends on people interpreting the same information over and over?
Tell us where the process is creating friction.
Axiom will start by understanding how the work happens today, what decisions are involved, and whether there is a practical systems opportunity worth pursuing.