Audiences
Four roles, four different working days
There is one system, but it looks different from the pilot seat, from the workshop and from the CAMO office. Below is what an ordinary day looks like in each role — and what stays outside the system in each of them.
Flying club · ATO/DTO
Many pilots, one tablet in the hangar
The biggest risk here is not a complicated maintenance programme, it is the number of hands. Dozens of pilots, a handful of aircraft, flying from dawn to dusk, and one place where all of it has to come together.
A working day
- Morning
The instructor opens a new entry next to the aircraft. They see current counter readings, open defects and how much is left to the next inspection. If something sits in tolerance, they learn it before the flight, not from a phone call from the mechanic.
- During the day
Every flight ends with its own entry — not a daily summary. The entry is signed by whoever flew it; nobody signs somebody else’s entry, because there is simply no way to do so.
- After the last flight
A reported defect shows up against the aircraft together with its limitation, so the next pilot does not discover it by accident. The day’s hours are already posted — nobody retypes them into a spreadsheet.
- In the evening
An e-mail alert summarises what is approaching its due date across the fleet. The head of training plans the next week knowing which aircraft will stop, and when.
What you get
- Accounts with three roles — pilot, mechanic, administrator — and no shared login, because a signature has to point at a person.
- An entry screen that works on a phone and in a hangar with no signal; the entry waits in a queue and sends itself.
- The whole fleet due list in one view, with a forecast of which aircraft stops first.
- A pilot logbook with utilisation statistics, CSV export and an A4 printout.
What you should know
Training a pilot takes about fifteen minutes next to the aircraft, but somebody in the organisation has to take the mechanic and administrator roles — that person does reversals, counter corrections and the opening balance.
Helicopter operator
Two counters, life-limited parts, bulletins every week
A helicopter usually has more than one time base and noticeably more hard-limited parts than a training aeroplane. Here you win on precision, not on convenience.
A working day
- Before the first flight
The pilot confirms the pre-flight check and enters both counter readings. The system requires the “before” reading to match the last posted state — a missed flight will not get through.
- Through the day
Landings and starts feed the cycle axis. Life-limited parts compute their own state: the state at installation plus the airframe increment since.
- After a component change
The mechanic records the removal and the installation. Moving an engine carries its installed accessories with it, and removal captures the counter state — with no transcribing onto a scrap of paper.
- Once a day
New manufacturer bulletins and airworthiness directives for the fleet types land in the catalogue. CAMO works through the queue and signs items off; the decision trail stays with the document.
What you get
- Block and tach counters as separate time bases, in whole minutes.
- Components with installation history and their own tasks, including life-limited parts with no tolerance.
- Daily ingest of manufacturer bulletins and airworthiness directives for the types you actually operate.
- Due-date forecasting from the more conservative of two utilisation windows — hangar planning instead of firefighting.
What you should know
A manufacturer that does not publish bulletins openly requires manual upload. The manual mode is visible in the source overview, so a coverage gap does not go unnoticed.
Aircraft owner
No CAMO staff, no spreadsheet of due dates
One aircraft, a few dozen hours a year, maintenance contracted out. The risk is not that something is unknown — it is that nobody looks at the calendar in the middle of the season.
A working day
- After a flight
The entry takes a minute: times, counters, landings, fuel, NIL or a defect, signature by password.
- Every now and then
An e-mail alert reminds you about an approaching inspection, ARC or insurance expiry — 60 and 30 days ahead.
- Before a workshop visit
The due-list printout shows what is outstanding and how much margin is left. The workshop gets specifics instead of “what needs doing, then?”.
- After maintenance
Compliance is recorded: date of work, counter state, release-to-service reference. Due points recompute themselves, and using a tolerance does not push the next inspection forward.
What you get
- A complete set of records in one place — including when somebody else does the maintenance.
- Alerts instead of remembering: inspection, ARC, CofA, insurance, life-limited parts.
- An opening balance from paper done once, with a dry run that stores nothing and a note on the source.
- A ZIP pack with the whole record set — useful when selling the aircraft as well.
What you should know
The opening balance has to be transcribed from paper: counters, maintenance programme tasks and last compliances. We do not migrate flight history — you enter the starting state, under a mechanic signature.
CAMO — in-house and contracted
The whole evidence chain in one place
For CAMO what matters is not the screen but what is left after a year of work: complete, consistent records that can actually be shown.
A working day
- Morning
A pass over the fleet due list with statuses and forecasts. “In tolerance” and “exceeded” are separate, because they are two different decisions.
- During the day
Recording compliance with a release reference, reviewing the bulletin queue, uploading aircraft documents. Each of those actions stays in the event register: who, when, what.
- On a programme revision
Tasks are matched across revisions by code, and items needing a decision go into a bridging report. The revision alone does not ground the aircraft.
- Before an audit
The authority pack for the chosen period: the techlog register (including reversed entries), the due list, compliance history, AD and SB status, components, defects, documents and a manifest with checksums.
What you get
- An event register bound by a hash chain — deleting or swapping a row is detectable.
- An integrity check run daily and mandatorily before every export for the authority.
- Append-only records: nothing is deleted, a document is withdrawn by archiving it.
- A retention report showing what is held in the system and since when.
What you should know
Version 1.0 supports one organisation per account. A CAMO managing several operators works with separate organisations today, and the workshop and the authority receive the audit pack rather than an account. Multi-party access is on the roadmap and we describe it as exactly that — a plan.
Getting started
What you need to begin
The list is short, but every item needs a person who knows the fleet. It cannot be clicked together in half an hour, and we do not pretend otherwise.
- 01
The maintenance programme as a task list: code, description, limits, tolerances and the whichever-first/later rule.
- 02
Current counter states with their source stated — for example the number and page of the paper logbook.
- 03
Last compliances with date, counter state and release-to-service reference.
- 04
A list of life-limited components with installation dates.
- 05
Accounts for pilots, a mechanic and an administrator, plus a decision on who runs the dual-run with paper.
FAQ
Frequently asked questions
We have three aircraft and ten pilots. Is that too small for a system like this?
No — billing follows aircraft, not users, so the number of pilots changes nothing. A small organisation gains even more: there is nobody on the payroll to watch a spreadsheet of due dates, and alerts and the due list work the same for three aircraft as for thirty.
Will the workshop that maintains our aircraft get access?
Not today. Version 1.0 supports one organisation, so the workshop receives the authority pack or a due-list printout — a complete set in open formats, readable without our application. Multi-party access is a plan and not a feature, and we describe it that way in the documentation for the authority too.
We fly under Part-ML but also have an aircraft under a different regime. What then?
Version 1.0 is designed for Part-ML with an in-house CAMO. An aircraft under a different regime can be kept in the system as a technical register, but we do not promise that every requirement of that regime is satisfied — this is one of the points to be talked through before a rollout, not discovered after it.
Next
The nearest topics — on the site and in the knowledge base.
On the site
- Pricing
Per aircraft, not per user: the pricing structure and how a rollout runs.
- Electronic techlog
One entry per flight, an electronic signature, immutability and work with no signal.
- Maintenance tracking
Hour, calendar and cycle limits, tolerances without drift, due-date forecasting.
In the knowledge base
- From paper to electronic records without losing history
The opening balance, the dual-run and the list of things to agree with your authority. What actually has to be transcribed, what must never be imported, and how long it takes.
- The electronic techlog and Part-ML: what a record system must do
What ML.A.305 and AMC1 ML.A.305 expect from a computerised technical logbook, and what you actually have to show an inspector to leave paper behind.
- The ARC and the airworthiness review: an operator's calendar
How an airworthiness review differs from maintenance, what the records review covers, how the operator's year is laid out and what most often derails an ARC date.
See CamoBook on your own fleet
Thirty minutes, live: a signed techlog entry, the due list for your aircraft type and the audit pack. No sales deck — we talk about your maintenance programme.
or write to [email protected]