Good service design is not just the screen a customer sees. It is the routing, the queues, the permissions and the channels working quietly behind it. This series documents how I stand up customer service on Salesforce end to end, from a public self-service site to a live human conversation, so a question never falls through a gap.
Category 1 Biking is a UK bike shop with a small chain of stores and a passionate, loyal following. The community was active, but the shop had no way to engage beyond a handful of social media pages. I built them a self-service Experience Cloud site and wired live Enhanced Chat behind it, so fans can find answers themselves and reach a real person when they need one.
The shop had great word of mouth, hosted local meetups, and had started sponsoring road races. What it did not have was a single place for that community to search for answers, ask questions, or reach the team directly.
Engagement lived on scattered social platforms the shop did not control or own.
Every question, however simple, had to become a phone call or an in-store visit.
There was no way to move a customer from browsing to a real, routed conversation.
I enabled Digital Experiences and built the site on the Customer Service template, chosen because it gives members a searchable knowledge base, Q&A, and case creation out of the box.
Picking the right template is a design decision, not a technical default. The Customer Service template leads with search and self-service, which matches how a curious cyclist actually behaves: they want to find the answer themselves first, and only then talk to a human.
A chat button is useless if no one is listening. Before touching the channel, I built the routing that decides who a conversation goes to and how many a person can handle at once.
Turned on skills-based and direct-to-agent routing so work distributes to the most available, qualified person.
Created a Category 1 Biking config with a Most Available model and a set capacity, so agents are never flooded.
Built the Category 1 Biking Queue, scoped to Messaging Sessions and linked to the routing configuration.
Added the support user to the queue, so live conversations always have a real owner.
I created a dedicated MIAW (Messaging for In-App and Web) permission set rather than loosening a profile. It grants the ability to initiate messaging sessions and full access to the Messaging Session object, then assigns cleanly to the support user.
Scoping access to a purpose-built permission set is a quiet but important design choice. It keeps the system auditable and safe: the person can do the messaging job and nothing they should not, and the access can be revoked in one place.
With messaging enabled, I added an Enhanced Chat channel and connected it straight to the routing I had already built, so the moment a customer starts a chat it lands in the right queue.
This is the join between front stage and back stage: the customer sees a simple chat window, but behind it the channel points at the Category 1 Biking Queue through Omni-Queue routing. Nothing is left to chance.
Finally, I brought the channel into the Service Console by adding the Omni-Channel utility, so staff can accept and answer messages without leaving their workspace, and added Send A Message to the global publisher for outbound conversations.
Category 1 Biking now owns its community space, lets fans self-serve, and can pull anyone into a real, routed conversation the moment they need help.
A messaging channel is only useful once customers can actually reach it. This is the end-to-end deployment: standing up a secure web deployment, wiring the browser security handshake, dropping the chat window onto the Experience Cloud site, and building the console page where agents answer.
The support channel and its routing existed, but the chat window itself had no home. Getting live conversations onto a public site is not a single toggle. It is a chain of dependencies that all have to line up.
The channel needed an Embedded Web deployment to render a chat window on a real page.
Cross-origin and content-security rules stop an external site from talking to Salesforce until explicitly trusted.
Incoming chats have to land on a record page built for handling a live conversation, not a generic layout.
I copied the Experience Cloud site domain, then created a new Embedded Service deployment: Enhanced Chat, Web type, pointed at the Category 1 Biking Support Channel.
Choosing Enhanced Chat over legacy web chat matters. It gives customers a persistent conversation that survives a page refresh, which is the modern, expected behaviour. Binding the deployment to the existing channel means every conversation inherits the routing and queue already built.
This is the invisible work that makes everything else function. A browser will not let an external site exchange live data with Salesforce unless the origin is explicitly allowed and the content-security rules permit it.
Added the site URL to the Cross-Origin Resource Sharing allowed origins, so the browser permits the exchange.
Pulled the real-time messaging endpoint (scrt2URL) from the deployment's code snippet.
Registered that endpoint as a Trusted URL scoped to Experience Builder Sites, with all six CSP directives enabled.
Skip any one of these and the chat window silently fails to load. Getting it right is the difference between a demo and a deployment.
In Experience Builder I dragged the Embedded Messaging component into the template footer so it rides along on every page, set it to always visible, opened the site to guest users, and published.
Footer placement is deliberate: one component, present site-wide, so a customer can start a conversation from wherever their question strikes, not just a dedicated contact page.
The last piece is where the agent works. I built a Messaging Session record page for the Service Console, cloned from the default, then added a dedicated Messaging tab holding the Enhanced Conversation component.
I activated it as the org default across desktop and phone, so every incoming chat opens on a purpose-built page: the live conversation on the left, customer and case context on the right. That is the difference between an agent who is guessing and one who has everything in view.
A customer on the Category 1 Biking site can now open a persistent chat from any page, and every conversation lands on a console page built to answer it.
Category 1 Biking's support team ran on FAQs taped to office walls and cash registers. The task was to turn that scattered knowledge into a searchable Lightning Knowledge base on the community site. The twist: the standard Service Setup route was missing from my org, so I had to find another way in.
A quality supply of knowledge articles does wonders for case deflection, customer satisfaction and agent productivity. Category 1 Biking had the knowledge, it was just in the wrong place: printed FAQs stuck to walls and registers, invisible to anyone online.
Every repeat question became a call or a visit, because customers could not self-serve an answer.
Knowledge needed a record type, a proper answer field, and a layout before it could hold real articles.
The guided Service Setup route the documentation assumed simply was not present in this org.
The instructions said to open Service Setup and run the Knowledge guided setup. That menu was missing from my gear icon. Rather than stall, I reasoned backwards from what the wizard actually does, and went straight to the underlying setting myself.
Every guided setup is just a friendly wrapper around real configuration pages. So I opened standard Setup, searched Knowledge in Quick Find, went into Knowledge Settings, and enabled Lightning Knowledge directly, assigning myself as a Knowledge author in the process. Same destination, different door. This is the part of the job that never appears in a tutorial: when the happy path is gone, you need to understand the system well enough to build your own.
With Knowledge live, I shaped the article itself. A simple FAQ record type, a long text field to hold the answer, and a page layout that puts that field exactly where an author expects it.
Confirmed the FAQ record type, so articles are typed for simple question-and-answer content.
Created a Text Area (Long) field, 32,768 characters, three visible lines, made visible to every profile.
Dragged the Text field directly under Title in the Information section, so writing an article reads top to bottom.
Structure before content. Get the object right first and every article after it is effortless.
Without Knowledge topics enabled, articles cannot be displayed outside the org. Category 1 Biking wants conversations and articles to cluster around common themes, so I enabled Topics for the Knowledge object and pointed topic suggestions at the article Title.
With the foundation in place, I opened Knowledge from the App Launcher and authored three real FAQ articles, each marked visible to customers, then published all three in one pass.
The articles answered genuine community questions: a product release date, how to find local bike groups, and expected delivery times. Small, human answers, now searchable on the site instead of taped to a register.
Category 1 Biking's FAQs now live where customers actually look, and the whole base was stood up despite the standard setup route being unavailable.
Articles that exist but cannot be found may as well not exist. This is the information architecture layer: giving the community three clear topics to navigate by, dressing them with imagery, and tagging every article so it surfaces in the right place.
The knowledge base was live, but the site had no structure to lead people to it. Category 1 Biking wanted the community to navigate around clear themes, and to grow that structure over time.
Nothing on the site told a visitor where to go or how the content was organised.
Even the right topics feel lifeless without imagery to invite a click.
Each article sat on its own, unconnected to any theme a visitor might browse.
Working in the site's Content Management workspace, I defined three navigational topics that map to how the community actually thinks: Customer Support, Social Groups, and New Products.
Navigational topics become the site's menu. Keeping it to three is a deliberate IA choice: enough to cover the ground, few enough that no one feels lost. Structure first, then decorate.
Featured topics appear prominently on the home page, so I promoted all three and gave each a photograph: a support rep, a group ride, and a rider celebrating a new product.
Imagery is not decoration here, it is affordance. A photo tells a visitor at a glance what lives behind a tile, and makes the difference between a menu people scan past and one they click into.
Structure only works if content is linked to it. In Article Management I assigned each of the three FAQ articles to its natural topic: delivery to Customer Support, bike groups to Social Groups, and the product question to New Products.
Back in Experience Builder, the work came together on the home page: three image-led featured topics, a topics menu in the header, and trending articles pulling through automatically.
Category 1 Biking's community now has a clear structure: three themed topics, each with a face, and every article tagged to surface in the right place.
The final layer: giving the site a face with custom branding, a Cases menu item and a header image, then publishing and testing the entire experience end to end, from a live chat to an asked question to a submitted case.
Everything worked, but the site still wore the default template. It needed a headline that speaks to the community, colours and imagery that feel like Category 1 Biking, and a way to reach cases, before it was ready to publish.
The default headline said nothing about who the community was for.
Stock colours and no hero image left the site looking like a template.
Nothing had been tested end to end from a real customer's point of view.
In Builder I gave the site a voice and a look: a "Category 1 Biking, Welcome to the community!" headline, adjusted theme colours, and a road-cycling header image to set the tone the moment a visitor lands.
Branding is not paint on top. The headline sets intent, the colours carry the identity, and the header image gives the page a sense of place, together they turn a functional template into somewhere the community feels they belong.
I added a Cases item to the navigation menu, wired to the Case object with a My Open Cases list view, so members can track their own support requests. Then I published the site.
A build is not done until it is proven. I set Omni-Channel to Available Messaging, opened the live site, and walked the full journey a real member would: chat, ask a question, and open a support case.
Started a chat from the site and accepted it in the Service Console, confirming the whole routing chain works in production.
Posted a New Products question from the site and watched it appear under the right topic.
Created a new contact and submitted a case through Contact Support, end to end.
Confirmed the new case appeared in the My Open Cases list on the site's Cases menu.
Category 1 Biking fans can now engage with the company and each other in a whole new way: branded knowledge organised by topic, a live chat button, a way to ask questions, and self-service cases, all proven end to end.