Short answer
Office equipment field service organizations often keep large, structured ticket histories for printers, copiers and similar devices: error codes, symptoms, parts and visit outcomes across many sites. These support diagnosis language, fault classification and parts-prediction research. They record what happened, not how hands did it, so they cannot supply manipulation or robot action data and need pairing with recordings for physical tasks.
What makes this a useful corner of maintenance data
Office equipment service is an unusually standardized business. A service organization maintains the same device families across thousands of customer sites, with a ticketing system, dispatch rules, a parts depot and a technician workforce trained on known models. The data that falls out of it is more uniform than the free-text maintenance logs of a factory, and the same fault recurs often enough to study.
For humanoid and embodied-AI buyers the value is indirect. The tasks, such as clearing a paper path, swapping a fuser, replacing a drum or cleaning a sensor, are small, repeatable and hands-on, and they happen in offices that a service robot might one day share. But a ticket describes a visit in words and codes. It does not show hands. This page is therefore about records, with video as a possible companion.
For the general record type, read work order histories. This page is about the particulars of office-device field service. The wider map is at the maintenance cluster hub.
Anatomy of a field-service visit as data
Confirm these with the supplier; the exact fields differ by organization and system.
- Request. Customer or device-initiated ticket: symptom text, error code, device model, location, priority.
- Remote triage. Notes from a phone or remote-diagnostic step, which may resolve the issue without a visit.
- Dispatch. Technician assignment, parts pre-staged, appointment times.
- Visit. Arrival, diagnosis, actions taken, parts replaced, test prints or functional checks, time on site.
- Closure. Resolution code, customer sign-off, follow-up needs.
- Callbacks. A repeat ticket on the same device shortly afterward, which is the main indicator of an unresolved fix. See first-time fix and callback labels.
A well-formed history lets a model link symptom to fault to part to outcome, and lets an evaluator check whether a predicted fix matches what the technician actually did.
What the data can and cannot support
| Data element | Can support | Cannot support |
|---|---|---|
| Symptom text and error codes | Fault classification, retrieval of procedures, code interpretation | Physical diagnosis |
| Parts used and parts depot data | Parts prediction, bill-of-materials reasoning | How parts are fitted |
| Technician notes | Shorthand resolution, action summaries | Exact steps and sequence |
| Resolution and callback outcomes | Fix-success labels, difficulty proxies | Why a fix failed |
| Time on site | Rough task duration | Motion or effort |
| Photos, when attached | Parts and condition recognition | Technique |
Error codes and on-screen messages are a distinct data type; the error codes and HMI screens page covers pairing screens with codes. For text cleaning, see normalizing technician shorthand and maintenance logbook text.
MaintNet offers a model of how maintenance language can be packaged: logbook data from aviation, automotive and facilities domains, with abbreviation lists, morphosyntactic lists, termbanks and pre-processing and clustering tools (Akhbardeh et al., 2020). It contains no office-equipment data, so it is useful only as a format and tooling reference.
Illustrative package
Synthetic, for discussion.
# Illustrative only
device_families: [mono_laser_A, color_mfp_B] # supplier-defined
ticket:
ticket_id: tk_00812
site_token: site_031
device_token: dev_2210
symptom_text: raw
error_code: E-xxx # synthetic format
remote_triage_notes: raw
visit:
actions_taken: raw
parts: [part_token_17, part_token_42]
time_on_site_min: value
resolution_code: category
callback_within_window: bool
removed: [customer_name, address, user_names, document_contents]
Customer document content deserves caution. Office devices handle customers' documents, and service data can include job names, queue contents or scanned images. Ask how the supplier checks for such content and what it does when it finds some.
Supplier types
| Supplier | Typical holdings | Watch for |
|---|---|---|
| Office-equipment service organizations and dealers | Ticket histories, parts, dispatch data | Customer contract restrictions |
| Managed print and IT services providers | Fleet monitoring, remote diagnostics | Device telemetry that may identify customers |
| Manufacturers' service divisions | Models, fault trees, manuals | Proprietary documentation |
| Field-service software vendors | Aggregated tickets | May lack the right to license customer data |
Records are existing assets. Their rights are mediated by service contracts, customer agreements and software-vendor terms. See licensing terms for robotics training data for clause topics, and existing assets, new collection or specialist partners for route choice. This is not legal advice.
Pairing records with physical data
Because tickets lack motion, a buyer who wants to model the physical tasks can add a commissioned layer: recorded visits for selected fault types with technician and customer agreement. Link each recording to its ticket so the diagnosis and the physical task share an ID. See existing footage versus commissioned recording. Human video of such work could inform perception and step understanding; robot control would still need robot or teleoperation data.
Limits and extra preparation
- No physical signal. Ticket text cannot teach a manipulator to handle a jammed sheet or a fuser.
- Shorthand and codes. Normalize abbreviations and map codes to meanings before training.
- Customer exposure. Redaction reduces exposure but does not resolve permission questions; check contracts.
- Device-family concentration. A service organization may specialize in a few brands.
- Label noise. Resolution codes are chosen under time pressure and vary between technicians.
- Evaluation. Hold out whole customers, regions or device families, and keep them out of training.
Questions to ask suppliers
- Which device families and years are represented, and how many sites?
- Are symptom and technician notes kept in raw text, or only as codes?
- Are callbacks identifiable, and over what window?
- Which fields could contain customer names, document names or user identities, and how are they removed?
- Do contracts with customers or software vendors permit licensing for AI training?
- Are manufacturer manuals, fault trees or parts diagrams embedded in the data?
- Are photos or screens attached to tickets, and are they retained?
- Can a sample of raw tickets be inspected before a commitment?
- Could selected visits be recorded with consent for a companion video layer?
Discuss your requirements
If office-equipment service histories fit your plan, describe the device families, fields and permitted uses to SourceX. SourceX looks for US businesses that hold suitable material, checks the data and the supplier's licensing permissions, and follows up about potential sources. A request does not guarantee a match. For the wider sourcing map start at the humanoid training data guide, and see the catalog entries for field service and maintenance records and customer support tickets.
Explore sourcing and licensing options with SourceX
Sources
- MaintNet: A Collaborative Open-Source Library for Predictive Maintenance Language Resources — maintenance logbook language resources from aviation, automotive and facilities domains; format reference only.