Salesforce Process Improvement Intern

Improvement requires an honest baseline, and the honest version is never the official version.

Choose a process you can observe or reconstruct reliably, such as how a coaching institute handles an enquiry, how a clinic books and follows up appointments, or how a small business handles a complaint.

Map it as it actually happens.

Document every step in sequence, who performs it, what tool or paper they use, how long the step takes, and how long the work waits between steps.

Waiting time usually dwarfs working time and is where improvement is easiest.

Include the unofficial reality: the steps people skip when busy, the workarounds they have invented, and the rework loops when something is wrong.

A map showing only the official process cannot be improved because it describes something that does not happen.

Measure what you can.

Record the number of steps, handoffs between people, systems or tools touched, and places the same information is entered more than once.

Gather the pain.

For each person involved, record what frustrates them most and what they would change, since the people doing the work know where the waste is.

Then quantify the baseline.

Estimate total elapsed time per transaction, total working time, and the volume per month, stating your assumptions.

Finally, write the single step you suspect causes the most damage downstream, and the evidence for that suspicion.

Submit the process map with timings, the unofficial reality, the measurements, the pain points per person, the quantified baseline with assumptions, and the suspected root problem.

The most valuable improvement is removing a step, not speeding it up, and this task finds those.

Classify every step on your map as adding value from the customer's point of view, necessary but not value adding such as compliance or record keeping, or pure waste.

Be strict, since generosity here produces an improvement plan that changes nothing.

Quantify the waste.

Total the time in each category and express value-adding time as a percentage of elapsed time.

The number is usually uncomfortably small.

Identify the specific waste types: duplicate data entry, waiting for approval, chasing information, correcting errors, reporting manually, and work done that nobody uses.

Now find root causes rather than symptoms.

For the three worst problems, ask repeatedly why until you reach a cause that is not itself caused by something else.

A step existing because a form requires it, which exists because nobody questioned it, is a different problem from one existing for a real reason.

Separate what a system can fix from what it cannot.

Some waste comes from policy, incentives, or how people are organised, and automating around it entrenches it.

State plainly which of your problems Salesforce cannot solve.

Decide the eliminations.

List the steps you would remove entirely before any system is built, with the reasoning and the risk of removing each.

Then challenge yourself.

Write the step you believe is waste but which the business will insist on keeping, and how you would make that case.

Submit the classified map with percentages, the waste type analysis, the three root cause investigations, the system-versus-policy split, the elimination list with risks, and the contested step argument.

Design the future state from the eliminations rather than from the current process, so the system supports the better process rather than the existing one.

Map the future state.

Show the process after improvement, and for every step state whether a person or the system performs it, who is accountable, and how long it should take.

For every step you retained, justify why it survived.

State the eliminations explicitly, with what replaces each removed step and what risk you accepted.

Set the targets.

Define the measurable outcome for the new process covering elapsed time, touches, and error rate, so success is verifiable rather than asserted.

Now build it.

Sign up for a free Developer Edition org and implement the future state: the data model capturing what the process needs, the automation handling the steps the system now performs, the access model so each participant sees their part, and the reporting that makes the process visible.

Make the handoffs explicit.

Every point where work passes between people must be visible in the system, since invisible handoffs are where work stalls.

Run it end to end.

Process at least five transactions through your build from start to finish, timing each and recording every point it was awkward.

Then fix what the run revealed.

Make at least three changes based on actually running the process rather than designing it, and record what the design had missed.

Finally, measure against your targets honestly, including anything not met.

Submit the future state map with step justifications, the eliminations with accepted risks, the targets, the build with screenshots, the handoff visibility, the five end-to-end runs with timings, the three fixes, and the measurement against targets.

A better process that people refuse to adopt delivers nothing, and this task addresses the human half.

Identify the resistance specifically.

For each person affected, write what they lose in the new process, whether that is autonomy, a task they enjoyed, a reason they were needed, or simply familiarity.

Dismissing this as fear of change is why change programmes fail.

Address each one.

For every loss, write what you would offer or change, and be honest about where you have nothing to offer.

Plan the rollout.

Decide between all at once and phased, with your reasoning, and write the sequence, who goes first and why, and what you would do if the first group struggled.

Build the enablement.

Write the quick reference a user needs on day one, no longer than one page, and the three things they must do differently from before.

Then test it by having someone follow it to complete a task.

Plan for the dip.

Write what will get worse in the first two weeks, since every process change costs productivity before it returns any, and state what support is in place during it.

Set up benefit measurement.

Define the metrics proving the improvement, implement the reporting in your org, and record the baseline so later comparison is possible.

Without a captured baseline the benefit can never be demonstrated.

Then write the failure conditions.

State the three most likely ways this change reverts to the old way, and the early warning sign for each.

Finally, write a one page summary for the business owner covering what changed, what it delivers, what it costs in disruption, and what they must personally do.

Submit the resistance analysis with responses, the rollout plan, the tested quick reference, the dip plan, the benefit measurement with baseline, the failure conditions, and the owner summary.