Why every job runs the same three steps

Open most operations platforms for the first time and what you get is a sidebar. Projects, jobs, forms, safety, logbooks, equipment, reports. Thirty doors and no clue which one you are meant to walk through first.

So people click about for an afternoon, find three screens they can live with, and ignore the rest. Six months later half the app has never been opened and the paperwork still lives in a shared drive.

We built Operations around a chain instead of a menu. Organisation, project, flight area, job, forms, clearance, records. Every survey job goes through that chain in the same order, whether it is a morning over a car park or three days over a quarry. Run one job properly and you have learned the software.

Here is the chain, in three steps.

One: set the job up

Work hangs off a project, and a project belongs to a client. Get that right first, because everything downstream attaches to the project rather than floating loose. The flight areas, the RAMS, the invoices.

Draw the flight area on the project’s Spatial tab. Sketch a polygon, buffer a line for a pipeline or a road, or upload the KML somebody has already sent you. Operations works out the take-off and landing zones and the operational volume from the parameters you set. If one launch position will not cover the site, split the area and give each half its own.

The flight area lives on the project, not the job. That is the detail worth pausing on. The second time a client asks you back to the same site, the boundary is already drawn, the TOAL zones are already there, and the new job borrows all of it. Sites get revisited far more often than they get surveyed once. Overlap analysis runs across the whole project, so you can see where two areas tread on each other before anyone drives anywhere.

Then drag the job onto the calendar and staff it. Pilot, aircraft, crew, vehicle. Do that before you touch a form, because the forms fill themselves in from it.

Two: clear it to fly

This is where an hour of admin usually goes, and where most of the design effort went.

Press Refresh data on the pre-flight survey and one request does the lot. UK airspace and live NOTAMs. Schools and built-up areas. Hospitals, care homes, railways, power lines and obstacles. The nearest emergency services. Terrain elevation and slope. The Met Office outlook, with an hourly flight window measured against your own aircraft’s wind limit. It all lands in the paperwork together, stamped with the moment it was captured. Nobody is copying a NOTAM number off a website into a Word template.

Then you work the Forms rail. Nine sections and two checklists on the pre-flight survey. RAMS issued against the job. On site, the CAP2606 Annex 2 survey, generated from the job and the pre-flight records so the aircraft serial and the crew details are not being retyped on a windy field, with its six separate GO or NO-GO decisions and a final remote pilot call. Then the SEEDS briefing, five prompts each across safety, exercise, equipment, discipline and signals, with attendance recorded.

The clearance is the last gate. Every upcoming job runs against the same 18 PDRA-01 checks, and each check comes back as met, advisory, confirm to proceed, or blocker. Worst wins. One blocker makes the whole job a blocker, however many checks came back clean.

What happens next is the part we care about. Confirm findings are not waved through with a single “continue anyway” tickbox. Each one is accepted on its own and recorded against your name by its rule code, so the record says what you actually saw. Blockers you either fix or override, and an override is per check. It needs a written justification, it needs a named person holding the right permission, and it expires two hours after it is recorded. A clearance taken the day before is not a clearance at take-off.

One judgement call runs through all of it: unknown is not the same as failed. A pilot whose currency has never been assessed raises a confirm, not a blocker. Only demonstrably insufficient recent flight time stops the flight. An operational authorisation that has lapsed blocks. One expiring inside its warning window asks the crew to see it and accept it. That distinction is why there are four severities instead of two.

Three: fly it, and keep the record

Upload the DJI log against the job, pull it from a linked DJI account, or type the flight in by hand for the sortie that left no file. Link the airframe, assign the pilot.

That one record then does four jobs at once. It becomes an entry in the pilot’s flight logbook. It adds its duration to the airframe’s technical log. It counts toward that pilot’s rolling currency, once the flight is approved and the aircraft sits in an equivalence group. And it becomes a row in the CAA audit pack the day somebody asks for one.

When a flight is not pulling its weight, the logbook says so out loud. The Counting column reads No aircraft linked, Needs group, Voided or a plain 3 fields missing. The specific reason, on the row, rather than a total that is mysteriously lower than you expected.

The order is the whole point

Read those three steps back and you will notice what is missing. Retyping. The Annex 2 is generated from the job and the pre-flight records. The audit pack is assembled from forms that were completed at the time. Currency is calculated from flights already logged. Nothing is entered twice for the benefit of the next document, which is exactly why the evidence still agrees with itself two years later when someone comes to check.

Same three steps for a sole trader and for a five-crew operation. The organisation around them gets bigger. The chain does not change.

If you want the detail, Getting started walks the same route with screenshots, and the readiness checks reference lists all 18 checks with the exact condition that makes each one block, confirm or advise.