Salesforce Consultant Intern

Choose a business to treat as your client, something you understand well enough to reason about.

Write the discovery brief.

Document what the business does, how it currently operates, the systems and spreadsheets in use, the volume of transactions, who would use a CRM, and what specifically is going wrong today.

Separate symptoms from causes, since clients describe symptoms and consultants are paid to find causes.

Quantify the problem.

Estimate what the current situation costs in time, lost work, or errors, and state the assumptions behind each figure.

A business case without numbers gets deferred indefinitely.

Define success explicitly.

Write what must be true in six months for this project to be considered worthwhile, in terms the client can verify.

Now scope it.

Write what is in scope, and more importantly what is out of scope with the reason for each exclusion, because unmanaged scope is the most common cause of consulting failure.

Identify the constraints honestly: budget, the client's technical capacity, who will maintain the system afterwards, and what the business will resist changing.

Then phase the work.

Propose what to deliver first and why that order, stating what value the client receives at the end of phase one on its own.

Finally, list the five questions you would most need answered before committing to this engagement, and what you would assume in the meantime.

Submit the discovery brief, the quantified problem with assumptions, the success definition, the scope statement with exclusions, the constraints, the phasing, and the open questions.

Consulting value lies in the options considered and discarded, not only the one chosen.

Design the solution for your phase one scope, covering the data model, the process the system will support, who gets what access, what is automated, and what gets reported.

For every significant decision, document the alternatives.

Where you chose a custom object, state what using a standard object would have meant.

Where you chose automation, state what leaving it manual would have cost.

Where you chose to configure, state what a custom build would have added.

Give each alternative a fair account rather than a straw man.

Now justify in business terms.

For each decision, explain the reasoning in language the client understands, referring to their cost, risk, or capacity rather than to platform features.

Estimate the effort.

Break the build into components with an effort estimate each, state your assumptions, and identify which estimate you are least confident about.

Identify what you are deliberately not solving, and what the client should do instead, since recommending a process change over a build is frequently the better answer.

Then assess the risks.

Name the three most likely ways this solution disappoints the client, with a mitigation for each.

Finally, build the core of it in a free Developer Edition org, enough to prove the design is implementable rather than theoretical, and record anything the build revealed that the design had missed.

Submit the solution design, the rejected alternatives with fair treatment, the business justifications, the estimate with confidence notes, the deliberate exclusions, the risk assessment, and the proof-of-concept build with findings.

Build your phase one solution in full in your org: objects, fields, relationships, security, automation, and reporting as designed.

Populate it with realistic data so a demonstration shows a working system rather than an empty shell.

Now prepare the demonstration.

Script it as a walkthrough of the client's own process rather than a tour of Salesforce features, since clients evaluate whether their work is easier, not whether your configuration is clever.

Prepare for the three hardest questions the client could ask.

Record or script the demonstration end to end, showing the process from the perspective of each user type.

Then handle change.

Write three change requests the client raises after seeing the demonstration, phrased as a real client would.

For each, assess the impact on scope, effort, and timeline, and decide whether to absorb it, defer it to a later phase, or decline it.

Write the response you would give the client for each, in a tone that preserves the relationship while protecting the project.

Implement the one you decided to absorb, and record what it actually cost against your estimate.

Then reflect on your own design.

Having built it, write what you would design differently, since this gap between design and build is where consulting judgement develops.

Finally, write the handover note the client's own administrator would need to maintain this.

Submit the completed build with screenshots, the populated data, the demonstration script with anticipated questions, the three change requests with assessments and responses, the absorbed change with actual effort, the design reflection, and the handover note.

This is the deliverable that gets read by the person paying, and it is judged on clarity rather than technical depth.

Assess what was delivered against the success criteria you defined at discovery, honestly, including anything not met and why.

Write the executive summary of at most one page, stating what the business now has, what measurably changed, what to do next, and what it would cost.

Assume the reader goes no further than this page.

Then write the main recommendation of roughly 900 words.

Cover what was built and the benefit in business terms, the decisions you took on their behalf and why, what you deliberately did not build, what the business must now do differently for the system to deliver, and the risks remaining.

Avoid Salesforce terminology entirely, because a recommendation needing translation does not get acted on.

Build the roadmap.

Propose the next two phases with what each delivers, its rough effort, its dependency on phase one, and the business reason for that order.

Mark anything you would advise against building at all, with reasoning.

Address adoption directly.

State what will cause this system to be abandoned and what the owner must do in the first month to prevent it, since most CRM failures are adoption failures rather than build failures.

Finally, write the single piece of advice you would give this owner if they only remembered one thing.

Submit the success assessment, the one page executive summary, the main recommendation, the two phase roadmap with exclusions, the adoption guidance, and the closing advice.