Who you need on your side of a Salesforce implementation

You need a small internal team with real authority, not just a partner. The core is an executive sponsor, a product owner who decides scope and a client-side project lead. Add subject matter experts from each affected department, a data owner, an IT owner and a future admin. Larger projects add security review, a change lead and power users. The partner builds; your people decide, supply data, grant access and accept the result.

Why does your own team matter more than the partner's?

Because every decision that shapes the system belongs to you. A partner can configure anything quickly, but it cannot decide how your business should work.

Stalled projects tend to share a pattern. The consultants were waiting on answers, data extracts or sign-offs that nobody inside the client had time to give. The build itself was rarely the bottleneck.

A capable partner team brings product knowledge, design patterns and delivery discipline. It cannot invent your pricing rules, pick which duplicate account is the real one, or tell a sales manager to change how they work. Those calls need someone on your payroll with the standing to make them.

Which roles should the client side fill?

Ten roles cover almost every implementation. Small companies combine several of them, but each set of responsibilities still needs a named owner.

• Executive sponsor: funds the project, sets the business goals and breaks ties between departments. Visible at kickoff, at major scope decisions and at the go-live call.
• Product owner: the single person who decides what is in scope and in what order the backlog gets built. Involved throughout, and the busiest internal role on most projects.
• Client-side project manager: keeps your own calendar, chases internal action items and tracks open decisions. Works opposite the partner's project manager rather than duplicating them.
• Subject matter experts: one per affected department, such as sales, service, finance or operations. They explain how work really happens, review designs and test their own processes.
• Data owners: know where each source record lives and which version is correct. They approve field mappings, cleanup rules and the final load.
• IT and integration owner: manages identity, single sign-on, connected systems and access to other platforms. Owns the technical side of every integration you keep.
• Security and compliance reviewer: checks sharing rules, field access, retention and any regulated data. Brought in at design time, not just before launch.
• Future admin: the person who will run Salesforce after the partner steps back. They should shadow configuration from the start, not inherit a finished org cold.
• Change and training lead: plans communication, schedules training and tracks whether people actually use the new process.
• Power users or champions: respected users in each team who test early builds, answer peer questions and report friction after launch.

What does each role decide, and when are they busiest?

Each role owns a specific set of decisions and peaks at a different phase. The table gives a quick reference you can adapt for your own project charter.

Which roles can one person hold in a small company?

Many pairs combine safely, but a few never should. The test is whether one person would end up approving their own work.

In a company with a few dozen users, three or four people can cover all ten roles. One common shape: the sponsor also acts as product owner, and an operations lead runs both project management and change. The future admin doubles as a power user.

Keep these apart even when headcount is tight:

• Product owner and partner staff: the person deciding your scope should not work for the firm billing for that scope.
• Security reviewer and the person who built the access model: someone else needs to check sharing and permissions.
• Acceptance tester and the person who configured the feature: builders test what they meant, not what users need.
• Data owner and the person running the load, when records are regulated or financial: a second pair of eyes should confirm the counts.

What does the partner supply, and what can only you supply?

The partner supplies expertise and labor. You supply decisions, data, access and acceptance, and none of those can be outsourced.

A typical partner team has a project manager, a solution architect or lead consultant, and configuration consultants. Developers join where code is needed, plus someone for data migration. They design, build, test their own work and coach your future admin.

Only your side can provide the following:

• Decisions about how your business operates, including which exceptions deserve their own process.
• Data extracts, answers about what odd values mean, and a ruling on which duplicate wins.
• Access to systems, sandboxes, test accounts and the people who own other applications.
• Formal acceptance that a feature works for your users, plus the call to go live.

If a proposal assumes the partner will make these calls for you, treat that as a risk. The first of these handoffs happens in discovery, so settle who attends before workshops start.

Who signs off on scope changes, data mapping, testing and go-live?

Name one accountable person for each of the four big approvals before the build starts. A simple RACI grid avoids most late arguments.

Scope changes that move cost or the launch date should also go to the sponsor for approval. Everything smaller stays with the product owner, or the sponsor becomes a bottleneck.

How can you tell the internal team is stretched too thin?

The signs show up in the partner's status reports long before they show up in the budget. Watch for decisions aging, not just tasks slipping.

• The open-decisions list grows from one status meeting to the next.
• Workshops get rescheduled because subject matter experts are covering their normal jobs.
• Data extracts arrive late, partial or in a different format each time.
• Testers sign off on scripts without logging any defects at all.
• The future admin has not opened the sandbox since kickoff.
• The partner starts proposing answers and asking you to confirm, instead of asking you to decide.

Any two of these together usually mean the project needs more internal capacity, not more consulting hours.

How do you free people from their day jobs?

Plan backfill on purpose, before the project needs it. Asking people to fit implementation work around a full workload is the most common staffing mistake.

• Move routine work from the product owner and key experts to colleagues for the heaviest phases.
• Pause non-essential internal initiatives that compete for the same people.
• Bring in temporary staff for clerical tasks, so experts are free for design and testing.
• Reduce sales or service targets for champions during acceptance testing, and say so publicly.
• Book recurring blocks for workshops and testing early, so they are not the first meetings cancelled.

Write the backfill plan into the project charter. If leadership will not fund it, that tells you something about the realistic launch date.

Who owns Salesforce once the partner hands it over?

Your future admin and product owner should own it, with a clear decision on what outside help continues. Ownership should transfer gradually during the build, not on launch day.

Agree in writing who owns the backlog, who approves changes and who maintains the documentation. The product owner usually keeps prioritization. The admin takes over configuration, user setup and release testing.

One of our Sales Cloud projects, for a multi-region technology-services firm, left a customer-success manager ready to run the system as its administrator. That works when the person is chosen early and learns alongside the build.

The reverse also happens. One manufacturer we worked with had several inexperienced admins who made the system unusable, and reps were not using it at all. The lesson for your team: name one accountable admin and give them clear standards.

If nobody internal has capacity for admin work, a managed services provider can cover configuration and releases. Your product owner should still set priorities. Outside help can run the platform, but it should not decide what your business needs next.

Before you sign with a partner, put names against each role in the first table. Any blank is a gap to fill or a risk to accept knowingly.