You called the sub back because the last job went fine. You don’t remember exactly when the problems started. Just that by week three you were managing around them instead of with them. The history you didn’t write down is the decision you’re making from memory.
Sub relationships are not managed in the field. They are managed in the record. The field is where the work happens.
The record is where the pattern becomes visible. Which subs deliver on this type of job, which require close oversight, and which should not be on jobs above a certain complexity. Those records are built one documented conversation at a time. Each scope agreement, scheduling confirmation, and post-job note adds to a picture that gets clearer with every job.
The Sub History Record is the tool that makes sub relationships manageable at scale. When the business works with ten or fifteen subs, the record is what keeps the owner from making every sub decision from memory.
Why Sub Relationships Run on Memory Instead of Records
The obvious problem is volume. A contractor who works with eight to twelve subs regularly cannot keep each relationship fully in their head. Who worked on which jobs, what the scope agreements were, which jobs had problems, how those problems were resolved.
The less visible cost is pattern blindness. A sub who is slow to start but strong in execution looks like a problem until the record shows three jobs with the same pattern. Without the record, each job with that sub feels like a new situation. With it, the pattern is visible and the decision is different.
The deepest cost is the repeat mistake. A sub whose scheduling problem was absorbed into memory gets booked again without the scheduling conversation that the first job warranted. The record that wasn’t written is the conversation that wasn’t had.
The Sub History Record
The Sub History Record is one document per sub. It captures four things: what this sub does, how they have performed, what they cost, and what to watch for on future jobs with them.
Part 1 defines what a complete sub history record contains
A sub record has three categories of content. First, the baseline: trade, specialty, license and insurance status, and contact information. Second, the work history: every job the sub has been on, the scope they handled, and any scope agreements documented at the time. Third, the performance notes: what went well, what required management, how issues were resolved.
The baseline is updated once when the sub is first brought in. The work history and performance notes grow with every job.
Part 2 identifies the moments when the record should be updated
A sub record has three natural update moments. Before a new job, when scope and schedule are confirmed. During the job, if a performance issue or a change in scope arises. At closeout, when the honest assessment of how the sub performed can be captured while the job is still fresh.
These three moments are not extra work. They are the work of managing a sub relationship rather than reacting to it.
Before: The sub decision is made from memory and availability, with no review of past performance before booking. After: The sub record is reviewed before every booking, making performance patterns visible and scope discussions grounded in prior agreements.
Part 3 shows how the record changes sub relationship decisions
A complete sub record changes three categories of decision. It changes which subs get called for which job types. It shapes the scope conversation before a job starts. And it informs what to watch for during the job.
A sub with a strong record on small residential jobs and a mixed record on large commercial jobs gets called for the right work. A sub whose record shows one recurring scheduling pattern gets the scheduling conversation at booking rather than at day three of the job.
How the Conductor Surfaces Your Sub History Before You Book
A new job comes in. The HVAC sub who did good work six months ago is the obvious call. Before dialing, the owner opens the Living Library.
The Living Library is the platform’s active working layer, holding the sub records, job history, and performance notes the owner has brought in over time. It organizes them by sub and by job type so a single query surfaces everything relevant to the current decision. The Conductor draws from that record. It returns what matters: the last three jobs with this sub, the performance notes, and any scope flags worth discussing before the new booking.
The booking conversation is different because the context is current, not recalled. The scope discussion references the actual record from the last job. The scheduling expectation is set based on what the record shows, not on optimism.
Start with the Sub You Use Most
Don’t build records for all your subs at once. Start with the one you use most.
Write down their baseline information, the last three jobs they were on, and a one-paragraph performance note for each. That is the first version of a Sub History Record.
Add to it after the next job. Use it before the booking after that. After three or four updates, the record earns its value.
The Pattern That Wasn’t Visible Becomes the Decision That Changes
The sub decision made from memory is a guess. The sub decision made from a record is a pattern confirmed. Every job that updates the record makes the next booking smarter. Try Kiluma free for 14 days at kiluma.ai.