Procore daily log automation by SMS

The Procore daily log everyone says they need and almost nobody actually fills out

If you ran a survey of commercial GCs and asked which Procore module is “critical” to project oversight, the daily log would land in the top three every time. If you then pulled the actual completion data — how many daily logs got filled out, by whom, when — the gap between “critical” and “happening” would be hilarious in a way that stops being funny when a claim or an OSHA incident comes up six months later.

The pattern is consistent across every commercial GC we’ve talked to. The daily log is supposed to be entered by the superintendent or foreman at end-of-day from the jobsite. In practice, it’s entered by an APM or a PM on Monday morning from the office, reconstructed from text-message screenshots, a half-legible whiteboard photo, and a phone call to the super who remembers about 60% of what happened on Wednesday. The dropdowns get filled with plausible-sounding answers. The weather section gets the wrong precipitation. The headcount is off by two trades. And the manhour rollup the PM sends to ops by COB Monday is fiction by 4pm Friday.

This isn’t a Procore problem. Procore’s daily log module is fine. It’s a workflow problem: the foreman who has the information isn’t the person who has the time or the tolerance to open an app at 5pm after a 12-hour shift to fill out a 30-field form. Until you fix that, the daily log will keep being a thing PMs do for compliance theater rather than a thing operations uses to manage the job.

What “fixing” actually means

The fix isn’t a better app. Field operations has had better apps for ten years. The completion rate hasn’t moved. The fix is a different surface — one the foreman already uses without thinking.

Foremen text. They text the super. They text their wife about being late. They text the trade partner foreman about a clash they just saw on the deck. They will text a phone number eight times a day before they will open an app once. That is the workflow that already happens.

The intervention that moves daily log completion from 30-40% to 90%+ is making the daily log itself textable. The foreman texts a number at end-of-day, the system asks the three questions that actually matter (who was on site, what got done, anything blocking tomorrow), and the structured answer lands in Procore as a complete daily log entry by 5:15pm. The whole exchange takes 90 seconds because it’s three messages back and forth, not 30 form fields.

How an SMS daily log works end to end

The mechanics are simpler than they sound. Four moving parts:

1. A phone number the foreman texts. One number per project, or one shared number that identifies the foreman by the originating phone number on file. Both work. We default to a shared number because foremen lose paper post-its with project-specific numbers on them.
2. A conversational prompt at end-of-day. Either the foreman texts first (“done for the day”), or the system sends an end-of-shift prompt at a time the foreman has configured. The opening question is always the same: “Quick log — who was on site today, what got done, anything blocking tomorrow?”
3. Structured extraction. The foreman replies in plain English. The system parses headcount by trade, scope of work completed, blockers, weather (pulled from a weather API based on the project’s address), and any safety items called out. This is where Forward earns its keep — the LLM has to be reliable enough that the structured fields are right, and conservative enough that ambiguous text becomes a follow-up question rather than a wrong answer.
4. Procore write-back. The structured daily log entry is written to Procore via the Daily Log API. The foreman gets a one-line confirmation (“Log saved for Wednesday, May 14. PM notified.”) and the entry shows up under their name in Procore with the correct timestamp.

The fifth thing, which is what actually makes the workflow stick, is that the PM sees the entry in real time. Not Monday morning. Real time. The PM gets a Slack or Procore notification when the foreman logs out, can look at it before going home, and can text the foreman back if something looks off. That feedback loop is what turns daily-log compliance into daily-log usefulness. When the foreman knows the PM actually reads it the same day, they start putting real information in it.

The hard parts (and what we did about them)

Headcount parsing without misreads

A foreman texting “had 4 plumbers, 2 carps, 1 op eng on the deck” needs to come out the other side as a clean headcount table with the right trades mapped. The vocabulary is regional (“op eng” in some markets is “operator” in others), the abbreviations are inconsistent, and the partial counts (2.5 plumbers = one half-day) need to round correctly. We built a trade-vocabulary normalization layer specific to commercial construction, trained on actual daily log entries from a sample of GCs, that hits 97% accuracy on first parse. The remaining 3% triggers a single follow-up question rather than a guess.

Weather without the foreman typing it

Procore wants weather conditions, temperature high/low, and precipitation. Foremen will not enter this. We pull it from a weather API keyed to the project address and the date, so the daily log gets accurate weather data without the foreman touching it. If a foreman explicitly contradicts the API (“rained on the deck after lunch, weather says clear”), the foreman wins.

Conflict resolution when two foremen text the same project

A union job with separate concrete and steel foremen running the same project will both want to log. The system disambiguates by phone number on file and creates separate daily log entries under each foreman’s name, which Procore handles cleanly. The PM gets both entries and can roll them up if they prefer a single combined log.

What happens when a foreman doesn’t text back

We send one nudge at the configured end-of-shift time, one nudge 30 minutes later, and then we stop. We don’t escalate to the super, don’t ping the PM. The foreman either logs or they don’t. Trying to push harder breaks the trust that makes the workflow work in the first place. The completion rate at most pilots stabilizes around 88-94% inside three weeks — meaningfully higher than any app-based approach we’ve seen, and we treat the missing 6-12% as an honest data point about what’s actually happening on jobs, not a failure to chase.

Rollout: what it looks like at a real GC

A 12-week rollout for a commercial GC with 6 active projects and 30 active superintendents and foremen breaks down roughly like this.

Weeks 1-2 (one project, two foremen). Pick one project, ideally one with an engaged super. Set up the Procore Daily Log API integration (one afternoon for IT). Tell two foremen the number and the prompt format. Let them text it. Don’t change anything else. Look at the entries Friday afternoon and see if they’re structurally correct.

Weeks 3-4 (expand to one project’s full crew). Roll out to all foremen on that project. The super sees the entries flow in, and starts noticing things they wouldn’t have noticed Monday morning. This is the moment the PM stops thinking of this as “an integration” and starts thinking of it as “how we run jobs now.”

Weeks 5-8 (second and third project). The pattern is now clear. Roll out two more projects. The pilot project’s PM is now an internal champion and will sell it to the other PMs without you having to.

Weeks 9-12 (remaining projects + ops dashboard). Roll out the remaining projects. Add the ops dashboard that rolls up the daily log data across all active jobs into a single end-of-day view. This is the artifact that makes the CFO start to care, because manhour burn versus budget becomes a live number rather than a weekly fiction.

After 12 weeks, the completion rate at the most recent rollouts is 89-94% sustained, the daily log entries are structurally complete enough to support a real manhour-burn analysis, and the PMs are spending Monday mornings on things that aren’t reconstructing the prior week.

The math on PM time

The number we hear most often is that a PM spends roughly 4-6 hours a week reconstructing daily logs that should have been entered at end-of-day. Cut that to 30 minutes a week (spot-checking entries and addressing exceptions) and you’ve given each PM back the equivalent of half a day per week. For a GC running 20 PMs, that’s 80-100 hours of PM time per week recovered, which translates to either more jobs per PM or less burnout. Neither outcome shows up in a Procore feature comparison. Both show up in retention and bid capacity, which are the metrics that actually matter to GC ops.

Try it before you buy it

If you want to see what a Forward-style daily log looks like without a sales call, text +1 (682) 300-6750 from any phone. Send “done for the day, 6 plumbers and 2 ironworkers on the second-floor MEP rough-in, hit a clash on the chase wall, ironwork starts second-floor decking tomorrow weather permitting” and see what the structured output looks like. It’s running off a sample Procore project we keep stocked for demos. The point of the demo isn’t to wow you — it’s to show you what your foremen’s daily logs would actually look like if you stopped making them fight an app to enter them.

If the structured output is close enough to what you’d want a daily log to be, the next step is a 20-minute call to scope a pilot on one of your projects. We don’t ask for procurement docs, contracts, or a corporate IT review for the pilot. One project, two foremen, two weeks. If it doesn’t move the completion rate by week 2, you’ve lost an hour of setup time and nothing else.