Who to hire for Spindle AI

A finance director asks a fair question in the first meeting: if the model says a pricing change lifts revenue, whose number is that? It is not the vendor's, and it is not yet the company's. It is a calculation based on assumptions, and the assumptions belong to people. The question of who to hire for Spindle AI is largely the question of who can keep that chain of ownership intact while the model runs.

Salesforce completed the acquisition on 21 November 2025. The announcement explains what the platform does: "Their agentic business analytics platform allows business teams to simulate the impact of complex, data-driven decisions, like pricing and packaging, GTM optimization, and sales mix shifts with AI." It also tied the acquisition to Agentforce, naming agent observability and self-improvement, along with ROI forecasting and continuous optimisation. Two quite different jobs sit in that description, and a hiring brief should separate them. One is business scenario modelling for decisions such as price and sales mix. The other is measuring how well agents perform and forecasting the value they deliver. Decide which you are buying before you meet anyone.

#Scenario model or forecast

A forecast estimates what is likely to happen on the current course. A scenario model estimates what would happen if you changed something: a price, a package, a territory design. They need different evidence. A forecast is tested against what later occurs. A scenario is tested against whether its assumptions were reasonable and whether the decision it informed worked out.

Partners blur the two because both produce a chart with a line going upward. Ask a candidate to explain, in your own terms, which of your decisions will use a scenario and which will use a forecast, and what would make them distrust each. A candidate who can answer without jargon has built these before.

Salesforce already has forecasting features in Sales Cloud and analytics in Tableau and CRM Analytics. A partner should be able to say why a scenario tool is needed beside them and how outputs flow back. If they cannot say what the new capability adds that the existing ones do not, you may be paying for a duplicate.

#Skills and certifications

You need three kinds of competence.

The first is data. A scenario is only as good as the history under it, so someone must find, clean and govern that history. Salesforce Certified Platform Data Architect covers data modelling at volume, and Salesforce Certified Data 360 Consultant applies where data from several sources is unified before modelling. The earlier name, Data Cloud, still appears in older proposals, and a candidate should know both.

The second is analytics. Salesforce Certified CRM Analytics and Einstein Discovery Consultant shows experience with dashboards and with predictive models inside Salesforce. Ask for evidence of a model that was explained to a sceptical audience, because that is the real exercise.

The third is business analysis and configuration. Salesforce Certified Business Analyst helps with turning a decision into requirements, and Platform Administrator or App Builder skills are needed to place results on records. For agent value measurement, Agentforce Specialist shows the person understands what the agents do.

No exam certifies the judgement that matters most, which is declining to model a question the data cannot support. Ask for an example of when the candidate told a client exactly that.

#A first scenario worth buying

Choose one decision with a date and an owner. Suppose you are considering a change in discounting for a product line. Write the decision as a question: if the maximum discount falls by a stated number of points for new business, what happens to win rate, deal size and revenue over the next two quarters?

Then list the assumptions in a table that a non-technical director can read. For each assumption record the value, the evidence, the owner and the date it will be reviewed. A partner should drive this step, and it is also where the project often ends in a useful way, because writing the assumptions shows which ones nobody can defend.

Run the model on historical periods first. If it cannot reproduce last year's result within a tolerance you agree in advance, the forward numbers deserve little weight. Only then run forward scenarios, and present them as a range with assumptions beside it.

#The field-name rule

Before any number is written to Salesforce, require a field name. If a scenario output is going to appear on an Opportunity, an Account or a dashboard, agree the object, the field, the data type, the label sellers will see, the refresh rule and the permission set that can edit it. Without that, a model result becomes a note in a text box, then a screenshot in a deck, and nobody can later say where it came from.

The rule also protects your forecast calls. Mixing a modelled number into the field sellers use for their commit confuses the process, and it erodes trust in both. Keep modelled values in separate fields with clear labels.

#What good governance looks like in a modelling project

Governance sounds heavy, but on this kind of project it reduces to four habits. The first is a register of models. Each one has a name, a purpose, a named owner, the data it reads, the date it was last validated and the decisions it has informed. A spreadsheet is enough. The second is a change log: when an assumption changes, someone writes down what changed, why and who agreed. The third is a review date. Models decay as markets shift, so a model without a review date is a liability waiting to be discovered. The fourth is a clear rule for who may act on a modelled result. A forecast that a seller can edit freely, or a scenario output that anyone may paste into a board paper, will eventually do damage.

A partner who raises these habits unprompted is thinking about the long life of the work. A partner who sees the project ending at the demonstration is thinking about the sale.

#Agent value measurement is a separate brief

The announcement ties this acquisition to Agentforce, including observability and forecasting the value agents deliver. If that is why you are interested, write a separate brief for it. The questions differ. You will want to know which agent conversations or actions are being measured, what counts as a good outcome, what the human alternative costs, and who will review the measurement. The data comes from agent logs and from outcomes recorded in Salesforce, and the skills are closer to observability and service operations than to pricing analysis.

Do not let a single partner stretch one proposal across both. A pricing scenario for next year and a measure of how well a service agent resolves cases have different owners, data and review cycles. Splitting them also makes it easier to compare quotes, since the line items are not blended.

#Red flags

A partner who shows a polished forecast without opening the assumptions has shown you a picture.

A partner who promises accuracy before looking at your history is guessing. Ask what accuracy they would measure and over what period.

A partner who writes model outputs into existing forecast fields is risking your pipeline discipline.

A partner who proposes to model everything has not chosen a decision. Scenario work thrives on a narrow question.

A partner who cannot explain where your data would be stored, and who can see it, has not thought about privacy. Pricing and sales mix data is commercially sensitive, so ask who at the partner will see it.

#Who needs to be in the room

Scenario work fails when only the analysts attend. Insist that the owner of the decision, a finance representative and one person from the sales team who will live with the outcome join the assumptions session. Each will challenge a different assumption: finance questions the cost base, sales questions the win-rate effect, and the decision owner questions whether the scenario even matches the choice on the table. An hour with all three saves weeks of rework, and it gives the eventual result a constituency that already understands how it was built. Ask the partner to run that session in the first fortnight and to treat absent owners as a project risk, not an inconvenience.

Plan the handover with equal care. At the end, someone inside your organisation should be able to refresh the data, rerun the model and explain the output without the partner present. If the design needs the partner for every refresh, you are renting an answer rather than buying a capability, and that should be a conscious choice, priced accordingly.

#Ten questions

1. Is this a scenario model or a forecast, and how will each be tested?
2. What does this capability do that our existing forecasting and analytics do not?
3. Which field will hold the output, on which object, with which label?
4. Who owns each assumption, and when is it reviewed?
5. How will the model reproduce a past period, and what tolerance do we accept?
6. Which data sources feed it, and how are gaps handled?
7. Who can edit outputs, and how are changes logged?
8. How do you stop a modelled value from entering the commit forecast?
9. What would you advise us not to model with our data?
10. How will we know, six months later, whether the decision it informed was sound?

#Checking evidence

Ask a previous client what the model got wrong and how they found out. Ask for an anonymised assumptions table from a past engagement. Ask whether any decision was reversed or changed because of what the model showed, which proves it was used.

Look for evidence of the explanation step. A finance director or head of sales should be able to describe how the model reached its answer after one session, and a reference can tell you whether that happened.

#Commercial models and the statement of work

A fixed-fee first scenario is sensible, because the deliverable is clear: assumptions table, back-test, scenario results and a decision note. Data preparation is the usual source of overrun, so treat it as a capped time-and-materials item with a review point. Keep platform licences with Salesforce and out of the services quote; the licence page covers that conversation, and the implementation cost page shows what drives a services quote.

The statement of work should list the decision, the data sources, the date range, the assumptions table, the back-test tolerance, the output fields and permissions, the refresh rule, the people who may see sensitive data, the handover and training, and what is excluded. Add an acceptance test: the partner explains the result to your finance lead and answers questions without the vendor in the room.

#When to skip a partner

If your question is a straightforward forecast of a single measure, Sales Cloud forecasting or a CRM Analytics dashboard may already answer it, and an internal analyst can build either. If you have no clean history, a partner cannot conjure one, and the first purchase should be data work. If nobody will own the assumptions, wait.

See also what happened to Spindle AI, integrating Spindle AI with Salesforce, should I migrate from Spindle AI and Spindle AI and Agentforce. The primary source is the Salesforce announcement, and the analytics credential is on Trailhead.