How to write it
Say which kind of business analyst you are
The title spans four largely different jobs: the requirements analyst who specifies systems, the process analyst who redesigns operations, the data analyst who happens to be called a BA, and the systems analyst who configures a platform. Recruiters screen for one of them.
Resolve it in the summary with the domain attached: "business analyst in insurance operations, working between claims teams and engineering". A reader now knows what you do, who you do it with, and whether you fit — before reading a single bullet.
Process work is where your numbers are
Requirements documents are hard to quantify; process changes are not. Handling time, rework rate, handoffs removed, steps eliminated, hours of manual work recovered, error rates — these are the metrics of business analysis and they're usually sitting in the operational reporting you already read.
"Redesigned claims intake end to end, cutting average handling time 44% and rework 31% across a team of 80" is a complete argument for hiring you. It has scope, method implied, two metrics and a headcount.
- Handling or cycle time, before and after
- Manual hours removed per week or month
- Error, defect or rework rate reduction
- Processes mapped, retired or automated
- Money found or saved — leakage, duplicate spend, recovered revenue
Requirements count when you attach the outcome
"Gathered requirements and produced BRDs" describes the artefact, not the value. The value is that something got built correctly, on the strength of your specification.
So write it with the consequence: the programme's size, and the fact that it landed without severity-1 defects, or with adoption above a threshold. That reframes documentation from paperwork into risk management, which is what it actually is.
Name the systems, exactly
Business analyst postings are heavily systems-specific: SAP, Salesforce, Workday, Dynamics, ServiceNow, a policy administration platform, a core banking system. Recruiters search for the platform name, and generic process language won't match.
If you've worked on a named platform, say so plainly and say what you did to it — configured, migrated, integrated, specified. If your systems were bespoke, describe the function instead: "policy administration replacement" communicates the domain even when the product name means nothing outside the company.
Facilitation is the skill nobody proves
Every BA resume claims stakeholder management. The evidence version names the room: how many people, from which functions, and what was agreed that hadn't been before.
"Facilitated workshops with claims, underwriting and IT to agree a single data definition set, ending a two-year dispute" is a specific, checkable achievement. It also happens to describe the hardest part of the job, which most resumes reduce to a bullet point about communication skills.