A rig got stuck behind a rise nobody had planned for. That's usually how this problem gets found, not in a spreadsheet, but on site, when the straight line between two holes turns out not to be drivable at all.
Planning where a hole goes and planning how to reach it are two different problems When you're planning a program in 3D software, most of the thinking goes into whether a hole's actually going to intersect what you've modelled. If there's a lode sitting under a particular spot, you want to go straight through it. You can drape that planned hole onto the topography and see exactly what elevation it sits at. What you can't see from a desk is what's actually between that hole and the next one.
That gap matters more than it looks like it should. A 3D plan has no way of knowing there's a cliff face or a stand of trees sitting between two collars. Nobody finds that out until a rig's physically trying to get through, and by then it's too late to have planned around it.
So the order the holes get drilled in ends up being whatever's simplest on paper. Start at hole one, finish at the last one in the grid, snaking across the program in whatever sequence they were planned in. Not because that's the best path, just because it's the path nobody had to think about.
Why this gap's stayed open for so long Ask most people why nobody's properly solved this and the honest answer is that it's always just worked well enough to get by. A driller reads the ground and adjusts on the fly. A geo makes a call about which hole to prioritise that day. The program gets through, one way or another. Nothing about it looks obviously broken, so there's never been much reason to look closer.
That's also why the fix has been sitting in a strange gap between two disciplines. Planning software has never really thought about rigs, because traditionally you only start thinking about a rig once it's already on site and something's already happening. And once you're on site, the reasonable move is to solve today's problem, not to have already planned the best route through the whole program.
The real cost isn't fuel If you're picturing the saving here as a diesel bill, it's worth reframing. Fuel's a rounding error against a multi-million dollar drilling budget. The real cost is opportunity. Every hour a rig spends tramming between holes is an hour it's not drilling, and every exploration manager wants the same thing: as much of the budget going into the ground as possible.
That adds up faster than it seems like it should. Shave travel time down across a whole program and you get better adherence to schedule and more confidence you'll land on budget. Come in under, and that's more budget left over for another hole or another sample. There's a second, quieter benefit too. Less time spent tramming means less fuel burnt moving a rig around for no reason, and that's starting to matter to programs being judged on their footprint as well as their spend.
Where it applies, and where it doesn't This isn't a universal fix for every style of drilling. Talk to anyone doing drill and blast and the problem barely exists, since hole spacing there is usually tight enough, fifteen by fifteen metres or twenty-five by twenty-five, that there's no meaningful route to optimise between one collar and the next. The opportunity really shows up in wider-spaced exploration programs, where the distance and terrain between holes is genuinely variable.
Interestingly, the same logic doesn't stop at drilling. A conversation with a customer running earthworks raised the same underlying problem in a different setting, moving heavy equipment efficiently across a site that isn't flat or predictable. The mechanics are the same even when the equipment and the job aren't.
Getting the sequence right Working this out properly means bringing together a few things that normally never sit in the same place. You need the terrain itself, since an incline a rig can climb easily on one program might stop it dead on another, depending on the machine. You need the rig's own constraints, how steep a slope it can safely cross, what that costs to run per hour, and how that cost stacks up against time spent idle rather than drilling. Put those together and you get an actual path between holes, not just a straight line drawn on a plan.
Once you've got that, the order stops running straight through in sequence. It might jump from hole one to hole thirty before doubling back, not because anyone's being clever about it, just because that's the path that keeps the rig drilling instead of driving.
None of this needs to be complicated to be worth doing. Even a rough pass at sequencing holes by access and terrain, rather than the order they happened to be planned in, tends to shave real time off a program. Whether that's solved with a proper tool, a smarter process, or just someone walking the ground before the rig turns up, the value's the same. More of the budget ends up drilled into the ground, and less of it spent driving between holes.
There's a reason this has landed with us specifically rather than a modelling package or a mapping tool. All the work of planning holes and interpreting geology happens before a program goes live, and all the work of turning results into a model happens after it wraps up. What sits in between, actually running the program day to day, has never really had a home. That's the space we've been building into, sitting between planning and execution rather than on either side of it.
We've built something at CorePlan that does exactly this, working out a rig's constraints and the terrain itself to hand back a sequence that keeps it drilling rather than driving. It's live now and open to anyone who wants to try it, and one customer already trialling it summed it up better than I could: it's the kind of thing you don't realise you're missing until someone shows you what it looks like once it's fixed.
If you've ever watched a rig sit idle longer than it should between two holes, you already know the problem I'm describing. I'd be curious to hear how your team handles sequencing right now, and whether it's ever cost you more than you realised at the time.
.png)
.svg){kind=small}
