Salesforce Business Analyst Intern

Choose a business you understand reasonably well, such as a coaching institute, clinic, or local service company.

Write a scenario describing how it operates today, including the spreadsheets, notebooks, and messaging groups it currently relies on.

Identify the stakeholders.

List at least four roles affected by a CRM, such as the owner, a frontline executive, a manager, and the person who maintains records.

For each, write what they want from the system, what they fear about it, and what would make them refuse to use it, since adoption failure is usually a stakeholder problem rather than a technical one.

Now write the discovery questions you would ask each stakeholder, at least six per role.

Make them open ended and aimed at how work actually happens rather than what system they think they want.

Then answer your own questions in character for each stakeholder, producing a realistic set of conflicting inputs.

Conflicts are the point: the owner wants more fields, the executive wants fewer.

From this, produce a requirement list separating must have, should have, and could have, and write one line justifying each placement.

Where two stakeholders conflict, state how you resolved it and whose need you prioritised.

Submit the business scenario, the stakeholder analysis, the discovery questions with in-character answers, the prioritised requirement list, and a note on the conflict you found hardest to resolve.

Pick one end-to-end process from your business, such as enquiry to enrolment or complaint to resolution.

Map the current state exactly as it happens, not as it should.

Record every step, who performs it, what tool they use, how long it takes, and where the work waits.

Include the rework loops and the steps people skip when busy, since an honest map is the only useful one.

Now analyse it.

Mark each step as adding value, necessary but not value adding, or pure waste.

Count the handoffs between people and the places information is entered more than once, because duplicate entry is where data quality dies.

Design the future state.

Produce a second map showing the process after a CRM, stating for each removed step why it is no longer needed and for each remaining step whether a person or the system performs it.

Quantify the improvement honestly.

Estimate the time saved per transaction and per month, state the assumptions behind your numbers, and name the one claimed benefit you are least confident in.

Finally, build the core of the future state in a free Developer Edition org you sign up for yourself, enough to demonstrate that the redesigned process is actually configurable rather than theoretical.

Submit both maps, the waste analysis, the quantified benefit with assumptions, screenshots of your partial build, and the confidence note.

Take your prioritised requirements and convert them into user stories.

Write at least twelve, each in the form of a role, a need, and a reason, where the reason explains the business value rather than restating the need.

For every story, write acceptance criteria as a testable checklist.

Each criterion must be something a tester can mark pass or fail without interpretation, which means avoiding words like quickly, easily, and properly.

Size the stories relatively, marking each small, medium, or large, and identify any that are too big to build in one go.

Split at least two of those into smaller stories that each deliver something usable.

Now map dependencies.

Identify which stories must be built before others and explain why, since sequencing errors waste more build time than estimation errors.

Then test your own writing.

Give three stories to someone else and ask them to describe what they would build.

Where their description differs from your intent, the story is at fault, so revise it and record what you changed.

Finally, write the one requirement you could not turn into a clean story, and explain what information you are missing.

Submit the twelve stories with acceptance criteria, the sizing and splits, the dependency map, the clarity test results, and the unresolved requirement note.

Set up a free Developer Edition org and work through standard Salesforce functionality against your requirement list.

For each requirement, classify it.

Mark it as met by standard functionality, met by configuration, requiring custom development, or better solved by changing the business process instead of building anything.

This last category is the one analysts most often miss and where the greatest savings sit.

Prove the configuration claims.

For at least six requirements you marked as configurable, actually configure them in your org and screenshot the result, because a gap analysis built on assumption is worthless.

For anything you marked as requiring development, write what it would take and propose a configuration-only alternative that meets most of the need, stating clearly what the business would give up.

Now write the recommendation for the business owner.

Set out what you propose building first and why, what you propose deferring, what you propose not building at all, and the reasoning in business language without Salesforce jargon.

Include the risks.

Name the three most likely ways this implementation disappoints the business and what you would do to prevent each.

Submit the classified requirement list, configuration evidence with screenshots, the alternatives for custom items, the recommendation, and the risk list.