RFIs and Submittals: Document Control Is Not Submittal Management
ServiceIQ has document management. It does not have a submittal log or an RFI register, and the difference is a ball-in-court column. Where those workflows belong and why.
An RFI is not a document. It is a clock.
Somebody asked a question, somebody owes an answer, a date is attached, and if the answer is late the delay is attributable. The register exists to prove who was holding it. A submittal log is the same shape: a ball-in-court record with revision history, not a folder of PDFs.
That distinction separates document management from submittal management, and it is why one does not substitute for the other.
What does document management actually give you?
ServiceIQ carries document management at Starter and advanced document workflows at Professional. Files attached to jobs, available in the field, with workflow around them.
That is genuinely useful and solves a real problem: a crew that can pull the current drawing on site is a crew that does not build to a superseded revision. Rework from stale drawings is expensive and common.
What it is not is a register. There is no numbered RFI sequence, no responsible party field, no days-outstanding clock, no audit trail built to survive a dispute.
What does a submittal log need that a file store does not?
- A number and a sequence, so submittal 047 means something to everyone on the job
- Ball in court, which is a field, not a note
- Dates that attribute: sent, received, returned, resubmitted
- Revision history where rev B does not overwrite rev A
- Status that is a workflow state, not a label somebody types
Every one of those exists to answer a question after the fact, usually under pressure, usually when money is attached.
Where do these workflows belong?
Procore, PlanGrid and Autodesk Construction Cloud own RFIs and submittals, and they own them properly.
If you are running commercial work with an architect of record, that is not optional tooling. It is how you defend a schedule position. A GC who cannot produce an RFI log showing a question sat for three weeks has lost that argument before it starts.
HubSpot has no claim here at all. It tracks the client relationship around the project, not the project documentation.
Then what is the CRM for around this?
There is a job, and it is the commercial one.
An RFI that sits for three weeks is a project problem. A GC whose RFIs consistently sit for three weeks is a commercial problem, and that is a pattern across jobs rather than within one.
- Which GCs cost you float, measured across years
- Which architects return submittals on time
- Whether to price a known-slow GC differently next time, or bid them at all
Your project system answers what happened on this job. Your CRM should answer whether to bid the next one. Almost nobody connects those two, and it is one of the more valuable integrations available to a contractor who bids repeatedly to the same handful of GCs.
Do you need a document system and a project system?
Depends which side of the contract you are on.
A GC running submittals with an architect needs the register. A specialty contractor receiving approved submittals mostly needs the current revision in the field, which is document management. Buying Procore to hold six PDFs is a common and expensive mistake, and so is running a GC's submittal process out of a file store.
Related: the full list of gaps and who fills each.