Skip to main content
Systems & Procore

Process first. Configuration second. Adoption always.

Software does not fix a business. A documented, sensible way of working does, and then the right platform makes it fast. We do both halves, which is why the result tends to stick.

New Procore implementations, and existing setups that need improving

The premise

Most rollouts fail for the same reason

They start with the software.

A platform gets bought, configured to look like the demo, and launched with a two-hour training session. Six months later the documents are in it and nothing else is, because the way the business actually approves a variation was never written down, so there was nothing to configure against.

The order that works is the other one. Agree how projects should run. Write it down. Then build the system to match, train people on their own process rather than on a piece of software, and stay close through the first few reporting cycles while the old habits fight back.

It is slower to start and considerably faster to finish, because you only do it once.

Construction systems & growth

The operating system for a growing contractor

What we design and document, whether or not Procore is part of the picture.

  • Project setup & controls

    A standard way every project starts: budget structure, cost coding, package breakdown, programme integration and the commercial baseline everything is measured against.

  • Commercial procedures

    Documented process for procurement, subcontract award, variations, claims, forecasting and final account, written for the people who have to follow them.

  • Reporting framework

    One set of numbers, reported at project, portfolio and board level, on a cadence the business can sustain without a week of manual assembly.

  • Roles & delegations

    Who approves what, to what limit, at which stage. Clear enough that decisions stop escalating by default and stop being made by nobody.

  • Template library

    Subcontract documents, procurement schedules, cost reports, variation forms, notices and correspondence. Consistent, current and actually used.

  • Documentation & handover

    The whole thing written down so it survives staff turnover and a new PM can be brought up to speed in weeks.

What it produces

Reporting is where control either exists or does not

A monthly pack that takes a week to build is a week out of date before anyone reads it. Once the framework is in place, this view is a by-product of running projects properly rather than a separate exercise.

  • Forecast final cost and margin on every live project, on one page
  • Portfolio roll-up that reconciles to the individual project reports
  • Variation status and value, including what has not been notified yet
  • Exception reporting that surfaces a job moving before it shows in the numbers
  • Cashflow and work-in-progress across the portfolio
  • A board pack that comes out of the system rather than out of a spreadsheet
Procore implementation & optimisation

Two very different jobs, so two separate engagements

Almost every Procore conversation is one of these. Starting a rollout from nothing and repairing one that has been live for two years need different scopes, timelines and prices, so we quote them separately rather than blending them into one service.

New Procore implementations

You have just bought Procore, or you are about to, and you want it done once and done properly.

Typically 3 to 6 months Fixed scope

Existing setups that need improvement

You already pay for Procore, and it is holding documents rather than running your commercial process.

Typically 2 to 6 weeks Starts with a health check

Independent, and not a reseller

We do not sell licences and receive nothing from Procore. If a module is not worth it at your size, or the platform is not the right answer at all, that is what you will be told.

Track 01: New implementations

Configured around your business, not the demo

A greenfield rollout, done in the order that works. Deep, hands-on Procore configuration with the commercial understanding to know what the configuration is actually for.

  • Implementation planning

    Scoping, sequencing and a rollout plan that fits your project calendar rather than a generic timeline, including which projects go first and why.

  • Financial management

    Budgets, cost codes, commitments, change orders, prime contracts and forecasting configured so the commercial truth lives in Procore, not in a parallel spreadsheet.

  • Workflows & permissions

    Approval workflows that match your actual delegations, with permission templates by role so people see what they need and cannot break what they should not touch.

  • Project templates

    New projects created from a template with cost structure, directory, workflows and configuration already in place. Setup goes from days to minutes.

  • Reporting & dashboards

    Reports the business will actually open: project commercial position, portfolio roll-up and the exception reports that surface a problem early.

  • Training & adoption

    Role-based training for PMs, CAs, site and finance, plus the follow-up that turns a launch into a habit. Adoption is the part most rollouts skip.

Implementation approach

Four stages, no big bang

Staged, piloted and reversible. Nobody wakes up on a Monday to find the way they run projects changed overnight.

  1. Stage 1

    Discover

    How the business actually runs today: commercial process, approvals, reporting, finance integration and where the current pain is.

  2. Stage 2

    Design

    Process first, configuration second. Cost structure, workflows, permissions and templates designed against your procedures, then signed off.

  3. Stage 3

    Build & pilot

    Configure, load a pilot project, and run it live with a small group. Fix what the pilot exposes before the whole business sees it.

  4. Stage 4

    Roll out & embed

    Staged rollout by role and project, training delivered in context, then support through the first reporting cycles until it sticks.

Track 02: Existing setups

A rollout that never landed is a cheaper problem than it feels

You have already paid for the licences and taken the disruption. An optimisation goes after the value still sitting unused, and it is measured in weeks rather than months.

  • Configuration health check

    A structured audit of what is configured, what is used, and what is quietly working against you. Delivered as a findings list with an effort estimate against each item.

  • Cost structure remediation

    The most common single fault: cost codes set up per project, so nothing rolls up. We design one structure and migrate live projects onto it without re-baselining them.

  • Workflow rebuild

    Approval chains rebuilt to match how your business genuinely approves things, so people stop routing around the system to get work done.

  • Reporting repair

    Reports rebuilt inside Procore so the monthly pack comes out of the platform instead of being exported and reassembled in a spreadsheet.

  • Modules & licence review

    An honest read on what you are paying for. Modules either get configured and adopted properly, or you stop pretending they are part of your process.

  • Retraining & internal ownership

    Role-based retraining for the people who gave up on it, and a nominated internal owner set up with the knowledge to keep the platform current.

How an optimisation runs

Health check first, then only what pays for itself

We never reconfigure a live instance before agreeing what is actually worth changing. Most of the value tends to sit in two or three specific fixes.

  1. Week 1

    Health check

    Audit the current configuration against how the business actually works, and interview the people who stopped using it. Findings and a fix list with effort against each item.

  2. Week 1 to 2

    Prioritise

    Agree what gets fixed now, what gets fixed later and what gets abandoned. Usually two or three changes unlock most of the value already paid for.

  3. Week 2 to 5

    Reconfigure

    Cost structure, workflows, permissions, templates and reports corrected on the live instance, staged so nothing breaks mid-month.

  4. Week 4 to 6

    Re-launch & own

    Retrain by role, run one full reporting cycle the new way, and hand the platform to a named internal owner with documentation behind them.

Sound familiar?

Eight signs your Procore setup needs work

If more than a few of these are true, a focused health check will usually find the two or three changes that unlock most of the value you already paid for.

  • Procore holds documents but the commercial position lives in Excel
  • Half the team never logged in after the initial training
  • Cost codes were set up per project, so nothing rolls up
  • Change orders are raised in Procore and then re-keyed into accounts
  • Workflows were configured to match the demo, not your delegations
  • Nobody internally owns the platform, so nothing has changed since go-live
  • Reports get exported and rebuilt in a spreadsheet before anyone reads them
  • The renewal is coming up and you cannot articulate what you get for it
Questions

Systems & Procore

No. We do not sell licences and we take nothing from Procore, which means the advice about how much of the platform you actually need is genuinely independent. If a module is not worth it for your size of business, you will be told.

Usually, yes. That is the whole reason the two tracks are priced and scoped separately. An optimisation of an existing setup is a fraction of a full implementation, and often the problem is three or four specific things: cost structure, workflows, reporting, or that nobody owns it internally. Frequently the answer is a fortnight of configuration and some retraining rather than a project.

If Procore is not yet live, or is live on one project as a document store and nothing else, treat it as an implementation. If it has been live across the business for a year and the commercial position still lives in spreadsheets, that is an optimisation. The first call sorts it in about ten minutes, and the honest answer is sometimes that you need the process work before either.

No. Procore is a large part of what we do because it is what we know deeply, but the systems and commercial work stands on its own. If you are on another platform, or still on spreadsheets, the process design comes first and the tooling follows.

The process work is the point. Configuring Procore around a broken process gives you a faster broken process. In most engagements the procedure design and the configuration happen together, which is exactly why this is not an IT consultancy.

We scope it and design the commercial structure so integration is possible and sensible, with cost codes, commitments and change orders lining up on both sides. The technical build is done with your finance team and the relevant integration partner; we make sure the two systems agree on what a number means before anyone connects them.

Typically three to six months from discovery to a rolled-out platform, depending on how many projects are live, how many people need training, and how settled your commercial process is going in. Businesses with clear procedures move a lot faster than businesses designing them along the way.

They usually do, at first, and normally for good reasons. Most have been through a rollout that made their job harder. That is why the design starts with how they work now, the pilot runs with a small group who become advocates, and training is role-based rather than a generic two-hour session. Adoption is a change management problem, not a software problem.

Next step

Whether it is a rollout or a rescue, start with a conversation

Tell us what you have, what it was meant to do, and what it is actually doing. We will tell you honestly whether it needs a project or a fortnight.

Within one business day No obligation, no sales pitch