Internal workshop · Buildertrend + automation

Build the workflow first. Automate only what survives reality.

Troy's ideas are sensible. The job now is to work out which parts Buildertrend already handles, which gaps are worth automating, and where the honest answer is simply “not yet”.

Start with one real jobTrace the actual movement of plans, POs, quotes, milestones, invoices and approvals.
Separate value from feasibilityA valuable idea can still be the wrong build if the connection point is unsupported or fragile.
Keep consequence humanFinal plan authority, financial exceptions and payment approvals stay with named people.
This is our working view. It intentionally separates confirmed Buildertrend capabilities from assumptions that still need Troy or Buildertrend to answer.
01 · Orientation

The goal is less admin — not “more AI”

The same outcome may be best solved by native Buildertrend configuration, rules-based automation, AI assistance, or no custom build at all.

BT

Buildertrend

Construction system of record. Use native jobs, schedules, POs, plans, bills, messaging, approvals and accounting integrations wherever they already fit.

Rule: never rebuild a feature Buildertrend already handles well.
↻

Automation

Runs predictable rules, timers, checks, imports, reminders and state changes. This should be deterministic wherever possible.

Rule: known trigger → fixed logic → explicit exception path.
AI

AI

Reads and interprets unstructured information: emails, quotes, plans, invoices, revisions and correspondence.

Rule: AI interprets; humans approve consequence.

Blunt feasibility position

No public customer API or self-service write interface into Buildertrend has been confirmed. We should therefore design around supported exports, imports, native integrations, email signals and human checkpoints until Buildertrend tells us otherwise.

✓ Confirmed? Must confirm△ Feasible with conditions× Not recommended
02 · Gate questions

These answers determine what we can actually build

These are not “nice to know”. They decide the architecture, the cost, the reliability and whether some ideas are feasible at all.

Questions for Buildertrend

Best answered by implementation/support in writing where possible.
QuestionWhy it mattersOwnerDecision it unlocks
Is there a customer, partner or private API available to an Australian account, and on what terms?This decides whether our workflow can communicate directly with Buildertrend rather than using imports, email or manual hand-off.BuildertrendDirect integration architecture
If API access exists, what can it read and write: jobs, schedules, POs, documents, bills, invoices, comments? Are webhooks available?Read-only access is very different from being able to safely push an approved result back into a job.BuildertrendWhich automations can be end-to-end
Which exports and imports are available in Troy's plan, and which features support bulk import?Imports may give us a clean supported return path even when no API exists.BuildertrendSheet → Buildertrend hand-off
Which task/schedule events can reliably generate external email notifications, and what information is contained in those emails?A dedicated Gmail account is only useful as a trigger if the notification reliably identifies the job, item, event and state.BuildertrendEmail-trigger workflow
What is Buildertrend's position on customers automating their own web interface?Current terms prohibit automated scraping/systematic acquisition without express written consent. We should not base a critical process on an unsupported workaround.BuildertrendWhether browser automation is off-limits
Which relevant capabilities are plan-tier dependent or planned on the roadmap: schedule-triggered actions, report delivery, document automation?Paying for/configuring an existing feature is better than building a parallel system.BuildertrendNative vs custom build

Questions for Troy

These define the real business workflow rather than the idealised one.
QuestionWhy it mattersOwnerDecision it unlocks
Which accounting platform is actually used — Xero, QuickBooks or something else — and who owns/administers it?We must not assume Xero. The accounting platform may become the financial source of truth and payment-status feed.TroyFinancial loop design
Can you show one real job from setup through completion?We need to see which steps happen in Buildertrend, email, shared folders, spreadsheets and accounting — not just what should happen.TroyEnd-to-end process map
How many jobs, POs, supplier quotes, plan revisions and invoices occur per month?Volume determines whether the build and maintenance cost is commercially justified.TroyPriority and ROI
Are job templates, cost codes, Bills Intake, plan tools, notifications and accounting integration already configured?Some of the requested automation may already exist natively.TroyWhat not to build
How is a plan or engineering document declared “authorised/final” today, and who has that authority?AI can detect revisions; it should not invent authority.TroyDocument-control checkpoint
How reliable and timely is supervisor completion tagging?If the trigger is late or inconsistent, automation will faithfully act on bad state.TroySchedule-trigger feasibility
How are supplier SKUs/descriptions mapped to Buildertrend cost codes today?This decides whether quote extraction can be deterministic after AI reads the document.TroyQuote automation design
What are the financial exception rules: price variance, missing PO, incomplete work, late client payment?The system needs explicit stop conditions and human escalation rules.TroyHuman approval matrix
Who can approve each consequential action, and when is secondary approval required?We should not assume a two-person rule, but we need a named fallback and authority model.TroyApproval and continuity design
03 · System map

A feasible architecture is a chain of responsibilities

This is the working model — not a committed build. The key is knowing who owns each state and where the hand-offs are supported.

Working system composition

Buildertrend stays the construction system. A workflow layer can sit around it only where there are reliable inputs and supported outputs.

Confirmed capabilityConnection must be confirmedOur control layer

Buildertrend

Construction system of record.

  • Jobs & schedules
  • POs / cost codes
  • Plans & files
  • Bills / invoices
  • Messaging & notifications
exports / email / API?

Dedicated Gmail

Possible event and document intake layer.

  • Supplier quotes
  • Buildertrend notifications
  • External documents
  • Controlled outbound mail
Apps Script reads / writes

Apps Script + Sheet

Initial workflow engine and operational state.

  • Rules & timers
  • Mappings
  • Approvals / exceptions
  • Event ledger
  • Audit history
safe human actions

Web app

Troy's human control panel.

  • Review queue
  • Approve / reject
  • Exceptions
  • Status / history
  • Generate imports

What we can control directly

  • Gmail intake and outbound email
  • Google Sheet state and audit data
  • Apps Script rules, timers and AI calls
  • Web-app review and approval screens
  • Generation of files/imports in known formats

What remains conditional

  • Buildertrend event output quality
  • Buildertrend import coverage
  • Any direct API access
  • Accounting platform and sync configuration
  • Whether workflow results need to be written back into Buildertrend

Example: one workflow event from field to action

This is how to think about every proposed automation: source → signal → interpretation → state → human checkpoint → supported action → audit.

1
Supervisor completes real work
→
2
Buildertrend event / email / export
→
3
AI interprets only if needed
→
4
Rule validates conditions
→
5
Human approval if consequential
Human: authority / judgementAI: read and interpretRule: deterministic logicUnknown: Buildertrend connection still to confirm
+ Practical composition: what the initial Google Sheet would store
Core tabs
  • Projects
  • Documents
  • Supplier_Quotes
  • Cost_Code_Map
  • Workflow_State
  • Approvals
  • Exceptions
  • Audit_Log
  • Settings
Typical event record
event_id
job_id
source_system
event_type
source_reference
occurred_at
processed_at
status
approved_by
result_reference

The Gmail inbox is not the ledger. Email is an input. The Sheet stores normalized state so duplicate messages, forwarding chains or deleted emails cannot cause duplicate actions.

04 · Six opportunities

Troy's brief, translated into practical implementation choices

Each idea below shows the likely route, the human checkpoint and the exact technical unknown that could stop or reshape the build.

Provisional value vs feasibility

Placement is deliberately provisional until Troy's volumes and live account are reviewed.

Business value increases ↑

High value / stronger feasibility

Good early candidates.

Supplier quote → cost mappingNative bill intakeTemplate standardisation

High value / conditional feasibility

Worth pursuing only if the connection point exists.

Schedule-triggered invoice workflowDocument version control

Lower priority

Useful, but probably solved by configuration or lower volume.

One-to-many document distribution

High risk / avoid as core design

May work technically, but not robust enough for a critical process.

Browser bot writes into BuildertrendAI authorises payment
Technical feasibility increases →
1

Standard documents attached to trade purchase orders

Approved plans, engineering and other standard documents should follow the relevant trade PO without repetitive uploading on every job.

Start nativeDo not build first

Likely route

First determine what job templates, schedule attachments, POs and shared files can already standardise. Only automate the residual gap.

Template / standard job setup
→
Trade PO + required docs
→
Troy checks exceptions
Human checkpoint
  • Approve non-standard documents or job-specific exceptions.
  • Confirm a later plan revision has not superseded the attached version.
Must confirm
  • Exactly what Buildertrend templates can carry into each new job.
Technical implementation + composition
If native is enough
  • No custom automation.
  • Define job types, standard document sets and PO templates.
  • Document the exception process.
If a gap remains
  • Sheet stores job/trade/document requirements.
  • Web app shows missing required docs.
  • Apps Script prepares a staging pack.
  • Final Buildertrend upload remains manual unless a supported import/API exists.
2

Recognise the authorised plan or document version

When revised plans arrive, identify the document, compare revision/date information and ask Troy whether it is the authorised version to rely on.

Good AI useWrite-back is conditional

Likely route

AI can classify and compare revisions outside Buildertrend. The system should never declare a drawing “authorised” on its own.

Email / Buildertrend input
→
Read title block + revision
→
Compare register
→
Troy authorises
→
Supported upload?
Human checkpoint
  • Troy/authorised person confirms final reliance status.
Must confirm
  • How revised plans arrive.
  • How Buildertrend supports revisions after upload.
  • Whether there is a supported upload/import/API path.
Technical implementation + composition
Gmail / document intake
  • Dedicated mailbox receives external plans or forwarded copies.
  • Apps Script stores attachment metadata and file reference.
  • AI extracts drawing number, discipline, issue date and revision.
Sheet / web app
  • Documents tab stores revision lineage.
  • Workflow flags newer-than-current revisions.
  • Web app offers Approve / Reject / Supersede.
  • Audit log records who authorised the version.
document_id
job_id
drawing_no
revision
issue_date
status
approved_by
supersedes_id
3

Disperse one document to multiple trades or suppliers

Engineering or other shared information should be distributed once, not repeatedly attached or sent to each recipient.

Likely native firstVerify live workflow

Likely route

Buildertrend already supports job-specific Messaging and feature comments/attachments. Check whether the required distribution can be handled natively before introducing another channel.

Approved document
→
Buildertrend job / message / file
→
Relevant trades / suppliers
Human checkpoint
  • Confirm audience and whether the document is approved for external distribution.
Must confirm
  • Whether each trade can access the same source file without duplicate attachment work.
Technical implementation + composition

Buildertrend Messaging behaves like job-specific email and can send to internal users, subs/vendors, clients and limited external addresses. Comments are feature-specific. External email can also be forwarded into the job's unique Buildertrend address. The cleaner design may simply be to standardise how documents are stored and shared inside the job.

4

Supplier quote → structured prices and cost codes

Read a supplier quote containing dozens of products, update prices efficiently and map items to the right coded cost structure.

Strong early candidateHigh value, controllable risk

Likely route

This can be mostly solved outside Buildertrend. AI reads the quote; deterministic mappings handle known SKUs; Troy reviews exceptions; the system generates whatever supported import/update format Buildertrend accepts.

Quote email/PDF
→
Extract 40 lines
→
Map known SKUs
→
Review unknowns
→
BT import / manual update
Human checkpoint
  • Approve new mappings, abnormal price changes and ambiguous items.
Must confirm
  • Which Buildertrend catalogue/cost-code imports are available.
  • Supplier SKU stability and quote volumes.
Technical implementation + composition
Data path
  • Gmail receives quote.
  • AI extracts supplier, quote number, expiry, SKU, description, qty, unit price.
  • Rules join SKU to Cost_Code_Map.
  • Price-delta threshold flags outliers.
  • Web app presents only exceptions.
Output
  • Approved rows update Supplier_Quotes / Price_Register.
  • Apps Script generates a Buildertrend-compatible file where supported.
  • If no supported bulk update exists, output becomes a clean review list rather than a browser bot.
supplier_sku
cost_code
unit_price
effective_from
expires_on
confidence
price_delta_pct
review_status
5

Schedule-triggered invoices, reminders and escalation

A verified field milestone should trigger the next administrative action without accounts staff manually remembering every step.

High value / conditionalTrigger + accounting path must be proven

Likely route

The workflow logic itself is straightforward. The hard part is getting a reliable completion signal out of Buildertrend and a reliable financial state from the actual accounting system.

Supervisor marks complete
→
Reliable external signal?
→
Rule validates
→
Approval if required
→
Accounting action
Human checkpoint
  • Exception handling, unusual amounts, disputes and any required approval before issue.
Must confirm
  • Task/schedule completion notification content.
  • Accounting platform.
  • Where invoices are actually created and how payment is recorded.
Technical implementation + composition
Trigger options
  • Best: webhook/API event.
  • Possible: structured Buildertrend email notification into dedicated Gmail.
  • Fallback: periodic report import.
  • Not preferred: browser automation.
Workflow state
  • Store event once using an idempotency key.
  • Record invoice reference, due date and reminder state.
  • Accounting system supplies authoritative payment status if integration/API exists.
  • Paid → stop reminders. Exception → human queue.

Important: do not assume Xero. If Troy confirms Xero, Buildertrend's current integration can push invoices/bills to Xero and payment status can sync back to Buildertrend. If they use another platform, the design changes.

6

Supplier invoice recognition and approval

Recognise incoming invoices, connect them to the correct job/cost/PO, confirm completion and route them for approval with less manual entry.

Native feature existsInspect before building

Likely route

Buildertrend already has a Bills Intake inbox. Bills can be emailed in, AI extracts vendor/dates/cost items, drafts can be reviewed, linked to a PO and approved before accounting sync. This may remove a substantial part of the proposed build.

Supplier invoice email
→
Buildertrend Bills Intake
→
Native AI extraction
→
Review / code / link PO
→
Approval
Human checkpoint
  • Job/PO selection, coding exceptions, completion confirmation and approval.
Must confirm
  • Whether Troy's account has this feature enabled and whether it satisfies the actual workflow.
Technical implementation + composition

Before building any external invoice-recognition tool, test Buildertrend's native Bills Intake with real supplier invoices. Buildertrend documents a unique Bills Intake email, AI-created draft bills, duplicate detection, PO linking and in-platform approvals. Gmail can even auto-forward supplier invoices to the Bills Intake address. If native coverage is adequate, our custom layer should focus on the missing exception or reporting need only.

05 · Priority

Suggested order: prove the plumbing before building the clever parts

The priority is not simply “highest business value first”. We need early wins that also teach us how Buildertrend behaves in Troy's real environment.

P0

Live Buildertrend discovery + one real job walkthrough

Confirm plan tier, native features, messaging, notifications, imports/exports, bills intake, accounting and real staff behaviour.

Importance100%
P1

Supplier quote → cost-code / price register prototype

Strong candidate because most intelligence can happen outside Buildertrend and the human checkpoint is obvious.

Current confidence85%
P2

Test native Bills Intake and approval workflow

May eliminate the need to custom-build invoice recognition.

Native opportunity90%
P3

Document version-control prototype

Build the external detection/register/review flow first; only decide Buildertrend write-back after integration options are known.

Current confidence70%
P4

Schedule-event proof of concept

Test whether a completion event can be detected reliably outside Buildertrend without scraping.

Current confidence45%
P5

Financial follow-up workflow

Only after the trigger and accounting source of truth are confirmed. Keep exception and consequential approval paths human.

Current confidence40%

Confidence percentages are internal planning estimates, not measured performance or promises.

06 · Boundaries

Operational boundaries that keep the workflow practical

This section is not a lesson on AI. It is the short list of business boundaries we should keep in place so the workflow stays workable for Troy and the team.

Final plan approval stays with a person

The system can help sort and compare revisions, but Troy or another named person still decides which document is final.

Financial approval stays with a person

The workflow can prepare invoices, reminders and approval queues, but payment approval and unusual exceptions should not be handed to AI.

One source of truth for each category

Buildertrend stays the construction record. The accounting platform stays the financial record. The Sheet only holds the workflow state we need to run automation.

Fix weak triggers before automating downstream

If supervisor completion tagging is inconsistent today, we should fix that first. Otherwise the automation will simply repeat a bad signal faster.

What we should not build the first version around

×
Do not assume direct AI control of Buildertrend.We have not yet confirmed a supported customer write path.
×
Do not use browser scraping/automation as the main architecture.It is both fragile in practice and contractually sensitive unless Buildertrend says yes in writing.
×
Do not let the Sheet become a second unmanaged system.It should support the workflow, not compete with Buildertrend or the accounting platform.
×
Do not automate around missing business rules.If nobody has agreed who approves what, the right answer is to settle the rule first, not automate the confusion.
07 · Technical findings

What we know now — and how it changes implementation

These are the practical findings tucked behind the “+” so Troy can stay at the business level unless the deeper implementation detail is useful.

Buildertrend Messaging is job-specific email — but that does not equal API access

Buildertrend Messaging can send and receive messages tied to a job. External emails can be forwarded into a job using a unique Buildertrend address, and replies to messages originally sent from Buildertrend are tracked back into Buildertrend.

Implementation implication: Buildertrend can centralise project communication, but we still need to confirm whether external automation can programmatically monitor or act on the Buildertrend inbox. A separate Gmail account may still be useful as an automation-facing channel.

Verified against Buildertrend Help Center: Messaging Overview.
Buildertrend can email task completion notifications

Buildertrend Tasks support email/push notifications for completed or reopened tasks, depending on notification preferences. Schedules also have reminder and notification features.

Implementation implication: a dedicated Gmail account could potentially receive a completion signal. We must inspect the actual notification to see whether it contains a stable job/task identifier and sufficient context for deterministic processing.

Verified against Task Management Overview and Advanced Scheduling Overview.
Buildertrend already has AI-assisted Bills Intake

Bills can arrive via Buildertrend's unique intake email, bulk upload or mobile capture. Buildertrend documents AI extraction of vendor, dates and cost items, draft bills, duplicate detection, PO linking and approval workflow.

Implementation implication: do not build external invoice recognition until we have tested the native Bills workflow. Gmail can be configured to auto-forward supplier invoices into Buildertrend's Bills Intake address.

Verified against Bills Management Overview and Cost Inbox & Bills FAQs.
Buildertrend supports some imports — but not a universal import layer

Cost codes can be imported; Selections/Allowances support Excel bulk import; schedule templates can be imported through supported processes. The scope differs by feature.

Implementation implication: our Sheet can become a staging and transformation layer that generates supported import files, but we must verify the exact feature/import format needed for each Troy use case.

Verified against Cost Codes Overview, Selections & Allowances Overview, and Buildertrend schedule documentation.
Xero is a valid option only if Troy confirms they use it

Buildertrend's current Xero integration supports Buildertrend → Xero transfer for jobs/contacts, bills, invoices and credit memos, and Xero → Buildertrend payment updates for invoices and bills.

Implementation implication: if Troy confirms Xero is the accounting source of truth, payment state can potentially be observed reliably without inventing our own ledger. If they use QuickBooks or another platform, the architecture must be redesigned around that system.

Verified against Xero Integration Overview. Accounting platform remains unknown.
Browser automation is both fragile and contractually sensitive

Buildertrend's current Terms and Conditions prohibit using scripts, crawlers, robots or other automated processes to copy, scrape or systematically acquire content without express written consent.

Implementation implication: we should ask Buildertrend directly about customer browser automation. Until written comfort exists, critical workflows should use native features, supported imports/exports, official integrations, email signals and human steps rather than stored credentials and browser bots.

Verified against Buildertrend Terms and Conditions Agreement, last updated 24 June 2026.
Why Gmail + Sheet + Apps Script is a sensible first control layer

This is not because Google Sheets is the perfect permanent database. It is because it gives us a fast, inspectable and low-friction prototype environment for Gmail events, state, mappings, approvals and audit records while Troy's real process is still being learned.

Implementation implication: the web app is the human interface; Apps Script is the glue/rule engine; the Sheet is the initial operational state store. If the workflow becomes high-volume or financially critical, we can later replace the Sheet/Apps Script backend with a proper database/service while preserving the same front-end concepts.

System of recordThe authoritative system for a category of information. Buildertrend should remain authoritative for construction project state.
Operational stateExtra workflow information we need to run automation: pending review, reminder stage, mapping confidence, exception state, etc.
IdempotencyA duplicate event can be received twice without causing the action twice. Essential for invoices, reminders and approvals.
Human-in-the-loopAutomation prepares or recommends; a named person approves the consequential action.
08 · Takeaway

The position to take into the meeting

Positive about reducing administration. Conservative about feasibility. Build only where the workflow, system boundary and human authority are clear.

A successful first meeting does not need a finished solution

  • We can draw one real job from start to finish and identify every system hand-off.
  • We know which of Troy's six requests Buildertrend already handles natively.
  • We have real samples: PO, plan revision, supplier quote, supplier invoice and progress-claim trigger.
  • We know which accounting platform is authoritative and who owns it.
  • We have a short list of questions to put directly to Buildertrend.
  • We can identify one low-risk proof of concept without pretending the rest is already solved.
Evidence basis: our internal assessment plus current Buildertrend Help Center and Terms research checked 15 September 2026. Platform capabilities should still be confirmed against Troy's live Buildertrend account and, where access rights matter, directly with Buildertrend before implementation commitments are made.