Workshop Intelligence: Jobs, Inspections & Service History in a Single Domain

In most fleet operations, the workshop and fleet management functions run in parallel tracks that rarely intersect automatically. A job gets completed. Someone has to remember to update the vehicle record. Someone else has to inform the customer. An inspection was due three weeks ago, but nobody noticed until the vehicle came in for an unrelated service. The information about what happened to a vehicle - when it was serviced, what was found, what was fixed - exists somewhere, but it's not connected to the operational record of the vehicle or the subscription it's attached to.

The consequence isn't just administrative inconvenience. It's operational blind spots. Compliance obligations missed because the due date wasn't visible in context. Service intervals overrun because nobody had a view across the fleet that showed where each vehicle was in its maintenance cycle. Customers unaware of upcoming requirements because the information sat in the workshop system rather than the customer-facing operational record.

Petriko treats workshop activity as a domain event, not an isolated record. When something happens to a vehicle in the workshop, the operational domain knows - and the information flows where it needs to go.

Job Cards as Domain Events

A job in Petriko is connected to the vehicle it touches, the subscription that vehicle belongs to, and the customer who holds it. These are not manual links - they're structural relationships established when the job is created.

When a job is completed, the vehicle's service history updates automatically. The record of what was done, when, by whom, and at what cost is attached to the vehicle entity - accessible from the vehicle detail page, from the subscription record, and from the customer's profile. There is no separate entry to make in a fleet management system after the workshop completes a job.

The job card itself carries the operational detail: what work was performed, parts used, labour time, cost breakdown, any inspections logged as part of the service, and notes. It's a complete record at the job level, and it's also a node in the operational graph - connected to the vehicle and subscription records that give it context.

Odometer-Triggered Inspection Workflows

The subscription record carries odometer readings logged at intervals by the subscriber. Each reading is timestamped, and the system maintains a history of readings against the subscription.

When a reading is logged, Petriko compares it against the service interval configured for that vehicle type. If the threshold is crossed - whether that's kilometres driven or time elapsed - an inspection workflow is triggered automatically. The workshop can see the trigger reason, the current odometer, and the history of prior service events when scheduling the inspection.

This changes the dynamic from reactive to proactive. Rather than discovering that a service interval was overrun when the vehicle comes in for something else, the system identifies the upcoming requirement before it becomes overdue. Scheduling happens in advance, not in response to a problem.

The service history view on the subscription shows the complete chain of events: odometer readings, triggered inspections, completed services, and the dates of each. This is the record that an operator needs to demonstrate compliance with service obligations - available directly from the subscription, not assembled from separate systems.

Alerts Close the Loop

Workshop events that have compliance implications surface in the alerts feed. Registration due dates, insurance expiry, inspection intervals overdue - these appear in the alerts dashboard before they become failures, not after.

The alerts system draws from the underlying operational data: the vehicle entity carries the compliance dates, and the system generates alerts based on configurable lead times. A registration due in two weeks appears in the alerts feed today. An inspection that's overrun its interval appears as overdue, with the vehicle, subscription, and responsible customer identified.

The information flows to the people who need to act on it. A service coordinator can see which vehicles are approaching compliance deadlines across the fleet, not just the ones that happened to come in for service recently. Workshop scheduling can be driven by what the data shows, not by what someone remembers to check.

The Architecture of Service Intelligence

The gap between the workshop floor and fleet administration isn't primarily a communication problem - though it manifests as one. It's a data architecture problem. When workshop jobs, inspection records, odometer readings, and compliance obligations live in separate systems with no structural connection, the information about a vehicle's state is never complete in any one place. People fill the gap manually, and manual processes fail.

When these are domain events in a connected operational system, the information flows structurally. A completed job updates the vehicle record. An odometer reading triggers an inspection workflow. A compliance deadline surfaces in the alerts feed. The connection doesn't require a person to maintain it - it's built into the architecture.

That's the difference between a workshop management system and workshop intelligence. The former records what happened. The latter ensures that what happened is known, in context, by the parts of the business that need to act on it.