Boston Dynamics: one front door for a robot fleet.
Spot walks industrial sites. Stretch unloads trucks. Orbit runs the fleet. Everyone who operates, maintains, or trains on those machines needs answers from one place, and export law decides who may see what. I led the full rebuild of that place.
A support center for robots is not a FAQ page. The products are machines with hardware revisions, software releases, payloads, and repair procedures, operated by customers and partners across regulatory borders. The old center had grown the way support content always grows: article by article, each one true when written, drifting as the product moved. The rebuild of support.bostondynamics.com replaced that accretion with an architecture.
This is the second case study in a pair. The SailMOB study shows how I build my own product; this one shows the same discipline inside a client org, where the hard problems are content architecture, integration, and compliance rather than physics.
Start with the audit, not the tools
The rebuild started with a full content and process audit, not with software selection. Before anything got designed, I inventoried what existed, traced who actually read it, and mapped the process that produced it, because sprawl is never the disease. It is the symptom of a publishing process without an owner. Fixing the article that is wrong today does nothing about the pipeline that will make another one wrong next quarter. The audit found the causes, and the architecture that followed was designed against them.
A design system, not a coat of paint
The visual rebuild shipped as a design system: reusable components with defined behavior, not a set of prettier pages. That is what lets three different orgs publish into one center and have it come out looking and behaving like one product. The system was designed in Figma and is part of the deliverable itself, something the client's teams keep building with after the engagement ends.
Componentized content: write once, version everywhere
The center runs on Paligo, a component content management system, and the content strategy is componentized to match. A procedure is written once as a component and reused wherever it applies, so a fix lands everywhere at once instead of in one article and out of date in four others. The architecture handles both versioning axes a robotics product forces on you: hardware revisions and software releases move independently, and the documentation has to stay true against both.
You can read the architecture in the public navigation: release notes, software updates, hardware, maintenance, and repair each have a home, per product, instead of one undifferentiated article pile.
Compliance is an architecture problem
Boston Dynamics ships under ITAR export controls and into both US and EU markets. That cannot be handled by asking writers to be careful. Who may see a given piece of content has to be a property of the content itself, enforced by the pipeline that publishes it. The compliance pipelines were built into the content architecture from the audit onward, which is also why parts of the center sit behind registration and partner login: the public layer, the customer layer, and the partner layer each get exactly the content they are entitled to.
Three orgs, one front door
Product, Services, and Training all publish into the center, and each came with its own systems: Salesforce for support, Jira for engineering, Docebo for training, Paligo for documentation. The integration work is what makes them feel like one product: a customer moves from reading an article to filing a case to enrolling in training without leaving the center or re-explaining who they are. The deep integration with Salesforce and Jira means the support workflow and the engineering workflow stay connected behind the scenes, instead of connected by someone copy-pasting between tabs.
What carries over to your business
Most companies are not shipping robots under export control, but the pattern transfers whole. Audit before architecture, so you fix causes instead of symptoms. Componentize the content your business runs on, so a fact lives in one place. Make access rules a property of the system, not of people's caution. And integrate the tools you already own before buying new ones. That is the work behind knowledge management and CRM integration, and it is the same discipline whether the subject is a robot fleet or a service business.
Where do your customers go for answers?
If the honest answer is "five places, and two are stale," that is fixable. I audit how your knowledge moves, design the system that owns it, and wire it into the tools you already run.