HubSpot
28 Sep 2026

How We Helped an Australian Non-Bank Lender Turn Broker Emails Into Complete HubSpot Deals

Record Types Created Automatically
Event-based HubSpot nurturing now guides trial users to search, invite, and book creators, instead of leaving them alone after signup.

~35

HubSpot Properties Written Per Deal
Meta Ads, cold email, and drip email now work as one connected funnel that moves high-fit brands from first click to paid subscription.

Project Overview

Project Name

Automated Loan Enquiry Intake for HubSpot

Project Scope

Dual inbox email capture, AI-led data extraction, external property data enrichment, HubSpot record creation and association, integration with existing pricing and product selection automation

Industry

Non-Bank Lending and Commercial Property Finance

Work Duration

2 months

Resource Used

1 Project Manager
1 Backend Developer
1 CRM Specialist

Technologies

Country

Australia

Our Capabilities

Email Capture and AI Extraction

Gmail and Outlook 365 intake pipelines
Single-call LLM extraction across body and PDFs
Attachment-over-email source precedence
Message ID idempotency and duplicate control

HubSpot Architecture and Data

Custom objects for Security, Trust and Encumbrance
Seven record types with labelled associations
~35 deal properties mapped to existing fields
Broker contact upsert without duplication

Enrichment and Quality Engineering

Google Geocoding and Cotality property data
Confidence thresholds on every external write
Per-record error isolation and structured logging
1,155+ automated tests built from real enquiries

Client Overview

Our client is a privately owned Australian non-bank commercial lender. They fund short-term and specialist property-backed loans, and almost all of their business arrives through a broker network rather than direct applicants.

A broker sends an email. It might be three lines with a PDF attached, or a long scenario covering two security properties, a trust structure and an existing mortgage. Nothing about it is standardised.

The client had already invested heavily in HubSpot. Custom objects for securities, trusts and encumbrances were in place. So were the automations that matter most to them: an LVR reduction and rate matrix engine, a product selection model that sorts deals into four lending products, and a file numbering workflow that builds the SharePoint folder for each deal. All of it worked. All of it waited on a human to type the deal in first.

Their Challenges

Every enquiry started as manual data entry:
Roughly 35 fields per deal, spread across seven record types, all keyed in by hand from an email and its attachments before any of the client’s automation could run.

Two inboxes, two habits:
Brokers use whatever their brokerage runs, so enquiries arrived in both Gmail and Outlook 365. Any solution had to watch both without the team maintaining two sets of logic.

The email never held the full picture:
Construction type, floor area, zoning, and whether a suburb counts as metro all affect pricing, and a broker almost never states them. Someone had to look each property up separately.

Multi-security scenarios were easy to flatten:
An enquiry offering two properties as security is two distinct records with two distinct valuations, positions, and encumbrances. Under time pressure, they tended to get merged into one.

Speed and accuracy pulled against each other:
Faster entry meant more guessed fields, and a guessed field is worse than a blank one here. A plausible but wrong property type silently changes the LVR, the rate, and the product a deal is offered.

Our Strategies

Fed the automation that already worked:
The rate matrix, product selection, and file numbering workflows were proven, so we did not touch them. We built a system that hands them the same facts a human would have typed, labelled the same way, so every existing report, view and workflow treats an automated deal exactly like a manual one.

Built one pipeline behind two front doors:
Gmail and Outlook are captured by separate watchers, but both normalise their payload and post to the same backend endpoint, so there is no channel-specific behaviour anywhere downstream.

Used one extraction call rather than a chain:
A single LLM call reads the email body, the quoted thread, and the parsed text of every PDF attachment together, and where the attachment and the body disagree, the attachment wins, because that is how a credit analyst reads the same pack.

Made “never guess” the governing rule:
Every property is extracted, confidently derived, or left blank, held in place by four principles.

An absence is not a “no”:
An email that does not mention an ABN does not mean the company lacks one, so that field stays blank rather than being written as false.
External data must clear a confidence bar:
Property data is only written at medium or high confidence, and the address match must resolve to a single exact or probable property. A fuzzy match between candidates writes nothing.
A logical deduction is not a guess:
If the extraction found no company and no trust anywhere, then “is the security owned by the borrowing company or trust” is provably false, not unknown. That is the one place the system infers rather than waits.
A stated fact outranks an inferred one:
External property data only fills a gap the broker left open, and never overwrites something the broker actually said.

Our Planned Solutions

1. Dual inbox capture

An n8n Gmail trigger polls the inbox every five minutes for subjects matching loan, mortgage, enquiry, or application, then pulls the full message and its PDF attachments through a follow-up API call. A parallel workflow queries Microsoft Graph directly for Outlook 365 on the same cadence, with a six-minute lookback so nothing falls between polls. Both post an identical payload shape to one NestJS endpoint.

2. Duplicate protection before anything is written

The backend keys every request on the email’s own message ID. If that message has been processed, the request stops there. No second deal, no re-extraction.

3. A single extraction call

PDFs are parsed, then one LLM call (OpenAI or Anthropic, switchable) pulls out:

Borrowing entity: name, ACN, ABN, registered address
Broker: name, brokerage, email, phone, brokerage fee. The sender’s address is used as a fallback only when a brokerage alone is named, never on an internal forward
Every security property as its own entry: address, estimated value, mortgage position, purpose, property type, condition, use and existing encumbrance, never merged even when one scenario offers two properties
Loan: amount, LVR, term, purpose, exit strategy, settlement date
Trust details when the borrowing entity is a trustee
Guarantors, plus officeholders and shareholders taken from an attached ASIC extract only, used to resolve each guarantor’s capacity

If the call decides this is not a genuine loan enquiry, nothing is written to HubSpot at all.

4. Three enrichment lookups per security

Lookup	Source	What it fills
Geocoding	Google Geocoding API	Street address, suburb, state, postcode, map URL, matching HubSpot’s own Find Place card
Property data	Cotality (CoreLogic AU)	Property type, gross floor area, property use, zoning
Classification	Internal suburb lookup	Capital city and metro status, reused from the existing rate matrix engine rather than rebuilt

Each one is designed to degrade to a blank field, never to a guess.

5. Seven record types, created and associated

Record	HubSpot type	Created
Company	Native	Borrowing entity
Deal	Native	One per enquiry
Contact (broker)	Native	Upserted by email, never duplicated
Contact (guarantor)	Native	One per named guarantor, capacity-labelled where resolvable
Security	Custom object	One per distinct property offered
Trust	Custom object	Only when a trust is named
Encumbrance	Custom object	One per existing mortgage disclosed against a security

Association labels match what the sales team already uses, so the records read as though a person created them.

6. Handing off to automation that already existed

LVR reduction and rate matrix: property type, condition, use and the specialised-asset flag on each security cascade straight into the existing calculation
Product selection: four of the seven checkbox questions that sort a deal into the client’s four products are now answered automatically, including one resolved by logical deduction rather than extraction
File numbering and SharePoint: a pre-existing workflow watches HubSpot’s own deal creation event, so intake only had to get the deal name right

The Result

An enquiry that used to wait for someone to open the inbox now lands in HubSpot as a complete, connected deal within minutes of the broker hitting send.

2 inboxes watched on one pipeline, Gmail and Outlook 365
7 record types created and correctly associated per enquiry
~35 HubSpot properties written per deal, with no manual entry
4 of 7 product selection questions answered automatically
1,155+ automated tests guarding the pipeline

Tested against live broker emails

Every issue below was found by processing genuine broker enquiries and checking the HubSpot output against what should have happened, rather than by guessing at edge cases in advance.

Issue	What happened	Fix
Duplicate deals	A manual test followed by the normal poll processed one email twice, creating two deals with inconsistent re-extracted data	Idempotency guard in the backend, keyed on the email’s own message ID rather than the email platform’s tracking
Extraction cut off mid-response	A complex multi-security enquiry hit the model’s output limit, failing the whole request with no record created	Raised the token ceiling, and the failure now reports why instead of returning a bare “no output”
Occupancy written with unearned confidence	A confidence signal was read from a field name that does not exist on the live API response, so the check never fired and a low-confidence read was written as fact	Corrected the field name, plus a same-day regression test built from the exact real response that exposed it
One bad contact aborted the whole intake	A broker identified only by brokerage name produced an empty update request, which the CRM rejected, taking down every other record in that request	Each sub-record now fails independently and is logged, never bringing the rest of the deal down
Security and geocoding misaligned	When an earlier security in a multi-property scenario had no address, later securities’ location data attached to the wrong property	Paired each security with its enrichment result before filtering, not after
Vendor documentation was wrong	The property data provider’s published guide named the wrong token endpoint and an extra URL path segment, both returning 404	Corrected against the live account after confirming with the vendor’s own portal

A foundation the next phase can trust:

The system reads an enquiry and populates HubSpot accurately. It does not yet decline a deal outside policy, ask a broker a clarifying question, or draft an approval. That decision layer- an eight-step credit policy specification of roughly 130 rules covering security eligibility, scenario, pricing, entity, guarantors, and policy overlays- is scoped as the next phase, designed to run in shadow alongside manual assessment before it is ever allowed to send anything on its own.

Share Blog: