Context
Knowledge workers spend about 60% of their time on work about work: context-switching, status updates, repeated data entry, coordinating across systems. The friction concentrates in four places:
- Noisy — too many notifications across too many surfaces
- Siloed — disconnected systems prevent visibility and flow
- Inefficient — repetitive manual entry of the same information
- Inaccurate — limited trust in AI outputs without proper context
Why Slack?
Slack already holds the enterprise work graph: conversations, decisions, files, relationships, mentions, channels. That graph is the substrate LLMs and agents need to do real work for a company.
If AI is going to operate inside a business, Slack is where the context already lives.
Approach
Two months of cross-functional exploration: joint work sessions with Slack and Salesforce Cloud teams, customer intercepts at Dreamforce, and 20+ feedback sessions on early concept iterations.



What I argued for
The org was already moving. Internal and external demos all depicted the same near-future, a DM with an agent that gets your work done, and our work had to draft off that. The question I kept pressing was why Slack. If the answer was just “conversational entry point,” any chat surface would do.



The sharper argument: Slack’s value to agents is the work graph underneath it. The channels where collaboration already happens, the decisions and context already accumulated, the existing pattern of who-talks-to-whom that an agent can read as ground truth. Other surfaces don’t go away. They’re the substrate the conversation reads from.
That reframed the design problem. Instead of five parallel agent surfaces, Slackbot becomes the single front door, with channels, canvases, and dashboards as the destinations the conversation hands off to and the context it reads from. The conversation is the interface; the rest is the source of truth.
Vision
A near-future demo of Slack as a company’s home base for getting work done — conversation with Slackbot as the primary surface, with channels, canvases, dashboards, and agent task views as the places the work lands.

Three persona stories
We grounded the vision in three end-to-end walkthroughs, one for each of the major Salesforce clouds. Each story was scripted and prototyped as a continuous demo.
Sales



Marketing



Service



Strategic impact
The work reshaped my own role: I now lead design for Slackbot, which inherited the ownership of this vision. The demo did something a spec couldn’t have — it gave a fragmented org something to point at and commit to. By the end, Slack as the interaction layer for Salesforce wasn’t a proposal anyone had to argue for. It was just what we were building.
Reflection
A vision demo isn’t a usability test or a product spec. It’s a vehicle for argument: something a fragmented organization can point at and say yes, that’s the shape we want.
Holding the why Slack question against an org already convinced of yes Slack took longer than I’d like to admit. The reframe was obvious in retrospect; while we were in it, it just felt like pushback.
The lesson I’ll carry forward: don’t start with the surfaces. Start with the use cases, watch where they collapse, and let the right surface fall out as a consequence.