Business Analyst
Business analyst is the least standardised title in this list. At one company it means gathering requirements for a software build; at another, process improvement on an operations floor; at a third, financial modelling; at a fourth, essentially data analysis with a different label. A résumé that does not resolve that ambiguity in the first three lines makes the reader guess, and readers guess against you.
Say which analyst you are before anything else
The summary line is doing more work on this résumé than on any other in this set. “Business analyst with 6 years of experience” resolves nothing. “Business analyst specialising in regulated insurance claims processes — requirements for core system replacement, and the process redesign around it” places you immediately.
This matters because the person screening usually has one specific gap. A hiring manager replacing a requirements analyst on a core banking migration is not looking for a process-improvement specialist, however good. Being clearly the wrong fit is a better outcome than being vaguely plausible, because vague plausibility is what fills a pile with candidates nobody advances.
If you genuinely span two of these, lead with the one the posting describes and let the other appear as range further down.
Requirements work needs an artefact and a consequence
“Gathered and documented business requirements” is the most common line on these résumés and is invisible to a reader, because it is what the title already implies. What distinguishes candidates is the shape of the work: how many stakeholders disagreed, how much was legacy with nobody left who understood it, and what happened when the build met the document.
“Wrote 40 user stories for the claims intake rebuild across three teams that had previously defined ‘claim’ differently, and led the workshop that settled it” is a real claim. It has a number, a genuine obstacle, and a resolution the reader can picture.
Requirements that changed are also material. An analyst who noticed a stated requirement was wrong before the build started saved more money than one who documented it faithfully, and that story is far more interesting than a count of documents produced.
Process work needs a before and an after
Where the job is process improvement, the résumé needs the state of the thing on both sides. “Mapped the returns process end to end and removed two approval steps, cutting median handling from 9 days to 4” is complete: it says what existed, what changed, and what it produced.
Naming a method without a result is the common failure. Six Sigma, value-stream mapping, and process re-engineering describe how you worked; on their own they leave the reader assuming nothing measurable came of it, which is usually not true.
Where the improvement was rejected or never implemented, say what you found and what the obstacle was. Analysts encounter this constantly, and how someone talks about a recommendation that went nowhere is genuinely informative.
Where these résumés usually get cut
The most frequent is reading as a weaker data analyst. Business analysts who lean on SQL and dashboards to seem technical end up compared against people who do that full time, and lose a comparison they never needed to enter. Technical fluency is a supporting detail here, not the headline.
The second is a tool list standing in for a method: Jira, Confluence, Visio, Excel. Everyone in the pile has used them. They belong in one line near the bottom and nowhere else.
The third is invisible domain knowledge. In regulated industries especially, knowing how claims, settlement, or clinical coding actually work is often the scarcest thing a candidate has, and it routinely goes unstated because it feels obvious from the inside. It is not obvious to the reader, and it is frequently the reason one candidate is advanced over another.
Terms that appear in almost every posting.
- Requirements gathering / elicitation
- The artefact, the number of stakeholders, and the disagreement you settled.
- Process mapping
- The before and after states. A method name alone implies nothing changed.
- Stakeholder management
- Which functions, and what made agreement hard. The phrase is on every résumé here.
- SQL / reporting
- Supporting evidence, not the headline — you will lose that comparison to full-time analysts.
- Domain knowledge
- The scarcest thing you have and the most often left out because it feels obvious from inside.
Add a term only when your own experience supports it. ApplySpan flags requirements you cannot evidence rather than writing them in for you.
Questions
Is a business analyst resume the same as a data analyst resume?+
No, and the overlap is what causes trouble. A data analyst is screened on the question, the analysis, and the decision it drove. A business analyst is screened on translating between people who want different things and leaving something behind that a team could build or run.
How do I show impact when I did not implement the change?+
Take credit for the part you owned and name it precisely: the recommendation, the specification, the workshop that settled a definition. Implementation you did not do is context. Analysts who describe that boundary clearly read as more senior, not less.
Should I include certifications like CBAP or Six Sigma?+
List them in one line if you hold them. They occasionally pass a filter and they never win an interview on their own — a specific process you changed, with the numbers on both sides, does considerably more.