ChatGPT
Claude
Google AI
Copilot
On Sales Cloud, the AI worth integrating does a small amount of writing. Activity capture puts the email and the meeting on the record. Drafting prepares a note or a reply the rep can send. Booking a meeting puts a hold on a calendar when a rule says it may. Those three are enough to start. A model that moves an opportunity stage is a separate decision, and it is a policy decision.
The failure is a single afternoon that looks like progress. Activity capture logs a thread the rep had with the customer's lawyer and had marked personal. The timeline looks complete, so people stop checking it. A draft then proposes a discount that is not on the opportunity. A colleague sends it, because the sentences are clean and the last email "sounded committed". The same week, an action left on from the demo moves the stage. The forecast meeting argues about a number nobody agreed to change. Three quiet writes did that. None of them looked like a decision at the time.
Salesforce describes Agentforce, formerly Einstein Copilot, as support for employees in the flow of work: search for data, create an action plan, and execute it. Search and a draft sit inside that sentence. Execution is the part you fence. The page on how agents work adds the other fence. Responses come from trusted business data, including CRM data and Data 360, not from a general guess. Data Cloud was renamed Data 360 on 14 October 2025.
The word "best" in the title is those three jobs. It is not a ranking of vendors. A logo on a slide does not answer who may change a forecast.
Capture
Activity capture is a pipe from mail and calendar onto the opportunity, the contact, and the account. The rep should see what was logged and be able to remove a private thread. If the pipe is invisible, people stop trusting the timeline, and then they stop reading it. A timeline nobody trusts is worse than a blank one, because it looks complete. Completeness is what made the lawyer's thread survive into the forecast conversation. Nobody opened it. Everybody assumed the record was the record.
Write the exclusion list before you turn the pipe on. Personal mail, legal mail, internal-only threads, and anything the rep flags in the moment. The flag has to work the same day, not after a weekly cleanup. A thread that sits on the opportunity until Friday has already been read by a manager, quoted in a draft, and treated as a buying signal. Removal after that is an argument. Removal before the next sync is a control.
The rep also needs to see the match. Which message landed on which opportunity, and why. A rule that attaches every email from a domain to every open opportunity at that account will staple a facilities invoice to a renewal. The timeline gets longer. The draft that summarises "the last conversation" now includes the invoice. Say, in one line, what may attach: messages to or from the contacts on that opportunity, during the open dates, excluding the list above. Messages that miss the line stay in the mailbox.
Who is allowed to write those activity rows is the same question as any other integration. One pipe, one user, the fields that job may fill. Which system owns the email address you matched on, and what happens when two opportunities claim the same contact, sits with the ownership decisions in integration at programme level. The capture job does not get to invent a winner because both opportunities were open.
The draft
A draft is a suggestion. It can summarise the last call or propose a follow-up from the fields on the opportunity. The rep sends it. A draft that invents a discount, a close date, or a competitor claim is deleted, not polished into something close enough. Polishing keeps the false number and makes the manners better. The colleague who is in a hurry will send the polished one.
The source line is short. The opportunity fields you name. The contacts on it. The activities that survived the exclusion list. The articles or price guidance you have actually allowed, with a version. If a field comes from Data 360 rather than the CRM record, name it in that list the same way, or the draft is not allowed to use it. "We connected Data 360" is not a field. A product holding, a support flag, a consent marker: on the list, or absent from the draft.
A discount is the sharp case. If the opportunity has no discount, the draft may not offer one. If a price book says ten percent is available to this tier, the draft may mention ten percent only when that field is on the line and still current. A sentence such as "we can probably do something on price" is how a rep's aside becomes a customer expectation. Delete it. The rep can type a real offer. The model does not get to hint one into existence.
The rep sends. That is the control, and it is the same shape as the other CRM jobs in what is worth turning on. If you later let the draft leave on its own, you have changed the job, and you need a stop for price, date, and discount before you do. Until that stop exists, the draft stays in the box.
Booking
Booking reads availability and the contact, proposes a slot, and writes the meeting when the rule allows. The rule might be that the rep confirms every time, or that the model may book only inside hours you have listed, and only with a contact already on the opportunity. Write the rule on the same screen as the button.
A button that books with no rule fills calendars with the wrong people, and the reps stop offering the button. The wrong person is usually someone who was copied, not someone who agreed to be sold to. A procurement colleague on a thread, a personal assistant, an address from the lawyer's mail that capture should have excluded. The booking job reads the contact you named. It does not read "everyone on the last email".
A hold is not a meeting. If the rule allows a hold, write when it expires and what the rep is told. A hold that sits for a fortnight blocks a diary and teaches the team the button is unsafe. Expire it. Do not move the opportunity because a hold existed. A calendar row is not a stage.
The stage change is a policy
Stage is forecast. Moving it changes what the business thinks it will collect, and it changes the conversation in the forecast meeting. An action plan that executes a stage change has done something a sales manager used to do on purpose.
Decide, in writing, whether any model may change stage, and under which conditions. One sound policy is that the model may recommend a stage and a person moves it. Another is that the model may move it only when named fields are already filled and the amount is under a number your finance partner accepts. Both are policies. Write the fields. Write the number. Write who is told when an automatic move happens, the same day, so the forecast meeting is not the first time anyone sees it.
Leaving the action on because the demo looked quick is how forecast becomes fiction. The demo moved a stage on a record with every field filled, in front of people who wanted to see motion. Production records are missing the next step, the economic buyer, and a date the customer actually gave. A model that treats "the email sounded committed" as those fields will walk deals forward. The commit number rises. The deals do not. Finance notices at the end of the month, which is the worst time to discover the writer.
Recommendations that reps ignore are information about the policy, not a prompt to push harder. Ask why. Often the recommendation fires because an activity landed, and the activity was the facilities invoice or the lawyer's thread. Fix the capture rule. Do not train the rep to click through a suggestion the data does not support. Ignored advice is a signal. Buried advice, pushed until people comply, poisons the forecast and the timeline together.
What the rep still owns
The rep owns the relationship and the number on the opportunity. The integration owns the chore of getting the email onto the record and the first draft onto the screen. When those chores are wrong, the rep corrects them, and someone reads the corrections once a week.
Read them as a list, not as a feeling that "adoption is soft". A correction that removes a private thread means the exclusion list is short. A correction that deletes a discount means the draft's source line leaked. A correction that puts the stage back means the policy is either wrong or being ignored by the automation. Each of those has a different owner. Bundling them into a single complaint about the tool is how all three survive.
Constant corrections mean the integration is too wide. Narrow the fields it may write. Take discount, close date, competitor, and stage off the draft's allowed language unless the field is populated and the policy says the sentence is allowed. If the weekly pile does not shrink after that, stop the job that is producing the pile. A job people have to undo is not saving the chore. It is adding one.
This is not a vendor shortlist. You do not need five products on a slide to decide who may change a forecast. You need the three integrations working, the exclusion list, the source line, and one sentence about stage. A bake-off of logos answers none of those. It consumes the month you should have spent reading corrections.
The first three weeks
Week one is the exclusion list, the attach rule, and a rep who can see and remove what was logged. Run capture on one team. Read every logged thread they flag. Week two is the draft, with discount, date, and competitor banned unless the field is on the opportunity, and with any Data 360 field named or left out. The rep sends. Week three is the booking rule on the same screen as the button, and the stage policy written down with the fields and the amount, or with the recommendation-only line.
Then read corrections for a fortnight before you add a fourth write. The forecast meeting should be able to assume that a stage moved because a person moved it, or because the policy you can point at moved it. If they have to ask which, the policy is not in force yet. Leave the action off until they do not have to ask.
