GenAI-Powered Work Order Management System POC
ntt_data · Other · 2024 · source Agentic: no · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)
Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.
Problem
Domain: maintenance work-order classification
A large infrastructure company needed to improve the accuracy and consistency of work-order processing for housing-complex maintenance requests, where roughly 70 employees manually classified and prioritized about 1,500 work orders per day.
Constraints:
- the company tracks and responds to more than 500,000 maintenance requests annually
- manual classification created error risk and inconsistency in categorization and management
- the POC had to answer classification, urgency, and special-handling questions
- the client required a secure third-party environment with a privately hosted LLM
- the initial effort was a proof of concept, with full deployment dependent on consistent usefulness
Architecture
NTT DATA built a secure GenAI POC for work-order management in under two weeks. The system uses a privately hosted LLM and a knowledge base of documented policies, procedures, requirements, and more than 160 work-order categories to classify incoming maintenance requests, assign urgency, identify special-handling requirements, and provide reasoning for each classification as an audit trail. The client plans to use a custom application to update policies and clarifications so model behavior can improve over time.
Diagram confidence: reconstructed (reconstructed from prose).
flowchart LR work-order-notes["Work order notes"] --> privately-hosted-llm["Privately hosted LLM"] policy-and-category-knowledge-base["Policy and category knowledge base"] --> privately-hosted-llm custom-policy-application["Custom policy application"] --> policy-and-category-knowledge-base privately-hosted-llm --> classification-output["Classification output"] privately-hosted-llm --> reasoning-audit-trail["Reasoning audit trail"] classification-output --> work-order-processing-team["Work-order processing team"] reasoning-audit-trail --> work-order-processing-team
Components
| Component | Role | Interacts with |
|---|---|---|
Work order notes |
Operator and technician-entered information describing resident maintenance problems. | Privately hosted LLM |
Policy and category knowledge base |
Documented policies, procedures, requirements, and over 160 work-order categories used to guide classification. | Privately hosted LLM, Custom policy application |
Privately hosted LLM |
Secure model that classifies expertise, urgency, special handling, and reasoning for each incoming work order. | Classification output, Reasoning audit trail |
Classification output |
Structured answers for expertise required, urgency level, and special-handling requirements. | Work-order processing team |
Reasoning audit trail |
Explanation of why each work order was categorized a certain way, used for accountability and process insight. | Work-order processing team |
Custom policy application |
Planned long-term interface for adjusting policies and adding clarifications for the LLM. | Policy and category knowledge base |
Work-order processing team |
Human team that uses POC results to optimize training, processes, and eventual deployment decisions. | Classification output, Reasoning audit trail |
Data flow
Operators or technicians enter work-order notes into the existing system. The POC sends those request details plus policy/category context to a privately hosted LLM. The LLM answers three business questions: required expertise, urgency level, and special-handling requirements. It returns both classifications and reasoning, which the client can use to compare against manual work-order processing and guide process improvement.
3 supporting quotes
Why this architecture
The POC centers on a privately hosted LLM because the client wanted a secure environment inside its firewall while testing whether GenAI could consistently classify work orders from existing policy/category knowledge. Requiring explanations makes the output auditable and useful for improving the current manual process rather than merely replacing operators with opaque predictions.
3 supporting quotes
Models used: GenAI · privately hosted LLM · NTT DATA LLM
Scale
- The client responds to more than 500,000 maintenance requests annually.“tracks and responds to 500,000-plus annual maintenance requests.”article, stated
- Roughly 70 employees manually process about 1,500 work orders per day.“Roughly 70 employees manually process about 1,500 work orders per day.”article, stated
- The POC was developed in under two weeks.“In under two weeks, we developed a GenAI-powered solution”article, stated
- The knowledge base included more than 160 work-order categories.“a comprehensive list of over 160 work order categories.”article, stated
- The POC focused on three business questions.“NTT DATA and the client determined the POC would focus on three main business questions:”article, stated
Alternatives considered (roads not taken)
Continue the largely manual work-order process
Rejected because: Manual processing created error opportunities and inconsistent classification across operators.
Broad enterprise rollout before proving value
Rejected because: NTT DATA and the client intentionally limited the POC to three concrete business questions so they could test impact quickly.
Use a public or unmanaged LLM environment
Rejected because: The client requested a secure third-party environment and privately hosted LLM to mitigate risk and demonstrate firewall-compatible deployment.
Patterns
structured-output-contract (classification workflow)
The POC constrains the LLM to answer three specific work-order management questions: expertise, urgency, and special handling.
observability-tracing (auditability)
The LLM returns reasoning for each classification, creating an audit trail for accountability and process-improvement analysis.
privacy-preserving-processing (deployment governance)
The client required the POC to run in a secure third-party environment with a privately hosted LLM and firewall-compatible deployment.
prompt-versioning (knowledge maintenance)
The long-term plan is to let the client adjust policies and add clarifications for the LLM, keeping the classification guidance updated over time.
eval-driven-development (POC strategy)
The POC intentionally narrowed success to whether AI could improve accuracy and consistency on three work-order questions before full deployment.
Tradeoffs
POC scope
Chose three high-value classification questions over full work-order process automation.
Rationale: The narrower scope let the team test impact quickly and show whether GenAI could improve consistency before full deployment.
Deployment environment
Chose secure third-party environment with privately hosted LLM over less-controlled public model access.
Rationale: The private environment mitigated risk and showed the AI tool could fit the client's firewall requirements.
Use before full deployment
Chose process improvement and team training first over immediate full rollout.
Rationale: The client planned to use the POC to train and equip the current work-order team, then deploy fully once usefulness is consistent.
Gotchas (what bit them)
Manual work-order classification creates inconsistent downstream handling.
Root cause: Operators and technicians enter notes differently, and manual categorization varies by person.
Resolution: Use the LLM plus policy/category context to classify each work order consistently and explain the reasoning.
A POC can fail to show value if the scope is too broad.
Root cause: Early GenAI work may reveal a different path or fail to prove value on the first attempt.
Resolution: Move quickly on focused POCs, but be patient enough to learn, iterate, and try again when needed.
Business context matters as much as model capability.
Root cause: The correct POC depends on business value, process understanding, and the right place to apply the technology.
Resolution: Start with business value, then evaluate technology enablement and partner expertise.
Evaluation
The source describes a POC evaluation rather than a quantified benchmark: the goal was to test whether a secure GenAI classifier could improve accuracy and consistency for expertise classification, urgency, and special handling, with full deployment contingent on consistent usefulness.
Metrics: classification accuracy · consistency · expertise classification · urgency level · special-handling identification · quality of reasoning audit trail · operator training usefulness
3 supporting quotes
Outcomes
- NTT DATA developed the POC in under two weeks.
- The POC demonstrated faster, more accurate, and more consistent work-order classification than the manual approach.
- The LLM provided reasoning for classifications, creating an audit trail.
- The client planned to use the tool to train and equip its work-order processing team before full deployment.
The work-order environment is large but the implementation was a POC: 500,000-plus annual requests, about 1,500 work orders per day, roughly 70 manual processors, and more than 160 work-order categories. The source does not disclose measured accuracy, latency, or cost results.