Three Salesforce exports each month: repairs, completed installs, and work-order comments. Nothing is typed in by hand, and nothing is added from memory. A job lands on your card because Last Modified By on that record is you — that is the only person field Salesforce gives us, because Technician Name comes across blank on every row.

That is also the biggest known weakness in this data. If a dispatcher or a Lumos Team member touched your ticket last, the job can land on the wrong card. If you see a job that isn't yours, dispute it as Not my job — those get removed and it is not a mark against anybody.

A repeat is a premise that took two or more repair tickets in the month. It is charged to the tech on the earlier ticket — the one who had the chance to fix it — not the one who cleaned it up.

A post-install callback is a premise you installed that then took a repair. It is charged to the installing tech. Order is enforced by SA number, so a repair that predates the install never counts.

Repeat Visits = (repeats + callbacks) ÷ (installs + repairs).

One thing to know: this rate is bigger on longer windows, because installs have had more time to fail. A 4.5% month and a 10.9% quarter are not a quality change — they are two different windows. Only compare within the same window, which is why this site never mixes month lengths.

Every repair's resolution code is read against what you actually wrote in the note. There are only three outcomes:

Clean — the code fits the note. Mismatch — the note clearly says one thing and the ticket closed as another, like a note describing a landscaper cutting the drop on a ticket closed as CPE. That is the only one that counts against you. Generic — closed as CPE or Other with no cause named anywhere in the note. That is shown on your card but is not scored, because it isn't wrong, it just doesn't tell the next tech anything.

Ambiguous notes always count as clean. A blank code is not counted as wrong — uncoded is not miscoded. About a third of all SC tickets close as CPE or Other, so the generic count is normal, not an accusation.

One real gap worth knowing: there is no picklist code for a bad, dirty, or loose connector, which is one of the most common actual causes in this state. If that is what you found and you had to pick something else, say so in a dispute and we will count it.

A repair with a blank resolution note, or one so short nobody can tell what happened. This is the most fixable thing on the whole card and it is not a discipline metric — it exists because when the note is empty, the next tech at that address starts from zero.

Fair warning about the data: the export cuts both the resolution note and the comments field at 255 characters, and it usually cuts the resolution section. A long note can look short here. Dispute it and we will check the record.

Appointments you closed as "need another appointment." Facilities Issues and Construction Access are stripped out — those are never on the tech. What is left is mostly customer driven: requested, missed, or a customer concern.

So read this as how often your appointments didn't happen, not as a fault count. It is on the card for visibility, and the reason breakdown sits right beside the number so the context travels with it.

Survey responses tied to your installs, scored 0–10. Across the whole state the average sits around 9.6 with only a couple of responses per tech, so there is no meaningful spread — this is not used to rank anybody and it never will be.

It's here for the comments. When a customer writes something good about your work, it goes on your card.

Viewer — signs in but sees no technician data. Every technician's numbers are tied to a company, and a viewer has none.

Vendor Partners — their own company's technicians only: the scorecard, QC, surveys, on-time and the coaching log, plus the right to reply to a coaching entry about one of their technicians. Replying marks it acknowledged. A Vendor Partner with no company linked sees no technician data.

Lumos Team — every company's technicians, plus logging coaching, resolving it and withdrawing it. No imports, no thresholds, no managing people.

Management — all of the above and the Admin tab: importing data, editing the thresholds, adding and removing people, the sign-in log.

Every one of these is enforced by the database, not by hiding buttons. A person cannot reach something by guessing a URL or by asking the page nicely.

The Lumos Team logs what happened. The technician's partner sees it immediately and replies — what they did about it, what the tech said. The Lumos Team can reply back. Every entry and every reply carries the name of whoever wrote it and the time they wrote it, stamped by the system rather than typed.

Nothing here can be deleted or edited after the fact. That is enforced in the database itself. An entry that turns out to be wrong is withdrawn — which needs a reason, keeps the original text visible, and records who withdrew it. That way the record is worth something to both sides.

Every entry is filed under a category — Quality of Work, Customer Interaction, Documentation, Work Order, Call Out / No Show, Process Compliance, Can Not Reach, Sent Back, Escalation, QC, Safety, Conduct — and says who reported it, WFM or QC or a customer or the Lumos Team, plus the job or SA number where there is one. The categories live in the database, so the list changes when the business changes it, not when the site is next rebuilt.

Not every entry is a fault. Positive is a category on the same log, filed the same way, just as permanent. If somebody stayed late to finish a cutover, that belongs on the record next to everything else — and it is never counted or coloured as a problem.

Two rules, because there are two.

First Job OTA asks a broader question: every appointment scheduled to start by 9:59 in the morning has to have the technician on site by 8:14. Make Ready and OLT Connection are excluded — nobody is waiting at a window. An appointment with no arrival stamped is counted apart, never scored as late.

The first job of the day on an 8–10 window has to be on site by 8:14. That is the one that gets watched, because a late start rolls downhill through everything behind it. Nine thirty is late on that job even though it is inside the window.

Every other job just has to land inside the window it was promised. The 8:14 rule does not apply to them. In by ten on a 10–12 is on time, and so is in by two on a 12–2.

Arriving early counts as on time. The alternative marks a technician late for being keen, and nobody in the field reads it that way.

A job with no arrival stamped is not scored — not on time, not late. Unknown is not the same as late, and counting it as late would measure who taps the status button rather than who shows up. About 1.4% of completed jobs land there.

Make-ready has no customer window and is never scored for on-time at all.

No reschedule reason counts against a technician. It used to — every reason except two carve-outs was charged to whoever had the appointment. Once Salesforce started giving us the reasons that turned out to be plainly wrong: of 323 reschedules in a month, 272 said Customer Requested, Customer Missed or Customer Concern. A customer moving an appointment is not a technician failing, and counting it as one meant the number was mostly measuring customer behaviour.

What replaces it is a comparison. If one technician has far more of a particular reason than the rest of the crew, that is worth a conversation. If everybody has the same rate, it is the business and not a person.

Standing out is decided statistically, not by a threshold somebody picked. The question asked is: if this technician were no different from everyone else, how likely is a count this high by luck? Because that question gets asked of every technician against every reason — hundreds of chances to be unlucky — the result is corrected so the page is not accusing somebody new every month by accident. Small counts are never tested at all.

Four reasons never enter the comparison, because they describe the plant rather than the person sent to it: Facilities Issues, Construction Access, Fiber Build Incomplete and Address Not Serviceable. They stay visible on the tab.

Being listed is a question, not a finding. A technician can stand out because of the addresses he is sent to.

Lumos Team inspections, a minimum of one per tech. QC is entered on a separate site and imported here.

The inspector's result decides. An inspection marked Pass passes, whatever the score. Fail and Needs follow-up never pass, even at a high score. Only an inspection that came in with no result at all is judged by its score: 90 or better passes (the line is set in Admin).

A Fail or Needs follow-up — however it is spelled — starts a draft coaching entry for the Lumos Team to review.

The pass rate counts technicians' inspections only. Bury-crew inspections have no technician, so they are shown separately with their own label and are not in the rate.

QC is open to the people it is about. The Lumos Team and management see every inspection; a Vendor Partner sees their own company's: what was inspected, who was inspected, the score, the result, why it missed and the coaching that was written.

Two things stay with management: which Lumos Team member carried out each inspection, and how many inspections each Lumos Team member is doing. Those are for running the QC programme, not for keeping score, and they are behind the admin passcode.

Rates need volume. Below the floor shown at the top of the Technicians tab, one bad job swings a percentage by ten points, so those techs are listed with their raw counts but are not ranked, flagged, or compared. They are not being hidden — they just cannot be measured this way yet.

Clean means repeat visits well under the state line with close-out quality at or above it. Good is the middle, where most people sit and where there is nothing to talk about. Slipping means one of the three metrics has drifted off the line. Needs a Look means repeat visits are far enough above the state average that a normal run of bad luck doesn't explain it.

That last one runs a real statistical test underneath, against the state rate and adjusted for the fact that every tech is being checked at once. We don't print those numbers because they don't help anybody do their job — but the test is what stops one rough fortnight from putting a tag on your name.

A standing is a starting point for a conversation. It is not a grade, it is not a ranking anybody is paid on, and it is not evidence for a write-up.

Dispatch and office accounts are excluded from tech scoring — they close tickets administratively and would distort everything. Names are matched to the field roster to handle spelling drift between the export and the tracker. If your name is missing or split across two spellings, that is a roster gap on our side: tell us and we will fix it at the source.

Open your card, find the job, hit Dispute. Pick the reason, write what actually happened, and put your name on it. It lands in a review queue the same minute.

You can watch its status right here on the Disputes tab: Open → Reviewing → Upheld or Denied, with a written reason either way. If it's upheld, the job stops counting against you and every rate on the site recalculates immediately.

Dispute the record, not the ranking. "This job wasn't mine," "the code was right and here is why," "the note was longer than what shows here" — all reviewable. "I don't like where I placed" is not.