Google Apps Script

Job seekers often depend on major job boards, but companies also publish roles directly through their own career pages and applicant tracking systems.

Discovering those opportunities manually requires repeatedly visiting employer websites, checking whether positions are still active and determining whether individual roles are remote, relevant and still accepting applications.

The technical challenge was equally important. As the dataset grew, the original Google Sheets implementation became too slow for reliable searching and synchronization. Airtable improved the structure but still introduced performance limitations as the number of jobs and automated updates increased.

The platform needed a faster data layer capable of supporting continuous collection, cleanup, classification and frontend search without slowing down as the database expanded.

Google Apps Script automation monitors employer career sources and applicant tracking systems, retrieves available roles and transforms the source information into a consistent job structure.

Job records are normalized before being synchronized into Supabase, including information such as employer, title, location, remote status, category and original application URL.

Supabase replaced earlier Google Sheets and Airtable implementations as the primary data platform because it provided significantly faster querying and a more reliable foundation for a growing automated dataset.

WordPress provides the public discovery layer. Job seekers can search by keyword, browse categories, sort opportunities and open each role directly on the employer’s original career page.

Scheduled automation also maintains the quality of the dataset by refreshing sources and removing outdated opportunities instead of allowing stale listings to accumulate indefinitely.

Important finance, sales, procurement, warehouse and supply chain information lived across separate systems including Xero, Shopify, ShipHero, Zoho, ClickUp and spreadsheets. Teams often had to retrieve, compare and update information manually, while external stakeholders such as factories and logistics partners also needed to contribute data throughout operational processes.

The challenge was therefore larger than creating dashboards. The underlying workflows, data relationships and responsibilities first had to be structured so the company could manage purchase orders, B2B sales, shipments, reporting and operational coordination from consistent information as the business continued to grow.

ConsultEvo designed an architecture in which each source platform remains responsible for its core business function while shared automation, operational and data layers connect them.

Make, Google Apps Script, APIs and webhooks handle synchronization, orchestration and external data collection. ClickUp acts as the operational layer for processes including B2B sales, purchase orders, manufacturing, shipments and supply chain coordination. Supabase provides the centralized structured data layer used by reporting applications, dashboards and other internal tools.

Custom WordPress interfaces provide management dashboards, mobile-friendly reporting, factory and logistics tools and visual operational applications without requiring every user or external stakeholder to access the underlying systems directly.

The same architecture also supports AI interfaces that let staff query operational information in natural language, making business data easier to access and helping new employees understand information that would otherwise require knowledge of multiple spreadsheets and systems.

The sales exports contained customer information, product information, transaction values, quantities and dates in a flat tabular format.

Inside HubSpot, however, that information belongs across several related record types.

A customer belongs to a Company. The transaction belongs to a Deal. Individual products sold are represented through Line Items, which reference records from HubSpot's Product Library.

The import therefore had to determine whether a Company or Product already existed, create it when it did not, create the Deal and Line Item records, and then preserve the correct associations between them.

The process also needed to handle returns, inconsistent CSV headers, invalid values, duplicate processing, missing records and API failures without silently losing data.

ConsultEvo built a custom import application around the HubSpot CRM API.

Each incoming transaction is validated before processing. The system searches HubSpot for the customer using a unique customer number and searches the Product Library using SKU.

When matching records already exist, they are reused. When they do not exist, the required Company or Product record can be created from the source data.

The system then creates the Deal, creates its Product-backed Line Item and builds the required HubSpot associations so the transaction becomes part of the customer's actual CRM history rather than an isolated imported record.

Positive transactions are routed into the completed sales workflow, while negative quantities or sales values are recognized as returns and routed separately.

The importer also includes progress tracking, retry handling, duplicate protection, header mapping, detailed processing logs and exception reporting so import problems can be identified and corrected rather than disappearing inside a bulk migration.