Request to accountable work
Turn every facilities request into accountable work
A maintenance request should not become a chase. This blueprint captures the minimum verified site and asset context, classifies the request, proposes the next work record, and gives the requester a named owner and status. It does not diagnose faults, decide whether a situation is safe, choose a contractor, or approve spend; those decisions remain with the facilities team.
AI workers
- Request intake worker
- Triage worker
- Status worker
- Facilities coordinator
Orchestrated process
- CaptureRequest intake worker
- Screen for escalationFacilities coordinator
- ClassifyTriage worker
- Propose work recordTriage worker
- Assign or returnFacilities coordinator
- Keep informedStatus worker
4 guardrails · 4 decision rules · 4 channels · tamper-evident audit
- The team
- 3 AI worker roles escalating into 1 human decision owner.
- The process
- 6 orchestrated stages, each with a named decision owner.
- The channels
- Voice, WhatsApp, Web chat, Email on one shared context.
The shift
What breaks today, and what changes
The challenge
- Requests arrive through reception, messaging, calls, and site teams with different levels of detail and no common owner.
- Technicians and coordinators spend time chasing location, access, asset, and urgency information before useful work can begin.
- Requesters call again because there is no clear acknowledgement, owner, or explanation of the next step.
What changes
- Each request is captured against the available site, location, and asset context before it enters the operational queue.
- Routine requests receive a proposed work record and a named coordinator rather than disappearing into an unstructured inbox.
- Safety signals and decision-heavy exceptions reach an accountable human with the original request and its context attached.
The team
Every seat has one job and a defined level of autonomy
This is what gets configured in Team Canvas: role-scoped AI workers, the humans they escalate into, and a trust level on each connection that sets what a worker may do on its own. Trust starts tight and widens on evidence.
AI workers
Request intake worker
Captures the request, site, location, contact, and available asset context across approved channels.
- Owns
- Complete request record
- Trust level
- Acts within policy — captures facts and asks for missing context
Triage worker
Classifies the request against the configured service catalogue and identifies the responsible queue.
- Owns
- Routing proposal
- Trust level
- Suggest-only where urgency or classification is uncertain
Status worker
Shares approved request status and records follow-up questions without inventing completion times.
- Owns
- Requester updates
- Trust level
- Acts within policy — reads verified status only
Human decision owners
Facilities coordinator
Confirms urgency, assigns work, manages access, and owns exceptions.
Owns: Dispatch and operational exceptions
The process
The conversation starts the work. The workflow finishes it.
Each stage records the decision that was made and the role accountable for it — which is what makes the run reviewable afterwards rather than a black box. Where the platform executes a stage rather than a person or agent performing it, that is named too, and accountability still sits with the role.
- 1
Capture
What site, location, contact, access, and issue details are verified?
Request intake worker
- 2
Screen for escalation
Does safety, emergency, or uncertain urgency require immediate human assessment?
Facilities coordinator
- 3
Classify
Which configured service category and accountable queue fit the verified request?
Triage worker
- 4
Propose work record
Is there enough verified context to propose a work order for coordinator review?
Triage worker
Run by workflow
- 5
Assign or return
Who owns the work, and what additional information or access decision is needed?
Facilities coordinator
- 6
Keep informed
What approved status and next step can be shared with the requester?
Status worker
Run by integration
Decision rules
The non-negotiables encoded in the workflow, not left to a prompt.
- Emergency and safety language stops routine handling and routes to an accountable human for assessment.
- The workflow proposes a work record only from verified context; it does not perform technical diagnosis.
- Vendor selection, site access permission, dispatch overrides, and spend approval remain human decisions.
- Status updates come only from the configured work-management record and never promise an unverified completion time.
Controls & guardrails
What makes this safe to run in production, and provable afterwards.
- Immediate human assessment path for emergency and safety signals.
- No technical diagnosis, vendor selection, access permission, or spend approval by the worker team.
- Work-order proposals remain reviewable and attributable to a facilities coordinator.
- Only verified status is shared back to requesters, with the full request history retained for review.
Platform
Surfaces that run this blueprint
The four tools inside Voxistry that compose, execute, monitor, and govern this team.
Channels on one shared context
- Voice
- Web chat
Systems it reads and writes
- Configured facilities or work-order system
- Site and asset register
- Service catalogue and responsibility matrix
- CRM or requester contact record
Measurement
What we instrument from day one
These are the measurements the pilot puts in place, not benchmark results. You set the targets against your own baseline — and the same instrumentation is what decides whether a worker's trust level widens.
- Request completeness
- Tracks the required site, location, contact, access, and issue fields present before a coordinator reviews the request.
- Time to named owner
- Measures the time from a new request to an accountable coordinator, not merely to an automated acknowledgement.
- Repeat or chase contact
- Shows how often a requester has to contact the team again before the work is resolved or clearly handed over.
At first handoff
From first contact
Before closure
Rollout
How this one goes live
A deliberately narrow start, supervised, with autonomy widened per role once the record supports it.
Weeks 1–2
One request lane, supervised
Start with one common non-emergency request category, capture the record, and have coordinators approve every proposed work item.
Weeks 3–4
Named-owner and status loop
Connect the agreed work-management record so requesters receive verified ownership and status while coordinators tune the routing rules.
Week 5+
Adjacent sites and categories
Extend to additional sites or service categories only where the responsibility matrix and escalation path are already agreed.
Questions we get asked
Request to accountable work, in practice
- Can the system decide that a request is safe to wait for?
- No. The workflow can recognise configured emergency or safety language and stop the routine path, but a facilities coordinator or other accountable person assesses urgency. The purpose of the intake is to preserve the requester’s wording, location, and available context so that assessment starts with a useful record, not to replace the judgement of someone responsible for the site.
- Will it dispatch a contractor or approve a repair cost?
- No. It can create a reviewable work-order proposal when the configured information is complete, but vendor selection, contractor instruction, access arrangements, dispatch overrides, and any spend approval remain with the facilities team. That boundary is deliberate: those choices depend on safety, site conditions, contracts, availability, and commercial authority that a generic request conversation cannot determine.
- What happens when the request does not contain enough information?
- The intake worker asks for the missing facts that the team has configured, such as site, exact location, contact, access constraints, and visible symptoms. If the record remains incomplete or the category is uncertain, it is handed to a coordinator rather than forced into a queue. The pilot should measure completeness at first handoff, making the gaps visible before the organisation widens the workflow.
What changes in Facilities management
Every request gets a named owner and a traceable next step, while safety assessment, technical diagnosis, vendor choice, and spend approval stay with accountable people.
Read the full Facilities management analysisRelated blueprints
Teams that run next to this one
Next step
Build this team around one measurable win.
We map your version of this process, compose the worker roles, connect your systems, and agree the escalation points with the people who own them — then run it supervised.