Run the storefront from Slack.

The team has agreed on the offer. The copy is in the thread. Somebody asks whether it’s live yet.

Then somebody else has to leave Slack and go make all of it happen.

That’s the part of running an ecommerce business I want to change. If marketing and merchandising are already working through the decision in the same conversation, why should carrying it out require a separate trail of messages, tickets and admin screens?

I’ve been building a merchant agent that brings that work into Slack. Here is where it started.

The request was one sentence

I asked an agent to put a fleece on sale.

Put the Summit Fleece on 20% off through Sunday.

It asked me to clarify the Sunday. Fair. Dates matter when you’re changing what somebody pays.

Once the date was clear, it showed me the proposed change. I approved it. The promotion was applied, and the storefront price was checked.

$144 became $115.20.

That was an early test in my Après Studio demo. I didn’t need to open Business Manager or send the request to somebody who knew which screen had the right checkbox.

I’ve spent enough time in commerce to know that putting a product on sale is not a new invention.

Being able to stay with the decision instead of stopping to operate the software is the part that interests me.

Marketing and merchandising in the same thread

I’m using Claude, from Anthropic, with its Slack integration. My merchant-agent work connects that conversation to the storefront: ask about the catalog, review a proposed change, approve it and check the result without moving the whole discussion somewhere else.

Salesforce B2C Commerce remains the commerce platform. The agent helps operate it; the team doesn’t have to move its catalog or rebuild its business inside Slack.

The scope has grown beyond that first fleece promotion.

The current prototype has tools for pricing and markdowns; product, order and shipping promotions; coupons and campaign audiences; product copy and search metadata; storefront editorial content and images; categories, product positions and sorting. It can also check stock and apply approved inventory changes where that belongs in the merchant’s operating model.

That means the conversation can include the offer, the products it applies to and the content explaining it to the shopper. Marketing and merchandising can work on the same customer experience without translating every decision into a different request for a different specialist.

The useful requests sound ordinary:

• Check which promotions are running before we add another one.
• Put these products on sale for the weekend.
• Change the announcement so it matches the offer.
• Move this product higher in the category and update its description.
• Show me the result before we tell customers about it.

Those are examples of the work the toolset is intended to support, not a claim that every retailer’s configuration is interchangeable. Some changes are visible immediately. Others need the storefront’s normal publishing or indexing work before the customer sees them.

I want that difference to be clear in the conversation. “The change was accepted” and “the shopper can see it” are different answers.

I want the merchandiser spending attention on whether the offer makes sense, not remembering where the setting lives.

The shopper gets the result, not the process

A shopper doesn’t care how many people were involved in setting up the promotion.

They care whether the offer they saw is the offer they get. Whether the product is available. Whether something the store told them five minutes ago is still true when they try to buy it.

That is why I see this as customer-experience work as much as an internal productivity idea.

If a team can spend less time moving a request between people and screens, it has a better chance of dealing with the actual issue while it still matters. That is the opportunity I want to test with a retail team.

I’ve been exploring the shopper-facing side with Juniper, the Claude concierge inside Storefront Next, and Stripe checkout in the storefront and the conversation. This looks at the people running that experience. All three have to agree about the same product and offer.

Moving faster is only useful if the customer gets the right result.

Easier to use should not mean easier to get wrong

This is where my enthusiasm comes with conditions.

Natural language can make a request feel simple while leaving plenty of room for misunderstanding. “This weekend” is not a complete business rule. Neither is “all the fleece.”

The experience needs to make the intended change clear, keep the person responsible in control and give them a result they can inspect. If something cannot be completed, that should be clear too. A cheerful “done” is not much use when the storefront says otherwise.

Before I would put this into a retailer’s production workflow, the permissions, accountability and operating expectations need to fit that business. A working demo is evidence that the experience is possible. It is not a substitute for that work.

Approval needs to mean approval by the right person, for the right scope of change, with a record the business can rely on. Those team-level controls remain production work for this prototype. Access to a chat is not, by itself, permission to change a retailer’s prices.

I don’t want a merchandiser to need engineering knowledge to use it. I do want engineering judgment behind what it is allowed to do.

I’m talking about storefront marketing and merchandising here, not claiming the entire business now runs from a Slack thread. Order operations and sales reporting are not part of this prototype’s current scope. Page Designer layout authoring still belongs in its existing interface. Paid media, email campaigns, finance and fulfilment need their own systems and connections.

Where I’d start with a retail team

I’d start with the request that keeps getting passed around.

The recurring change that is easy to describe but still waits for the right person. The question someone has to leave the conversation to answer. The offer everybody agreed on that is still waiting to reach the storefront.

Pick something useful enough that the team notices when it gets easier. Then measure the time from an agreed request to a verified storefront result, how many handoffs it needed and how often somebody had to correct it. Compare that with the current workflow. Check whether the promotion, product and copy agree when the shopper gets there.

I don’t have a retailer productivity number to attach to this yet. Less time in admin screens is only useful if the work is correct and the customer gets the intended experience.

That is the conversation I’m interested in having with retailers. Less time translating a decision into administration. More attention on the decision itself.

If something came to mind while you were reading, tell me what keeps getting handed off.

The request is probably already a message.