How to Run a Weekly Contractor Document Review That Actually Moves Work Forward

A weekly contractor document review sounds straightforward until someone tries to run one.

The spreadsheet is open. Outlook is open. Three customer portals are open. Someone has a yellow legal pad with notes from last week. A project coordinator remembers that a broker sent something on Tuesday, but nobody can find the message. The portal says “under review,” the spreadsheet says “pending,” and the shared drive contains two files with nearly identical names.

Twenty minutes into the meeting, the team is still trying to establish what happened. Nobody has reviewed what needs to happen next.

That is the real problem with many weekly document reviews. They are not reviews at all. They are reconstruction sessions.

The purpose of a good weekly review is not to read every row in a tracker. It is to find work that has stalled, confirm that recent activity was recorded correctly, and make sure every unresolved item has a clear next step. The meeting should help the team answer a few practical questions: What changed? What is still missing? Who has the ball? What needs attention before next week?

When the review is designed around those questions, it becomes useful. When it is designed around the shape of the spreadsheet, it becomes a long tour of administrative scenery.

The review should begin before the meeting

The fastest way to ruin a weekly review is to begin with the full customer list and work downward.

Most records do not need discussion. A current document that expires next year, has no open request, and belongs to a customer with no active issue is not helping the meeting by appearing on screen. It is simply present, like a coworker who joins every call but never speaks.

The review should begin with an exception list: customers and items that changed, aged, became urgent, or failed to move during the previous week. That usually means recent missing requirements, upcoming expirations, overdue follow-ups, new replies, portal notices, unresolved internal tasks, and anything whose status no longer makes sense.

If the team cannot produce that list without manually comparing the spreadsheet to email and portal activity, the tracker is recording documents but not really supporting the workflow around them. The review set does not need to be perfect. It needs to be small enough that the team can make decisions.

Start with what changed, not what exists

The first few minutes should be spent on new information.

Which documents arrived? Which requests were sent? Which portal notices came back? Did any customer add a new requirement? Did an item that looked complete last week become rejected, expired, or questionable?

This is where small inconsistencies appear before they grow into larger ones. A broker may have replied with a replacement certificate, but the document was never connected to the customer. A customer portal may have rejected an upload while the internal tracker still says “submitted.” A project manager may have forwarded a request for an additional form that never made it into the list of tracked requirements.

New activity should lead to a change in the operating record. “There is an email about it” is not a status. The reply needs to be reviewed and translated into something the team can act on: received, partially received, revision required, uploaded and waiting for review, accepted, assigned as an internal task, or resolved.

Email creates a false sense of progress. A broker may send a revised certificate, but the attachment still needs to be checked, linked to the correct customer, and perhaps uploaded to a portal. Marking it “received” can hide those remaining steps; leaving it “pending” hides whether anyone saw the reply. A useful status says where the item actually stands and what must happen next.

Look for missing work that nobody has started

Once recent activity is accounted for, the next priority is not every missing document. It is missing work that has no active owner or request.

This distinction is easy to lose in a spreadsheet. Two rows may both say “missing,” even though one was requested yesterday and the other has been sitting untouched for three weeks. Operationally, those are very different situations.

The first item is waiting. The second has not begun.

For each unstarted item, the team should confirm which customer requires it, who or what the document belongs to, who should receive the request, and who inside the company owns the follow-through. The first follow-up date should be decided at the same time the request is prepared. Otherwise the item moves from “missing” to a new form of limbo: “email sent, probably.”

This is especially important when documents belong to different parties. A customer package may contain company records, subcontractor certificates, employee credentials, crew rosters, and portal forms. A row labeled “COI missing” is not enough if nobody can tell whose COI it is.

The team should not have to rediscover that context every week.

Treat expirations as workflow, not calendar trivia

Expiration dates are easy to report and surprisingly easy to mishandle.

A list of documents expiring in 30, 60, or 90 days is useful, but the date alone does not tell the team whether the renewal process is healthy. A certificate expiring in 45 days may already be requested from a responsive broker and safely waiting. Another item expiring in 75 days may require internal signatures, employee information, and a slow customer portal review. The second item may deserve attention first.

A good weekly review looks past the countdown and asks whether the work has started early enough.

For each upcoming expiration, someone should be able to explain whether renewal is actually required, who must provide the replacement, whether a request has been sent, what the usual turnaround time is, and when the next follow-up is due. Records that do not expire should remain outside the expiration workflow entirely rather than receiving invented dates simply because the spreadsheet has an expiration column.

The team needs to distinguish an upcoming expiration that is under control from one quietly approaching with no plan. Customer differences matter here: one may accept a replacement by email, while another requires an upload, additional forms, and portal review.

Spend time on old waiting items

Most weekly reviews contain too much discussion of new work and not enough discussion of old waiting work.

New items feel active. Old waiting items feel familiar. That familiarity is dangerous because the team gradually stops seeing them.

“Waiting on customer” since Tuesday is normal. “Waiting on customer” since May, with no recorded follow-up date, is not a status. It is an abandoned process.

Every waiting item should tell a simple story: who is expected to act, when the waiting began, what the last contact was, and when the next follow-up is due. If the team cannot answer those points without searching email, the review has found a workflow gap.

Grouping waiting work by party can be more revealing than reviewing it customer by customer. Three stalled requests may all involve the same broker. Several portal submissions may be waiting because nobody was assigned to check the portal after upload. An internal manager may be holding up documents across multiple customers without realizing it.

A row-by-row spreadsheet review tends to hide those patterns. The meeting should also avoid treating every waiting item as urgent. Some should remain quiet until the agreed date. The goal is to separate healthy waiting from stale waiting, not to choose between chasing everyone constantly and forgetting them entirely.

Review the customer as a package

Individual document rows can look correct while the customer relationship is still blocked.

Suppose a customer requires a COI, W-9, training roster, supplier form, and portal registration. Four items may be current or submitted. The fifth may never have been requested. Looking at each document separately can create the impression that the customer is nearly done, while the missing form is still preventing progress.

At some point in the review, the team needs to zoom out and look at the customer package as a whole.

That means checking what is required, what has been received, what is waiting, what expires soon, what has not been requested, and what still needs attention in the customer portal. It also means confirming that documents belong to the correct company, subcontractor, employee, or crew. A perfectly current document attached to the wrong party does not solve the problem.

This customer-level view is where a single source of truth earns its keep. It should not claim that the customer is compliant, approved, or guaranteed ready. It should show the tracked operational state clearly enough that an administrator can understand the package without rebuilding it from Outlook, a spreadsheet, shared folders, and the portal.

A prospect considering new software usually does not need another place to store a PDF. They need confidence that the system can show how the PDF relates to the customer’s requirements, whether anything is still missing, and what someone must do next.

Do not let the meeting end with “we should follow up”

The most common failure at the end of a weekly review is a room full of reasonable intentions.

Someone says the broker should be contacted. Someone else says the portal needs to be checked. A project manager agrees to find an employee record. Then the meeting ends, and those decisions become private notes, flagged emails, or memory.

Every unresolved item should leave the review with a current state, an internal owner, and a next date. That does not require a paragraph of documentation. One clear sentence is enough:

Revised certificate requested from the broker. Morgan owns the follow-up. Check again Tuesday if nothing is received.

Compare that with “COI pending.” The first statement lets another person understand the work immediately. The second forces the next person to investigate from the beginning.

Ownership should also be split correctly. “Waiting on broker” identifies the outside party expected to act. “Morgan owns follow-up” identifies who inside the organization is responsible for making sure the item does not disappear. Those are different roles, and both matter.

The review should produce a small number of believable totals

A weekly review does not need an executive dashboard large enough to guide aircraft.

It does need a few numbers the team can explain. By the end of the meeting, an administrator should be able to state how many required items have not been requested, how many follow-ups are due or overdue, how many documents are inside the active renewal window, how many customers still have package gaps, and how many internal tasks are blocking progress.

The counts will change, but they must be traceable. If the team says there are nine overdue follow-ups, those nine items should be easy to open and understand. Otherwise users create side spreadsheets to verify the main spreadsheet, and the workflow begins reproducing itself like an administrative houseplant nobody asked for.

What a 45-minute review can look like

A practical weekly review does not need six agenda sections projected onto a conference-room wall. It needs a stable rhythm.

Begin with new activity and unexpected changes. Then look for required work that has not started. Move into upcoming expirations and confirm whether renewals are actually underway. Spend the middle of the meeting on overdue or aging waiting items, because that is where neglected work usually lives. Finish by reviewing the customers with the largest unresolved package gaps and assigning owners and dates to anything that remains open.

For a small team, that can fit into forty-five minutes. The first ten minutes cover new replies, uploads, portal notices, and changed requirements. The next ten focus on missing and unrequested work. Another ten cover renewals entering the active window. Ten more address stale waiting items and overdue follow-ups. The final few minutes confirm assignments and reconcile the operating totals.

The timing is less important than the outcome. The meeting should update the system the team actually uses. If everyone leaves with handwritten notes that must be entered later, the review has created another handoff that can fail.

What the system should remember between meetings

A strong weekly review depends on what happens during the other six days.

The tracking system should preserve the connection between customer requirements, documents, outgoing requests, incoming replies, waiting states, portal activity, internal tasks, owners, and follow-up dates. It does not need to replace every customer portal or become a full email client. It needs to give the team one operational record that explains the work taking place across those systems.

That is the role Sidecar is built to fill. It can show which customers need attention, separate work that has not been requested from work already waiting on someone, capture request and reply history, surface follow-ups when they become due, and keep customer-level context together. The administrator still reviews the documents and decides what the customer requires. Sidecar is not making compliance decisions. It is preventing the coordination around those decisions from disappearing.

The value is starting the weekly review with a believable picture of the work instead of spending half the meeting reconstructing one.

A better review starts with better operating rules

Teams do not need to buy software before improving the review itself.

Stop using “pending” unless the record also says who is expected to act. Separate missing-unrequested work from missing-requested work. Give unresolved items an internal owner and a next date. Treat replies as workflow changes rather than proof that an issue is finished. Review customers as packages, not just collections of file rows. Keep healthy records out of the discussion unless something changed.

Those rules quickly expose whether the current system is still adequate.

A spreadsheet can work for a small, stable operation when one person understands the whole process and the number of customers remains manageable. It starts to strain when the weekly review depends on memory, status must be reconstructed from several systems, or nobody can explain why an item is waiting, urgent, or supposedly complete.

At that point, the problem is no longer storing documents. It is coordinating the work around them.

The weekly review should be where the team sees that coordination clearly—not where they recreate it from scratch.