A stakeholder asks you to add an approval to a catalog item. You know how to build it, but you want to understand who should approve, what they are checking, and what happens when they are unavailable. Before even touching the configuration, you have a few questions.
If this sounds familiar, you may already be delivering aspects of business analysis. Moving into a ServiceNow BA role means taking greater responsibility for those conversations and following the requirements through to delivery. Here is what I would focus on if you are considering that move.
Understand What You Are Taking On
A ServiceNow BA helps people explain what they need, works through conflicting expectations, and documents requirements the delivery team can use. Depending on the project, this can include facilitating workshops, mapping processes, writing user stories, supporting backlog refinement, and coordinating user acceptance testing (UAT).
You also follow up on the things people would rather leave vague by asking the following questions:
- Who owns this process?
- Who can approve this request?
- What does “urgent” mean?
- Who will confirm that the requirement has been met?
You do not make every decision yourself. Process owners agree on how their teams should work. Product owners help determine priorities. Architects and technical consultants assess solution design and constraints. Your responsibility is to make the requirement clear enough for those decisions to happen and to keep track of what was agreed.
Before applying, read the responsibilities carefully. A BA position in one organisation may include process consulting, while another focuses heavily on requirements and testing. Ask what you will own and who you will work with.
Recognize the Experience You Already Have
Platform knowledge is very useful in ServiceNow. If you have configured catalog items, maintained flows, or investigated incidents, you have seen how requirements affect users and support teams after deployment.
You may also have examples of questioning a request, explaining a limitation, or identifying why a recurring issue keeps happening. Those experiences belong in your application, provided you can explain your contribution.
Think beyond the configuration you delivered, and ask:
- What did you need to clarify?
- Who did you involve?
- Did the discussion change the requirement?
- How did you check that the result addressed the need?
Be honest about the gaps too – joining stakeholder calls is different from planning and leading a workshop. Writing configuration notes is different from defining acceptance criteria. You have a useful starting point, but there will still be work to learn.
Learn to Lead the Conversation
One challenge I have encountered in ServiceNow workshops is working with clients who do not have a documented process. Asking them to describe their requirements is not always enough. They may need help understanding the available options before they can make a decision.
In that situation, demonstrating the out-of-the-box process gives people something concrete to discuss. You can walk through it, ask where responsibilities sit, and identify which decisions still need an owner.
Consider a request workshop where someone says, “Every request needs manager approval.” Before documenting that as a rule, ask what the approval is intended to protect against. Is it cost, access, policy, or simply the way things have always been done? Would the same rule apply to a keyboard and privileged system access?
This example does not have one correct answer. The point is to understand the reason and make sure the agreed rule fits the requests it will cover.
You also need to know when to defer a question. If someone asks whether an integration or access model is supported, capture the need and confirm it with the appropriate technical lead. Do not promise a solution because you feel you should have an immediate answer.
Practice Writing Requirements People Can Test
A user story can look tidy and still leave the team guessing. “As a user, I want approval notifications so that I stay informed” does not explain enough to build or test the behavior.
For a practice exercise, take a simple equipment request and work through the details.
- Who receives the notification?
- What triggers it?
- What information should it contain?
- What happens if the request is rejected or the approver is unavailable?
Write acceptance criteria that make the agreed behavior observable. Keep unanswered questions separate, with someone responsible for resolving them. Otherwise, an assumption can quietly become a requirement.
Then connect the requirement to a test scenario. Could a tester demonstrate that it works without asking you to explain what you meant? Reviewing your work with a developer or tester is a good way to find the gaps.
Process mapping helps here too. Start with the trigger, the people involved, the main activities, the decisions, and the end result. You do not need an elaborate diagram to expose a missing handoff.
Choose Training That Addresses Your Gaps
If you already understand the platform, avoid restarting your learning simply because you are changing roles. Focus on the skills you have not yet had to use regularly.
ServiceNow University’s AI Business Process Analyst career journey is a useful place to review the available learning. Its business process analyst guidance also covers areas such as stakeholder engagement and implementation methods. Use that material to identify what you need to practice, rather than treating course completion as proof that you can lead a project.
If you do not hold the Certified System Administrator credential, review its learning path and relevance to the roles you are targeting. If you already have it, consider whether facilitation, requirements analysis, or process modeling would be more helpful than another platform exam.
A specialist certification can support a chosen area of work. For asset management, for example, ServiceNow offers separate Hardware Asset Management (CIS-HAM) and Software Asset Management (CIS-SAM) certifications. Choose based on the work you want to do and the experience you can gain. You do not need to collect several before seeking BA responsibilities.
Business analysis training and service management can also help. Check the course content, prerequisites, and costs before paying. Be clear about what you expect to learn and where you will use it.
Get Experience Before Waiting for the Title
An internal move can begin with a small, agreed responsibility on your current project. Ask to shadow a requirements workshop, prepare questions for one topic, or draft the stories for a change you understand well.
Agree the scope with your manager or project lead. Taking on BA work should come with time and feedback, rather than becoming an indefinite extra job alongside your existing workload.
A practical progression is to observe a workshop, own one requirement with support, then follow it through clarification, development, and testing. Ask the ServiceNow BA or process consultant to review your work. Pay attention to what they challenge and why.
If you cannot get project exposure, create a clearly labelled practice case using fictional information. A small equipment-request example could include a problem statement, a process map, a few user stories, acceptance criteria, and UAT scenarios. Include your assumptions and outstanding questions.
Keep it small enough to explain properly. A portfolio is more useful when you can discuss your decisions than when it contains dozens of templates. Never use client documents, screenshots, or data without permission.
Make Your Application Reflect the Work
Your resumé should show relevant responsibilities without changing your previous job titles or overstating what you owned.
If you clarified an approval requirement and supported testing, say so. If you only implemented a specification someone else wrote, do not present that as leading requirements discovery. You can still explain what you learned from the implementation.
Prepare examples for interviews: a vague request you helped clarify, a disagreement you worked through, or a requirement that changed after review. Explain the situation, your actions, and the outcome you can substantiate. If you do not have measured results, do not invent numbers.
Ask the employer questions too. Will you lead workshops? Who approves requirements? Is there an architect available for design decisions? What support will you receive while learning the role? These answers will tell you more than the job title alone.
Give Yourself Time to Adjust
The first few months may feel uncomfortable, particularly if you enjoy the immediate feedback that comes with technical work. ServiceNow BA work has no compile button – a document can read well and still contain a misunderstanding that only becomes obvious during a walkthrough or test.
Get feedback early. Review your interpretation with stakeholders, check feasibility with the technical team, and involve testers before the requirements are considered finished.
You may also find yourself designing the solution while someone is still explaining the problem. Your platform experience is valuable, but give yourself time to hear the full requirement before proposing an answer.
There is no fixed month when the transition becomes easy. Look for practical signs of progress: clearer workshop decisions, fewer unanswered questions passed into development, and requirements you can explain confidently.
Use AI With Care
AI can help prepare questions, organize notes, or suggest a first draft of acceptance criteria. It can also fill gaps with plausible details that nobody agreed to.
Check generated content against the source material. A suggestion belongs in the discussion until the appropriate stakeholder has confirmed it. Keep proposed requirements separate from decisions already made.
Use tools approved by your organization and follow its rules for client information. Do not upload workshop recordings or confidential documents simply because a tool can summarize them.
Learning to use AI is useful, but it does not remove your responsibility for the requirements you submit. You still need to understand them, explain them, and know which agreements are outstanding.
Ultimately, the AI story is not a threat for the ServiceNow BA. It is a nudge up the value chain. Learn to use AI to clear the routine work off your desk, then spend the time you get back on the stakeholder conversations and the process thinking that no model can do for you. That is the version of this role that gets more valuable, not less.
To learn more about this topic, check out the community article from my AI Learning Days session.
Final Thoughts
If you are considering the move, find one opportunity to take a requirement further than you normally would. Help clarify it, document it, review it with the right people, and follow it through testing.
That experience will give you something specific to discuss with a manager or interviewer. It will also help you decide whether you enjoy the work enough to make it your next role.