ERP for Geotechnical Engineering Firms: Field Data to Report in One Workflow

The Boring Log Is the Bottleneck, Not the Lab

Ask a geotechnical firm's principal engineer where projects actually slow down, and the honest answer is rarely the laboratory. Atterberg limits, standard Proctor curves, and grain-size analyses run on a predictable schedule once a sample reaches the lab bench. The real bottleneck sits earlier: a field technician standing next to a drill rig, filling out a boring log by hand on a clipboard in the rain, recording blow counts every six inches, bagging split-spoon samples, and hoping the handwriting survives the drive back to the office legibly enough for a CAD drafter to redraw it two weeks later. Every step in that chain — field sheet to typed log, typed log to lab assignment, lab result to report table, report table to a professional engineer's final review — is a place where a transposed number, a missing sample ID, or a lost field sheet can quietly corrupt the data a foundation design depends on.

Most geotechnical firms run either generic project management software with boring logs bolted on as PDF attachments, or a purpose-built geotechnical logging tool that doesn't talk to the firm's accounting or scheduling system at all. Neither gets you what a modern operation needs: one continuous data thread from the drill rig to the sealed report to the invoice, with nothing manually re-keyed in between.

What a Geotechnical Job Actually Requires the Software to Track

Field Data Capture: Borings, SPT Blow Counts, and Driller Logs

A single subsurface investigation can involve a dozen or more borings, each logged at 2.5- or 5-foot intervals, with Standard Penetration Test (SPT) blow counts recorded per ASTM D1586 at every sampled interval, soil descriptions per the Unified Soil Classification System (ASTM D2487), groundwater observations, and driller's notes on caving, artesian conditions, or refusal. A field data platform needs to let a technician enter this on a tablet at the rig — offline-capable, because most drill sites don't have reliable signal — and sync a structured record, not a scanned sheet, the moment connectivity returns. The distinction matters: a structured N-value at 8.5 feet on Boring B-3 is a queryable data point that auto-populates a boring log template and feeds directly into bearing-capacity calculations; a photo of a handwritten sheet is not.

Sample Chain: Jar Samples, Shelby Tubes, and Lab Assignment

Every split-spoon jar sample and every thin-wall Shelby tube pulled from a boring needs a unique ID that ties back to the exact boring and depth it came from, a defined storage and transport protocol (undisturbed Shelby tube samples are moisture-sensitive and need to be sealed and handled to avoid disturbance before consolidation or triaxial testing), and an assignment to a specific lab test program. On multi-boring, multi-sample projects, losing track of which jar corresponds to which depth interval is a real and recurring failure mode when sample tracking lives in a technician's memory instead of a system.

Laboratory Testing Queue and Result Linkage

Once samples reach the lab, the software needs to route them into the correct test queue — moisture content (ASTM D2216), Atterberg limits (ASTM D4318), particle-size analysis (ASTM D6913 for sieve, D7928 for hydrometer), standard or modified Proctor (ASTM D698 / D1557 or AASHTO T99 / T180), consolidation (ASTM D2435), or triaxial shear (ASTM D4767 for CU tests) — and link every result back to the originating boring and depth automatically. A platform that requires an engineer to manually cross-reference a lab result sheet against a boring log to build the final report table is reintroducing the exact transcription risk the field data capture was supposed to eliminate.

Standards That Shape the Data Model: ASTM, AASHTO, and State DOT Specs

Geotechnical practice is governed by a dense stack of ASTM and AASHTO test methods, and state departments of transportation frequently layer their own geotechnical manuals and reporting formats on top for public infrastructure work — TxDOT, Caltrans, FDOT, and NYSDOT each maintain their own boring log formats and minimum investigation criteria that a firm doing DOT work has to match exactly. Software built for a generic "field services" market usually has no concept of any of this; software built specifically around geotechnical or materials-testing workflows should let you configure report templates and required test sets per client or per project type — a bridge foundation investigation for a state DOT looks structurally different from a shallow foundation study for a retail pad site, and the system should support both without a developer ticket every time a new client format shows up.

Report Generation: From Raw Field Sheets to a Sealed PE Report

The deliverable that actually matters to the client is the geotechnical report: boring logs, a subsurface profile, laboratory summary tables, bearing capacity and settlement analysis, foundation recommendations, and a professional engineer's stamp. Every one of those components should be able to pull directly from the field and lab data already in the system — a subsurface profile cross-section generated from actual boring coordinates and depths, a lab summary table populated from linked test results, not retyped from a printout. The time this saves is not trivial: geotechnical firms that still manually rebuild report tables from separate field and lab records routinely lose a full day or more of an engineer's time per project just on data assembly before the actual engineering judgment — bearing capacity, settlement, slope stability — even begins. That is professional engineering time spent on data entry instead of the analysis the client is actually paying for and the PE stamp is certifying.

Field-to-Office Latency: Why Paper Boring Logs Still Cost Firms Real Money

The gap between "field data collected" and "field data usable by the office" is where geotechnical firms bleed margin without noticing. Paper logs sit in a truck for days before being typed. Typed logs sit in an inbox before being checked against the original field sheet. A revision to a boring location or a re-classification of a soil layer after lab results come back requires someone to remember to update three different documents by hand. Each of these gaps adds latency to project delivery and adds risk that the final report doesn't match the field reality. A connected field-to-report workflow collapses that latency to the sync delay of a tablet reaching cell coverage, and it eliminates the entire category of error where a typed log simply doesn't match the technician's original handwritten sheet.

Evaluating Platforms: Geotechnical-Specific vs General Field-Service Software

Firms evaluating new software generally land in one of three camps: a narrow, geotechnical-specific logging tool that handles boring logs well but has weak project accounting and no real CRM; a broad, generic field-service or construction ERP that handles scheduling and invoicing well but treats a boring log as a free-text attachment; or a configurable platform built for technical, standards-driven field inspection work that can be shaped to either discipline. The right evaluation question isn't "which tool has the prettiest boring log template" — most decent tools clear that bar — it's "does this system carry a sample or data point's full context (boring, depth, test method, standard, technician, instrument) as structured data all the way from field collection through the final signed report, with billing and project tracking in the same data model rather than a bolted-on integration." Ask vendors to demonstrate that chain live, end to end, on a real multi-boring project, not on a curated single-sample example. Also ask what happens when a project spans multiple report revisions — a common scenario when a structural engineer's foundation loading changes after the geotechnical report is issued and the firm has to reissue recommendations. The system should carry version history on both the analysis and the report itself, so it's always clear which boring data and which lab results supported which revision of the recommendations a structural engineer is relying on.

Multi-Discipline Firms: When Geotech, Materials Testing, and Special Inspection Share One Backlog

Many mid-size geotechnical firms don't do geotechnical investigation alone — the same crews and the same back office also run construction materials testing (soil compaction verification with a nuclear density gauge per ASTM D6938, concrete cylinder breaks per ASTM C39, and asphalt density) and special inspection services under building code requirements. Running geotechnical field logging in one system, materials testing in a second, and special inspection reporting in a third means three separate scheduling calendars, three separate invoicing streams, and three places a client's project history is scattered. A unified platform that can model all three workflows — distinct data structures, shared client and project records, one crew scheduling calendar, one accounts receivable ledger — is where firms doing this kind of multi-discipline work see the real efficiency gain, because dispatch, invoicing, and client reporting stop being duplicated three times per project.

Equipment and Calibration Records: Rigs, Gauges, and Lab Instruments

Geotechnical firms carry more calibrated and maintained equipment than most clients realize: nuclear density gauges require annual calibration and a leak-test certificate to stay legally operable and transportable, consolidation frames and load cells need periodic verification, balances used for moisture content testing need routine calibration checks against certified weights, and drill rig hammers used for SPT testing should have documented energy-transfer ratios on file, since hammer efficiency directly affects the reliability of blow-count-based correlations engineers use for bearing capacity and liquefaction analysis. A firm running this equipment across multiple field crews and a home lab needs calibration due dates tracked against each specific asset, not a single generic "equipment list" reviewed once a year. Software that ties a calibration record to the exact gauge serial number used on a specific boring gives a firm a defensible answer when a client or a peer reviewer asks which instrument generated a given field measurement — and it catches an expired gauge before it goes out on a truck, rather than after a client questions a density result.

Client Deliverables, Turnaround Commitments, and Portal Access

Commercial and residential developers hiring geotechnical firms are frequently working against their own hard deadlines — a lender's due-diligence period, a permit submission window, a construction start date tied to a financing close. A firm's ability to quote and hit a realistic turnaround time depends on knowing, in real time, where every active boring program actually stands: which borings are drilled, which samples are at the lab, which test results are back, and what's left before the report can go to PE review. When that status lives across a shared drive, a lab technician's memory, and an engineer's inbox, quoting turnaround is a guess. A system that shows live project status — and increasingly, that exposes a simplified version of that status to the client through a portal — turns "we'll get back to you" into a specific, defensible answer, and it reduces the volume of status-check phone calls that otherwise eat into engineering time during a busy investigation season.

Implementation Considerations

Switching platforms mid-project-load is disruptive for any firm, but geotechnical work has a specific wrinkle: active projects often span weeks or months between field drilling, lab testing, and final report issuance, so a clean cutover date rarely exists. Plan for a transition where in-flight projects finish in the legacy system while new projects start in the new one, with a defined end date for the legacy system's use rather than an indefinite parallel run. Get clarity up front on data migration for standing client and project records, template rebuilding effort for firm-specific and DOT-specific report formats, and how field crews will be trained on tablet-based data capture if they're coming from paper — that last item is a change-management problem as much as a software problem, and firms that skip a real training period see adoption stall at the field level even when the office loves the new system.

Where a Connected Platform Pays Off

The firms that get the most value out of connecting field data to final report aren't necessarily the biggest ones — they're the ones running a high volume of small-to-midsize investigations where the office overhead per project (typing logs, chasing lab results, rebuilding tables) is a large percentage of the total time spent, because the engineering analysis itself might only take a few hours. Cutting the administrative tail on every project compounds across a full year of work in a way a single project's time savings won't show you.

Atlantis NDT's ERP platform is built around that same principle for accredited, standards-driven field inspection work generally — one job record carrying field data, technician and instrument assignment, document control, and billing together, configurable to a firm's specific report formats and client requirements rather than forcing a firm's workflow into a rigid template. For geotechnical and materials-testing operations weighing a platform change, it's worth comparing that connected model against whatever patchwork of tools is currently carrying your field-to-report workflow.

Atlantis NDT Products & Services

Atlantis NDT pairs field expertise with software: NDT inspection management software — Atlantis ERP, a digital twin platform for asset integrity, and NDT reporting software. Build your team with NDT training & certification (ASNT SNT-TC-1A) and ASNT certification pathways, or bring in ASNT Level III consulting. Affordable, accessible, fully customizable — book a free consultation.