Choosing a Salesforce partner in Australia: what the tiers do not tell you

This page is a buyer's guide rather than a pitch. It covers what the words actually mean when a firm says it is a Salesforce partner, what the current tier structure does and does not measure, the questions that separate a delivery team from a sales team, and the clauses your agreement needs so that leaving later is possible. If you are already talking to two or three firms, the section on the six questions is the one to read first.

What "Salesforce partner" actually means in Australia

The phrase covers at least four different commercial arrangements, and they are not interchangeable. Asking "are you a Salesforce partner" gets a yes from all four, which is why the question tells you nothing.

• An implementation partner. Scopes and builds: discovery, data model, configuration, custom code, migration, testing, go live. This is what most buyers think they are shopping for, and it is a project with a start and an end.
• A managed service provider. Runs the org after go live: admin tickets, user provisioning, release management, monitoring, small changes. Sold as a monthly retainer, often to organisations that already have a Salesforce instance and nobody to look after it.
• A licence reseller. Sells the subscriptions. Some resellers also deliver projects, many do not, and a few are effectively a billing relationship with a logo on the invoice. Buying licences is a real need, but it is a purchasing decision, not a delivery one.
• An AppExchange product vendor. Sells a managed package that solves a defined problem, such as document generation, field service scheduling or backup. The product might be excellent and the vendor might have no implementation capability at all beyond installing it.

The failure mode is a mismatch between the arrangement and the need. A business that wants its existing org looked after buys a six week implementation. A business that needs a complex build buys a licence reseller because the quote was lowest. A business that needs one product installed buys a full system integrator and pays for a discovery phase it did not need. Before you evaluate anyone, write down which of the four you are actually buying, and put that sentence in the brief.

What the partner tiers do and do not tell you

Salesforce restructured its consulting partner program for its FY27 year. The structure is now two tiers, Select and Summit, with newly approved partners starting in a Provisional status before they qualify, replacing the four tier structure that most Australian partner pages still describe. At the same time the old Navigator specialisation list, roughly 170 items, was retired and replaced with 28 competency badges. Eligibility is reviewed quarterly against Salesforce's own fiscal year, which runs from the first of February to the end of January, and a change takes effect at the start of the following month.

None of that is a statement about delivery quality. The tier ladder is built from certifications held, projects submitted and customer satisfaction scores returned to Salesforce, plus Salesforce's own strategic judgement in cases where it overrides the standard criteria. It tells you the firm has a real relationship with Salesforce and meets the program's evidence requirements. It does not tell you the firm has anyone who has built the thing you need, in your industry, at your size.

Two practical consequences. First, a higher tier usually comes with a higher minimum engagement, because a firm paying for Summit-level overhead cannot run a small project profitably. Second, a Select partner that has done nine builds of exactly your use case is a better bet than a Summit partner that has never touched it, and the Select partner will usually say yes to a scoped discovery to prove it. Ask what tier they are by all means, then ask what it would take to be wrong about them, and listen to whether the answer is specific.

Source note: the tier structure and the reduction from roughly 170 Navigator specialisations to 28 competencies are as described in Salesforce's FY27 consulting partner program materials. Partner program terms are revised each program year, so check the current terms rather than relying on any partner page, including this one.

Why "we have two hundred certifications" is a weak answer

Certifications belong to individuals, not to the firm, and the number on the website is a count of people who passed an exam at some point. It does not tell you who is on your project, how recently they sat it, or whether the person who did the discovery is the person who does the build. In larger firms the answer is frequently no, which is the single most common reason projects drift between the sales cycle and delivery.

The question that actually resolves this: name the people who will be on my project, tell me their roles, and tell me what percentage of their week I get. Then ask whether any of the work will be subcontracted, and if so which parts and to whom. Subcontracting is not automatically bad, and a partner with a genuine specialist bench overseas can be the right answer for a hard integration. Being surprised by it in month two is bad. Ask whether the named people are employees or contractors, and ask what happens to your project if the lead leaves.

A related habit worth testing: ask for the last three projects the team delivered that were similar to yours, and ask what went wrong on them. Any firm that claims nothing went wrong is either new or not answering. The useful answer names a specific constraint, a migration that ran long, an adoption problem that needed a second round of training, and what they changed afterwards.

Six questions worth asking before you sign anything

These are the ones that change the answer. They are also the ones a weak partner will try to answer with a capability deck.

If you would rather have that positioning worked out for you first, the free Salesforce review covers the org, the automation and the support you are currently paying for, and tells you which of the four arrangements you actually need.

1. What would you tell me not to build? A partner with real judgement has opinions about scope. If every request is met with "yes, we can do that", you are talking to an order taker and the scope will grow until the budget does.
2. Who owns the configuration and the documentation? The answer should be you. Ask to see a sample of the documentation they hand over at go live, not a description of it. If the sample is a video call recording, you have your answer.
3. What happens to our admin team? The good answer involves training your people so they can handle the routine work. A partner that keeps everything opaque is selling dependency, whether or not that was the intent.
4. How do you handle change requests? Ask for the actual mechanism: who estimates, who approves, what the rate is, and how long the estimate holds. Vague answers here are how fixed-price projects become open-ended ones.
5. What does the exit look like? Ask directly what happens if you want to move to another firm in two years. Reasonable partners have a transition clause and will describe it without flinching.
6. Who do I call when something breaks on a Friday afternoon? Get a name, a channel and a response expectation in writing, before go live rather than after the first outage.

How to tell whether a partner will still be useful in year three

Most of the value or damage from a partner relationship shows up long after the invoice for the build. The signals are structural rather than personal, which means you can inspect them before you commit.

• Release notes. Every change to a production org should leave a written trace: what changed, why, who approved it, how it was tested and how to reverse it. Ask to see a real example from a real client, redacted if necessary. Firms that do this well produce it as a byproduct, so it takes them ten seconds to find.
• Named configuration, not tribal knowledge. If the only person who understands the commission calculation is a contractor who is not on your account any more, the build is a liability regardless of how well it works today.
• Admin credentials and access. You should hold the keys to your own org. That means you control the production login, the integration user credentials and the connected app secrets, and you can revoke a partner's access the day the engagement ends.
• A visible queue. Support work should be tracked somewhere you can see, with priorities that you agreed. Email only support is a sign that nobody is measuring response time.
• Willingness to be measured. Ask whether they report on ticket volume, response time and reopened issues. A partner that tracks its own numbers is usually a partner that improves.

This is also where the small decisions get made that look trivial and are not: whether the org has a naming convention, whether there is a sandbox refresh schedule, whether anyone has looked at the storage and API limits since implementation. Those are exactly the findings a structured review turns up, which is a separate exercise to a build and worth doing before you scope more work.

Commercials: what the agreement should actually contain

You do not need a law degree to spot a one-sided services agreement, but you do need to know which clauses matter. Five of them carry most of the risk.

• A rate card with named roles. One blended hourly rate hides the difference between a principal consultant and a junior. Ask for the rates by role and the assumed mix, then compare like with like across quotes.
• Change control in writing. Who can request a change, who estimates it, how long the estimate holds, and what happens if the change is not approved. Without this, the scope conversation happens verbally and then gets settled by whoever is more confident.
• Ownership of what gets built. Configuration, custom code, documentation and any data model design should be yours, or licensed to you perpetually. Watch for language that ties deliverables to an active subscription.
• Access and credentials. Your org, your logins. A partner holding the only admin account is a commercial risk, not just an operational one.
• Transition assistance. A defined obligation to help a successor firm or your own team take over, at a stated rate, for a stated period. This is the clause that keeps a managed service honest, because the cost of leaving is visible before you sign.

On price: there is no useful benchmark without scope. A quote for a build with one integration and a hundred users is not comparable to one with four integrations, a data migration and a custom approval matrix, and firms that quote a single number without a discovery phase are guessing. Ask what the estimate is based on and what would move it. If you want to understand the licence side separately, that is a different conversation from delivery cost, and it is worth reading our breakdown of what Salesforce costs in Australia before you compare partner quotes.

Partner, in-house admin, or managed service

The right answer depends on volume and volatility, not on company size. Any org with more than a handful of regular changes per month will eventually want an internal admin who understands the business, even if a partner does the technical work. An org with a stable, lightly customised implementation and one change a quarter is usually better served by a retainer with a firm than by hiring.

A workable structure for most mid-sized Australian businesses: an internal admin who owns the business processes and the user relationships, plus an external partner for architecture, complex builds, integrations and overflow. That keeps decisions inside the business and technical depth outside it. What does not work is an external partner holding both, because nobody internal can then tell whether the advice is sound or just billable. If you want a read on which structure fits the org you have today, the free review covers that too. If you want to see how that division of labour is structured in practice, the Salesforce consulting page covers it, and the work we have delivered includes the platform builds it refers to.

Questions we get asked about Salesforce partners

Do we need a Salesforce partner at all?

Not always. A small org on Sales Cloud with standard objects, a few automation rules and an internal admin who is comfortable with the tool can run for years without one. The point where external help earns its cost is usually a complex integration, a migration with dirty data, a build that needs architecture decisions you will have to live with, or an implementation nobody internal has time to lead.

Can we use an offshore partner instead of an Australian one?

Often yes, with conditions. Time zone overlap matters less than people claim, provided the handover discipline is genuinely good and there is an accountable person in your time zone. What matters more is that the firm can evidence work in your regulatory context, understands local payroll, tax and superannuation requirements if your org touches them, and can be reached when something breaks in your business hours. Verify the employment model as well as the price, because a quoted rate that assumes a subcontractor chain is a different product.

Does a bigger partner mean less risk?

It means less risk of the firm disappearing and more risk of being a small account inside a large one. Larger firms bring process, bench depth and formal delivery governance, which matter on large programs. They also bring junior staffing on smaller engagements and a commercial incentive to grow the engagement. The relevant question is not size, it is who is accountable for your outcome and whether that person has the authority to make decisions without escalating.

How do we switch partners without losing everything?

Do it as a documented transition, not a handover call. Collect the current configuration documentation, a complete list of automation and integrations with owners, the credential inventory, and the last twelve months of release notes. Get read only access to your own production metadata confirmed before the old partner's access is reduced. If documentation is thin, pay for a structured review of the org before the new partner starts, so the incoming team is working from evidence rather than from the outgoing firm's account of itself. That review is worth doing even if you are staying put.

---

Start with the review, not the partner search

Choosing a partner is easier once you can describe what your org actually needs, in writing, with evidence. The free Salesforce review looks at the org, the automation, the release history and the support you are currently paying for, and tells you plainly where the risk sits and what the next twelve months should cost. If your current arrangement is sound, that is a legitimate outcome and we will say so. You do not need to be choosing a partner to book one, and plenty of the businesses that do are simply confirming that they do not need to change anything yet.