Most business analyst resumes fail the same way: they describe activities instead of decisions. "Gathered requirements," "created documentation," "worked with stakeholders." Every BA on earth can claim those lines, so they filter nothing and prove nothing. The resumes that get callbacks show what changed because you were in the room: the process that got faster, the report that replaced a guess, the project that shipped because the requirements were actually right.

This guide walks through a complete business analyst resume example, then breaks down what BA job descriptions actually ask for, where the hard skills like SQL and Tableau sit against the soft skills like stakeholder management, and how to write bullets that survive both the applicant tracking system (ATS) and the recruiter's first skim.

A BA resume has one job: prove you can translate a business problem into something a team can build or fix, and that the translation produced results. Every section should serve that argument.

Here is the structure that works for most business analysts, top to bottom:

Length: one page if you have under roughly seven years of experience, two pages if you are senior with multiple substantial projects. Never pad to fill a second page. If you are unsure which side of the line you fall on, the breakdown in should a resume be one page or two settles it by experience level.

One formatting rule matters more than the rest: keep it a clean single-column or simple two-column layout with real text, no tables for the experience section, no graphics carrying information. BA applications almost always pass through an ATS before a human sees them, and a resume the parser mangles never gets its seven-second chance.

The example below is a mid-level business analyst, roughly five years in. Read it for the pattern, not the specifics: every bullet names a project or a process, states what the analyst did to it, and ends with what changed. The tools appear inside the bullets doing work, not just stacked in the skills list. That is the difference between a resume that claims SQL and a resume that proves it.

Three things to lift from this example. First, the summary makes a claim a hiring manager can interrogate: a specific kind of project, a specific kind of result. Second, no bullet starts with "Responsible for." Responsibility is what the job description gave you; the bullet's job is what you did with it. Third, the skills section is grouped, so the recruiter finds SQL in one second instead of hunting through an alphabet soup of twenty ungrouped terms.

A senior business analyst resume is not a mid-level resume with more bullets. The unit of proof changes. Mid-level BAs prove they can run a workstream; senior BAs prove they can own the problem, influence the roadmap, and make other people's work better.

Concretely, that means four shifts:

The structure stays the same as the example above. Two pages is normal at this level, and the second page should be older roles compressed to two or three bullets each, not the recent work stretched thin. On history depth, how far back a resume should go covers the cutoffs.

Business analyst postings split their demands into two buckets, and most candidates get the balance wrong. Read a stack of BA job descriptions and a clear pattern emerges: the hard skills are the filter, and the soft skills are the tiebreaker. Requirements language and tool names get you through the ATS and the first skim; the stakeholder and communication skills decide the interview.

Here is how the demand breaks down across the tools and skills that appear again and again in BA postings, and what each one means for your resume:

The practical takeaway: your skills section should lead with the hard skills, because that is what the filter reads, but your bullets should carry the soft skills as evidence rather than adjectives. "Strong communicator" in a skills list is noise. "Ran weekly requirement reviews with engineering, design, and compliance, resolving conflicts before they reached the sprint" is stakeholder management a hiring manager can believe. For the deeper logic on this split, see hard skills vs. soft skills on your resume.

Recruiters filter BA applications on specific terms, and the ATS matches those terms literally. If the posting says "user acceptance testing" and your resume says "final-stage validation," you lose a match you earned. Use the standard vocabulary of the field, then let your bullets prove you mean it.

The keywords that show up repeatedly across business analyst postings:

Two cautions. First, match the posting in front of you, not a generic list: a BA role at a bank leans on regulatory and process language, while a product-team BA role leans on user stories and Agile delivery. Second, keyword stuffing is dead as a tactic. Modern screening surfaces the terms in context, and a recruiter who opens a resume with a keyword wall closes it just as fast. The right move is one honest use of each term inside a bullet that demonstrates it, which is exactly the approach covered in ATS resume keywords: stop guessing and start matching.

These three tools deserve their own section because they are where BA resumes most often overclaim or underclaim. The rule for all three: the skills list states it, a bullet proves it.

SQL is the technical skill BA hiring managers probe hardest in interviews, so an unsupported "SQL" in your skills list is a liability. Anchor it to a task: "Wrote SQL queries against the orders database to reconcile a reporting discrepancy, identifying a data-entry defect affecting 3% of monthly invoices." You do not need to be a database engineer. You need to show you can pull and check your own data instead of filing a ticket and waiting.

A dashboard bullet needs three parts: the audience, the question it answered, and what happened next. "Built Tableau dashboards" says you attended a training. "Built a Tableau dashboard tracking fulfillment SLAs for the operations director, replacing a weekly manual report and surfacing a carrier delay pattern that led to a vendor renegotiation" says you turned data into a decision. If you know one and the posting names the other, list what you know honestly; the concepts transfer and interviewers know it.

Everyone claims Excel, so the claim itself is worthless. What works is specificity about the artifact: a forecasting model, a reconciliation workbook, a pivot-based analysis that fed a business case. "Advanced Excel" without an artifact reads as "I can make a chart." One concrete Excel bullet in your most relevant role is worth more than the phrase in every skills list you will ever write.

The summary is the first thing read and the last thing most candidates write well. The failure mode is the adjective stack: "Detail-oriented business analyst with excellent communication skills and a passion for data-driven solutions." Nothing in that sentence is checkable, so nothing in it is persuasive.

A working BA summary has three parts in three lines or fewer: who you are in market terms, the kind of problem you solve, and one result that proves it. For example: "Business analyst with 5 years in e-commerce operations. I turn messy fulfillment and payments processes into documented requirements teams can build against; most recently led the requirements for a returns-portal rebuild that cut processing time 40%." A hiring manager reading that knows your domain, your specialty, and your ceiling in ten seconds.

Skip the objective statement unless you are entry-level or changing careers; at every other stage, the summary does the same job with evidence instead of aspiration. For structure and more worked examples, see how to write a professional summary for a resume.

BA work is project work, and the resume should read that way. Inside each role, organize bullets around projects rather than duties. A duty-based bullet ("Facilitated meetings and documented requirements") could describe any week of any BA's career. A project-based bullet has a beginning, a middle, and an outcome.

The format that works: project context, your specific contribution, measurable result. "Led requirements for a CRM migration serving 200+ sales users: ran discovery workshops across 4 departments, wrote 60+ user stories, and coordinated UAT; the migration launched on schedule with zero critical defects in the first month." That single bullet demonstrates elicitation, documentation, stakeholder work, and testing, each keyword earning its place.

Two structural choices worth making deliberately. If a single project dominated a role, give it a bolded lead-in line within the experience entry so it reads as a unit. And if you have significant projects outside employment, coursework capstones, contract work, or a certification project, a separate Projects section below experience is legitimate; entry-level BAs especially should use one rather than stretching thin work history. Keep bullets to 3-5 per role, weighted toward the most recent, per the guidance in how many bullet points per job.

Vague bullets are the hardest problem to see in your own resume, because you know what you meant. "Supported the data migration project" feels complete to you; to a stranger it is a fog. This is where a second pair of eyes earns its keep, and it is the specific job Remi, the career copilot inside Roleframe, was built for.

The workflow: paste the BA job posting, and Roleframe produces a fit report scoring your resume against it, including the exact keywords the posting asks for that your resume is missing. Then Remi works with you on the gaps, bullet by bullet. Ask it to tighten "supported the data migration project" and it proposes a rewrite grounded in the posting and in what your resume already says, shown as a word-by-word diff. You accept it, edit it, or discard it. Nothing changes without your approval, which matters more than it sounds: a BA who cannot defend a resume line in a requirements-style interview grilling has a worse problem than a vague bullet. The words stay yours; Remi just makes you say what you actually did.

Section order is a real decision, not a template default, and for business analysts the answer splits cleanly by career stage.

Certifications get their own placement logic: if the posting names one (CBAP appears in senior postings, ECBA in junior ones), it belongs near the top where the filterer finds it, not buried under a decade-old degree. The full reasoning is in the best resume section order for your experience level. In Roleframe's editor, reordering is a drag: grab a section's handle and drop it where the argument says it belongs, and it keeps its content and formatting on the way.

The fastest path from this page to a finished resume: start from the structure in the example above, write your bullets project-first, and check them against the actual posting before you send anything. Export and submit as PDF, always. It is the one format that renders identically everywhere and parses cleanly in modern ATS software; only send anything else if an employer explicitly demands it.

If you are applying to several BA roles at once, resist the one-resume-fits-all urge. A banking BA posting and a SaaS product BA posting reward different keywords and different lead bullets, and the gap between a generic and a matched resume is usually the difference between silence and a callback. Keep one master BA resume and spin off a matched version per application; the base-resume-and-variants system makes that sustainable instead of exhausting.