There is a particular kind of contractor admin work that feels productive right up until you realize you have recorded the same thing three times.
A customer asks for an updated document. You reply in Outlook. You update the spreadsheet so the office knows the request went out. Then you log into the customer’s portal and discover it still says Missing. Maybe there is also a SharePoint list, project tracker, or dashboard that somebody expects to be current.
By lunch, one request has left a trail through four systems.
None of those systems is necessarily wrong. Each one may have a perfectly legitimate job. The problem is that the contractor administrator quietly becomes responsible for keeping all of their partial versions of the story in agreement.
You see the same thing in supplier onboarding and procurement work. The request happens in email. A form feeds a SharePoint list. Somebody updates an internal spreadsheet. Another department works from its own system. The “official” status often gets entered after the real work already happened somewhere else.
That is how duplicate data entry turns into duplicate workflow maintenance.
Replacing every system is usually unrealistic. A more useful goal is figuring out which system needs to know which fact — and stopping the habit of copying everything everywhere.
Decide what each system is actually authoritative for
“Single source of truth” sounds great until somebody interprets it as “we should put absolutely everything in one application.”
Customer portals are not going away because your internal tracker is better. Outlook is still where a broker or subcontractor may reply. A shared folder may still be where the final document belongs. Accounting and project systems have information they genuinely need to own.
So make the question smaller: which system is authoritative for this particular fact?
A contractor admin team might decide that the customer portal owns the customer’s portal status. The shared drive owns the final file. Email preserves the original conversation. The internal work queue owns the part the team actually needs to run the day: what is missing, who has the ball, and when somebody needs to look again.
If a portal says Pending Review, the internal tracker does not need a miniature copy of the portal. It needs enough context to tell the next person that the upload happened, the customer is reviewing it, and somebody should check again Friday.
That is a much easier record to maintain.
Stop copying status and start recording what it means
This is where a lot of duplicate entry sneaks in.
One portal says Submitted. Another says Under Review. A customer simply emails, “Got it, we’ll take a look.” An administrator can faithfully copy all three phrases into a spreadsheet and still leave the team wondering what to do next.
For internal purposes, the useful translation may be the same:
Waiting on customer review — check again Aug. 31.
Or a subcontractor replies, “I’ll send the revised form tomorrow.” The operational status becomes:
Waiting on subcontractor — follow up Aug. 28 if not received.
The original wording has not vanished. It is still in the portal or email if anyone needs it. The internal record has a different job: tell the team what the outside information means for the work.
Once you make that distinction, there is a lot less reason to reproduce every external status field word for word.
Give every duplicate update a reason to survive
Old workflows collect fields the way kitchen junk drawers collect mystery cables.
Somebody added a “last follow-up” column years ago. A project tracker got its own status field. Then a manager wanted a spreadsheet for reporting. Nobody remembers which one came first, but everybody knows they had better update all of them.
Before maintaining another copy, ask what decision it supports.
If a project manager uses a dashboard to see whether mobilization paperwork is ready, that status has a job. If accounting needs a vendor identifier in its own system, that field has a job.
But if three spreadsheets contain the same follow-up date and nobody can say which one wins when they disagree, the duplicates are not providing resilience. They are creating three opportunities to be wrong.
It is worth mapping the fields admins touch constantly:
| Information | Authoritative place | What belongs elsewhere |
|---|---|---|
| Actual document | Shared document location | Link to it when useful |
| Customer portal status | Customer portal | Operational meaning, not a full copy |
| Request/reply history | Email + workflow history | Enough context to understand the current state |
| Waiting party | Internal work queue | Surface wherever daily work is managed |
| Next follow-up | Internal work queue | Avoid competing reminder dates |
| Customer-specific requirement | Customer workflow record | Reference it from related work |
Your office may make different choices. That is fine. The win comes from making the choices on purpose.
Watch for the spreadsheet whose job is feeding another spreadsheet
This one is usually a giveaway.
The contractor admin keeps a personal spreadsheet because the department spreadsheet is awkward. Once a week, the department sheet gets updated from the personal one. A manager exports that into Power BI. Someone on a project keeps another list because the department sheet does not show enough detail.
Congratulations. The company has accidentally built a distributed database, and the synchronization service is a person with Outlook open.
A temporary working sheet can be useful. An import-cleanup file, for example, has a clear end. So does a project staging list if everyone knows where the final status goes.
The trouble starts when nobody can answer, “When do we stop maintaining this copy?”
If the answer is never, it is not a temporary tool anymore. It is another system of record whether anybody intended that or not.
Put the update where the next person will actually look
Even a sensible system-of-record plan falls apart if nobody trusts the record.
Say the admin sends a request at 10:15 but plans to update the tracker after lunch. At 11:40, somebody else checks the tracker, sees Missing, and assumes the request never went out.
Nothing dramatic happened. The team just had two versions of reality for an hour and a half.
That is enough to teach people a bad habit: verify everything yourself.
Once people stop trusting the operating record, even good software becomes decorative. The admin ends up answering the same questions anyway.
The practical habit is to update the record when something meaningful changes: the request went out, a reply changed who has the ball, an upload happened, a portal status changed, ownership moved, or the next follow-up date changed.
You do not need a transcript of every click. You need the handful of events that change what the next person should believe or do.
Sidecar can play that operational role by keeping customer requirements, waiting states, follow-ups, and activity together without pretending it can replace every customer portal or inbox. A disciplined spreadsheet can follow the same principle at smaller scale.
One operational truth is enough
Contractor administrators work in a world where customers have different requirements and often insist on different systems. That part is not going to become tidy just because the internal process is tidy.
But the administrator should not have to keep four complete copies of the same workflow aligned forever.
Let the customer portal own what the customer portal knows. Keep the actual document where the team has decided documents belong. Leave the original conversation in email. Then maintain one dependable operational view connecting those pieces.
That view should answer the questions that matter during the day:
What is still missing? Who has the ball? What changed? What needs attention next?
And perhaps the most underrated one:
Where do I update this so I don’t have to update it two more times?
When everybody knows the answer, the work gets lighter without requiring the rest of the software stack to magically disappear.