Define
What your organization does, who it does it for, and what it has committed to. This is where onboarding starts — and JBird starts empty on purpose, because no two organizations map the same way. Empty, but not unhelpful: a template pack gives you the documents every quality system needs, scoped to your standards, before you write a word.
Step 0 · the first click
Template Packs
Starting empty is honest, but it shouldn't mean starting from nothing. Tick the standards you're certified to, press the button, and JBird sets that as your scope and writes five starter documents — QMS Scope Statement, Internal Audit Procedure, Management Review Procedure, NCR/CAPA Procedure and Document Control Procedure — each already scoped to just the standards you picked, not a generic pack with the irrelevant clauses left in.
Running it again is safe. It fills in whatever is still missing and will not touch, regenerate or duplicate a document you have already written or edited. That matters more than it sounds: the reason people don't press buttons like this in other systems is that they can't tell what it will overwrite.
Click to enlarge.
Step 0 · the other first click
Data Transfer
The honest objection to any new QMS is not whether it can hold your records. It's the fortnight of retyping between deciding to switch and having anything useful in it. So there's a wizard per entity — people and training, suppliers, equipment and calibration, documents, NCR/CAPA history, customers — that takes a CSV out of whatever you keep now: paste it or upload it, map your columns to JBird's fields, and look at exactly what will happen before anything is written.
Three things about it are deliberate. It never guesses at your data: column suggestions come from exact header names, never from reading the values, because a mapping that is silently wrong is worse than one you had to make yourself. Re-running the same file is safe — duplicates are detected and skipped, with a toggle if you meant it. And a document imported with a historical approver and date gets a real, dated approval record, the same shape as if somebody had clicked Approve at the time, rather than an "Approved" badge with nothing behind it. Historical nonconformances get real NCR numbers in the same sequence as the ones you'll raise next week.
The quick "Import a List" button on Customers and Suppliers is still there and still faster when all you have is a column of names. This is for the rest of it.
And it runs in both directions. Every register has an Export to Excel button that writes a real .xlsx workbook — the full list for that register, not just whatever filter you happen to have on screen, because a partial export is the kind of thing that goes unnoticed until an auditor asks why a record is missing. The spreadsheet library is built into the page rather than fetched from anywhere, so export works on a locked-down shop network, and on a machine with no network at all. You can try it right now in the demo.
There is also one button for everything. A full export downloads a single ZIP: every record as JSON, one CSV for each kind of record, and every file attached to a record exactly as it was uploaded, with a manifest that lists each file, the record it belongs to and its SHA-256, and marks any file it could not fetch as not included rather than leaving it out silently. When people sign in to a hosted deployment, the exports on that screen are for the organization’s Admin.
This matters more than a convenience feature. You are being asked to keep records in here that you will be audited against for years, and the reasonable question is what happens if you want to leave. The answer is that everything comes out as files you can open in Excel, without asking us.
Nothing is written until you press the button, and the button tells you how many records it will write. Click to enlarge.
Step 1 · before you draw anything
IOP Archetype Library
A blank process map is the hardest screen in any quality system, and the usual failure isn't blankness — it's copying someone else's twelve processes because they came in a template. Pick the shape closest to yours and JBird seeds a complete starter map: processes, sub-steps, interactions with what flows between them, owners, KPIs, resources and training requirements. Then you edit it into your own.
What makes it worth having is what the panel says before you pick. A process is only its own process if someone is primarily executing it; otherwise it's an activity inside a broader one. Two of the archetypes apply that rule to the same question — purchasing — and land on opposite answers: a machining shop with no purchasing manager folds it into Operations, while a distributor whose whole business is buying gives it its own owner and its own KPIs. The third applies it to a different question. A design-and-build shop employs engineers, so Design & Development is a process of its own rather than something folded into contract review. Each card says which way it went and why.
So when you then split or merge something, you're making an informed choice against a named rule rather than guessing — which is the difference between a template library and one that teaches you something. Applying is safe on a map that already has processes: it adds only what isn't there, and never touches anything you've renamed or edited.
Click to enlarge.
Step 1 · where the app opens
Interaction of Processes
A builder, not a fixed diagram. Add your processes, group them into categories you control, and define what flows between them. The diagram draws itself from that data — the core flow lays out as a single left-to-right spine, category zones enclose what belongs to them, and support processes sit in their own zone below — drawn as full processes, but deliberately not wired to individual core processes, exactly as a real AS91xx process map does it. Each box carries its own activities as a short list, so the map shows what every process does without a word of text floating on the arrows.
Each process carries what an auditor expects to be shown — Inputs, Activities and Outputs, all required — plus its owner and team, its applicable standards and clauses, its equipment and operating environment, its audit interval, and the training its team needs. Its KPIs carry a monitoring plan rather than just a number: how each one is measured, how often, and when it was last analysed, which is what clause 9.1.1 actually asks for. Everything downstream reads from here.
Click to enlarge.
Step 1, one level down
Turtle Diagram & SIPOC
Every process gets a printable turtle diagram and SIPOC, built from the record you already filled in — there is no second form to complete. Every leg: Inputs, Outputs, With What (equipment and operating environment), With Whom (owner, designee, team and their training), How (the sub-steps, plus the procedures and work instructions tagged to that process at their current revision), How Measured (the KPI table and the audit interval), and the process itself in the centre.
Beneath the turtle, the process's interfaces — each one showing its direction, the process at the other end, and what flows between them. Support processes are included here even though they are deliberately not drawn on the interaction map, because an auditor assessing Support still needs them.
The SIPOC underneath resolves suppliers and customers the honest way: anyone you have actually linked — a shelf-life supplier, a calibration provider, a contract-review customer — appears by name, and where no real link exists yet it falls back to the upstream or downstream process from your interaction map and labels it Internal. An empty leg says so rather than rendering blank, so a thin process definition reads as a gap you can go and close.
The four things an auditor has to record on a PEAR are inputs, outputs, activities and interfaces — so those are exactly the four this page leads with, in a form you can read straight across into the PEAR. JBird pre-fills them there for you as well, from the same source, so the two never disagree.
It is a standing view, not an audit snapshot — open it any time, print it, hand it to an auditor who asks how a process actually runs. Distinct from the PEAR, which is frozen to the audit it belongs to. On screen it follows whichever theme you work in; printed or saved to PDF it always comes out on white, so the copy in the auditor's hand doesn't depend on who exported it.
Click to enlarge.
Data Transfer
A three-step wizard per entity — paste or upload a CSV, map your columns, then a dry-run preview that says what each row will do before a single record is written. Covers people and training, suppliers, equipment and calibration, documents, NCR/CAPA history and customers.
Organizational Context
Issues log, interested parties with stakeholder mapping and RACI, and the QMS scope with the 9101 not-applicable justification cross-check.
Requirements Register
Every customer, statutory, regulatory and internal requirement you've taken on, with where it came from and what satisfies it.
Quality Objectives
Objectives with a cascade view down to the process KPIs that actually measure them, referenced to the real SCMH 7.11.2 source.
Risks & Opportunities
Assessment and treatment, with actions that land in the master Action Tracker rather than dying in the register.
Operational Risk Management
The aerospace addition to clause 8 — risk carried through the work itself, not just a register kept alongside it.
Product Safety
Safety-critical items and a safety event log, feeding the safety performance input management review already asks for.
Special Processes & FAI
Standing approval records for special processes, first article inspections that print as AS9102 Forms 1, 2 and 3, and new capability evaluation.
Design & Development
Design projects with the 8.3.2 planning checklist, inputs, reviews and verification, outputs with critical-item flagging, and a change log.
Change Management
Planned changes to the QMS with their risk assessment, so clause 6.3 isn't a paragraph in the manual with nothing behind it.
Customers & Suppliers
Both registries, with an 8.4.1.1 external provider control record on every supplier — approval status and who decided it, scope of approval, periodic performance review, certificate on file — a scorecard per supplier worked out from the receipts you post against its purchase orders (on-time delivery, conformity and, if you choose, PPM rejected) with every target and rule left blank until you set it, and bulk import when you're bringing an existing list across. Counterfeit prevention (8.1.4) sits here in its proactive form: an authorized/original-source flag and obsolescence monitoring per provider, alongside the reactive suspect-part controls in NCR/CAPA.
Contract & Order Review
A review record per customer order, checklisted against the standard's own requirements, with any negotiated differences noted and the decision retained. Changes to an accepted order get their own log with an acknowledgment step, so "the customer changed the spec" leaves a trail.
Quotation
The step before an order exists. A quote per customer with revision-bearing line items — part number, revision, quantity, unit price, requested due date — and an extended price and running total computed live. Status runs requested → quoted → revised → won, lost or expired, with the reason kept when it is lost, and a re-quote log so a third revision does not erase the first two. A unit price entered as free text ("TBD") declines to compute rather than quietly inventing 0.00.
Customer Orders
The order itself, optionally carried over from the quote that won it, with the customer's PO number, received date, acknowledgment fields and how the order arrived — portal, email, EDI — with attachments. A Contract & Order Review links to the order it reviewed rather than to a typed reference, so the review, the order and the quote behind it are one chain instead of three documents that mention each other.
Bills of Material
Components per part number — quantity per, unit of measure, reference designator — linked into the Inventory part master by part number rather than retyped, so a component's on-hand quantity is one click away from the BOM that calls for it.
Routers
The operation sequence a part follows through the shop — one of the "route cards, parts lists, travelers, control plans" clause 8.5.1 names as documented information a production organization is expected to hold. Each operation can name the special process approval, required asset and required training role that already govern it elsewhere in the system.
Work Orders
The production order itself, worked from a queue or a status board, with on-hold and cancelled work kept out of the flow rather than cluttering it. A Traveler for the execution record is created from the Work Order it belongs to.
Travelers
The execution record a Work Order's router actually runs against — each operation a snapshot of the router at the moment the Traveler was created, so a later router edit never rewrites history. Once the organization has named a Quality Gate Administrator, calibration, special-process and training gaps block sign-off rather than merely warn; a blocked step can be authorized with a written reason, and the override covers only the finding it saw.
Inventory
A part master and its ledger — every receipt, issue, adjustment, WIP move and scrap is a ledger entry carrying lot/batch and serial numbers, the same field names an NCR record already uses. On-hand is never entered; it is always the sum of the ledger, and material received but not yet verified is flagged separately rather than blending in with stock already checked.
Customer Communication
A dated log per customer across all five things clause 8.2.1 names — information provided, inquiries and orders including changes, feedback and complaints, customer property handling, and contingency requirements. The 8.2.2 intake fields sit on the inquiry entries, so statutory and regulatory requirements, special requirements and any operational risk spotted at intake are captured where the order is taken rather than reconstructed afterwards.
Process Change Control
A change to how a process runs — a work instruction, a special-process parameter, tooling, an authorized person — tied to the process it affects, with the reason, the verification done before it went in, who reviewed and approved it, and confirmation it was actually incorporated. Distinct from Change Management above, which is clause 6.3: a change to the QMS itself. Auditors ask why both exist, and the two records answer differently.
