Get in Touch

Tag: Decision Support

  • AgentExchange and the rise of prebuilt agents: build, buy, or customise?

    Salesforce launched AgentExchange as the marketplace for Agentforce: prebuilt agents, actions and templates you can install instead of building from scratch. The pitch is familiar if you’ve been around Salesforce long enough. AppExchange did the same thing for apps fifteen years ago. Install instead of build, and get to value faster.

    The question that actually matters isn’t “should I use AgentExchange.” It’s which decision applies to the thing in front of you: build it yourself, buy something off the shelf, or buy something and then rework it until it fits. Most teams default to one answer regardless of the situation. That’s the mistake.

    What’s actually on AgentExchange

    Listings fall into a few buckets. Fully packaged agents aimed at a specific job, like a service agent or a sales research agent. Agent actions, smaller building blocks you drop into your own agent. And templates: a starting structure for topics, instructions and guardrails that you still have to configure for your org.

    The marketing treats all three the same way. They’re not the same decision at all. A packaged agent is closer to installing an app. An action is closer to installing a library. A template is closer to downloading someone else’s starting notes.

    Build, buy, or customise

    Three honest options, and most orgs land in the third one more often than they expect.

    Buy wins when the job is generic

    If the task doesn’t touch anything specific to how your org runs, a prebuilt agent is usually the right call. Lead qualification against standard fields. Case summarisation. FAQ-style support questions where the knowledge base is already clean. These are commodity problems. Paying to solve them yourself is paying to reinvent something a vendor has already tested against thousands of orgs.

    The failure mode here is skipping evaluation because the install was easy. An easy install doesn’t mean the agent’s reasoning matches your process.

    Build wins when the logic is the differentiator

    If the value sits in how your org actually makes a decision, not whether a decision gets made, build it. A contact-centre team I worked with had a triage process that weighted case severity, customer tier and SLA exposure in a specific order, tuned over years. No off-the-shelf agent was going to replicate that without being rebuilt into something custom anyway. At that point, you’re not saving effort by starting from a template. You’re adding a translation step.

    Build also wins when the data behind the agent is genuinely unusual. If your object model, your Apex business logic or your approval chains don’t look like anyone else’s, a generic agent will either ignore that complexity or get it wrong.

    Customise is where most of this actually lands

    In practice, a lot of AgentExchange installs end up as a customise decision whether or not anyone planned it that way. You install a packaged agent, discover it’s 70% right for your process, and then start rewriting instructions, swapping actions and adding guardrails until it matches. That’s fine. It’s often faster than building from nothing. But budget for it as a build, not an install. Teams that treat a prebuilt agent as finished the moment it’s installed end up shipping something that technically works and practically annoys every user who touches it.

    What to check before you trust a prebuilt agent

    A few things matter more than the demo:

    • Where does it get grounded? If it’s pulling from Data Cloud, your data quality becomes its accuracy ceiling, no matter how good the agent’s reasoning is.
    • What actions can it actually take? A read-only agent and a write-access agent are different risk profiles. Know which one you’re installing before you see what it does in production.
    • Can you see its reasoning? If the vendor can’t show you why it made a call, you can’t debug it when it makes a wrong one, and it will eventually make a wrong one.
    • Who maintains the underlying logic? A vendor update to a packaged agent can change its behaviour without you touching anything. That’s a different maintenance burden than code you own.

    None of this is unique to AgentExchange. It’s the same diligence you’d apply to any third-party integration. The difference is that an agent making a wrong call is harder to spot than an integration throwing an error. A failed callout shows up in the logs. An agent that quietly routes a case to the wrong queue, or summarises a complaint in a way that drops the part that mattered, just looks like a slightly bad outcome. Nobody gets paged for that.

    The actual decision framework

    Before installing anything, answer three questions. Is the underlying process generic across orgs, or specific to how we run things? Does getting it wrong cost us a bad customer interaction, or something worse, like a compliance or financial problem? And are we prepared to own the maintenance of whatever we install, the same way we’d own a build?

    If the process is generic and the stakes are low, buy and move on. If either answer tips the other way, plan for build or customise from the start rather than discovering it three months in, once the packaged agent can’t be stretched any further.

    AgentExchange is going to keep growing. The marketplace model works, and Salesforce has every incentive to make it the default path into Agentforce. That’s a reasonable thing for a platform to want. It’s not a reason to skip the evaluation most teams would already run on any other third-party tool going into a production process.

  • Building a business case for a Salesforce enhancement, not just logging a ticket

    Most Salesforce enhancement tickets I’ve seen sit in a backlog for months, get bumped every sprint planning, then quietly disappear into a colder list somewhere. Not because the idea was bad. Because nobody ever wrote down what it was worth.

    A ticket describes a symptom. “Case assignment is slow.” “Reps re-enter the same data three times.” “The approval process takes two days when it should take two hours.” None of that tells a product owner or a steering committee why this fix matters more than the other fifteen things competing for the same sprint. A business case does that job. It’s the difference between an idea getting funded and an idea getting forgotten in a backlog nobody re-reads.

    Start with the metric, not the feature

    The instinct is to describe the solution first: “we need a new Flow,” “we should build a custom LWC for this screen,” “let’s add validation rules.” Stop there and you’ve written a technical spec, not a business case. Nobody outside the Salesforce team can evaluate whether a Flow is worth building. They can evaluate whether cutting case resolution time by 20% is worth three sprints of effort.

    Work backwards from a number the business already tracks, not one you invent for the pitch. Average handle time, case backlog size, order fulfilment cycle time, first-contact resolution rate, the number of manual steps in a process someone in ops complains about weekly. If leadership doesn’t already watch the metric, your business case has to do double duty: justify the fix and justify why anyone should care about the number in the first place. That’s a much harder sell.

    Three questions before you write anything

    • What number moves, and by roughly how much? Don’t chase false precision here. “Reduces average handle time by 60 to 90 seconds per case” is more credible than a suspiciously exact 73 seconds nobody can defend under questioning.
    • Who feels the current pain, and how often? A process that annoys one admin twice a month is a different case than one that costs every service rep four extra clicks on every single case.
    • What happens if this doesn’t get built? Sometimes the honest answer is “nothing much,” and that’s useful information too. It tells you to deprioritise it yourself before someone else does.

    What a real business case looks like

    I’ve worked with a contact-centre team where case assignment ran on a static round-robin queue, built years earlier when the team had a third of the headcount it has now. New agents got flooded with complex cases they weren’t trained for, senior agents sat idle between escalations, and average handle time had crept up for over a year with nobody able to say why. The fix, in Salesforce terms, was a skills-based Omni-Channel routing configuration with capacity weighting. Unremarkable, technically. Maybe two sprints of configuration and testing.

    The business case wasn’t “let’s configure Omni-Channel routing better.” It was: current average handle time is trending up 4% quarter over quarter, misrouted cases account for an estimated 15% of escalations, and every escalation costs the team roughly double the handling time of a case routed correctly the first time. Fix the routing logic, and the model predicted a measurable drop in escalation volume within two reporting cycles. That’s a sentence a delivery lead can put in front of a steering committee without translation.

    Size the cost honestly, including the boring part

    Every enhancement has a cost beyond the sprint estimate: testing, user training, change management, and the risk of breaking something that currently works fine. Leaving these out doesn’t make the business case stronger. It makes it fragile, because the first person who asks “what about regression testing on the existing automation?” exposes a gap you should have owned upfront.

    State the cost plainly. Two sprints of build, one sprint of testing and UAT, a half day of training for the team that uses it. If the enhancement touches a process with downstream integrations, say so and name what needs revalidating. A business case that admits its own cost is more credible than one that pretends the work is free, and it survives scrutiny from someone who’s seen enhancements blow their estimates before.

    Who actually reads this, and what they’re looking for

    A technical lead reading your case wants to know the approach is sound and the estimate is realistic. A product owner wants to know it fits the roadmap and doesn’t conflict with something already committed. Whoever controls budget wants one thing above all: a number they can defend to their own leadership later. Write for that last person first, because if they can’t repeat your case in their own words in a follow-up meeting, it won’t survive contact with prioritisation.

    That means cutting anything that only makes sense to someone who already knows Salesforce. “Reduces flow interview steps by consolidating three screen flows into one” is an implementation detail. “Cuts the time to process a standard order from four minutes to under ninety seconds” is a business case. Keep both versions if you need them, the technical detail for your own team, the outcome for everyone else, but don’t hand the wrong one to the wrong audience.

    The case that never got approved, and why

    I’ve also seen the other version: a well-built enhancement, genuinely useful, that never got funded because the request arrived as a two-line ticket asking for “improved data quality on the Account object.” True, probably, and completely unactionable for anyone deciding where to spend the next quarter’s capacity. Nobody could say what “improved” meant, what it currently cost the business to not have it, or what would change if it shipped. It sat in the backlog for over a year before someone finally reframed it around duplicate account records causing incorrect territory assignment, at which point it got approved in the next planning cycle without much debate.

    Same technical work, same team, same effort estimate. The only thing that changed was whether anyone reading the request could tell what it was worth.

    Write it short

    A business case for a Salesforce enhancement doesn’t need to be long. Half a page is usually enough: the metric, the current cost of not fixing it, the proposed change, the estimate including the boring parts, and what success looks like in numbers someone can check later. Anything longer starts competing with the reader’s patience instead of their attention.

    Log the ticket if you want a record. But if you want the enhancement built, write the case first. The ticket describes what’s broken. The business case is what gets someone to spend their limited capacity fixing it instead of the fifteen other things asking for the same slot.