How we scale support
When inbound grows, our first move is not adding headcount for triage. The priority is leverage: sharper pages, fewer dead links, and answers that live in the repo so every visitor benefits.
We think in a try/catch model: the static site, handbook, help section, and runnable demos should resolve most questions before anyone needs a human.
Make the surfaces better
Incoming themes feed what we fix next in HTML/CSS, copy, and Neuro OS demos. Rough categories we use for planning:
- Reliability (build, deploy, broken assets)
- Usability (navigation, clarity, mobile)
- Functional (wrong behavior in demos or scripts)
- Docs & accuracy (handbook, tutorials, outdated screenshots)
- Abuse & safety (spam, misuse of public embeds)
- Partnership & enterprise (longer conversations, custom touchpoints)
Create documentation dynamically
Each thread should leave a durable asset when possible: a doc fix merged on GitHub, a new handbook FAQ, or a small site change in a PR with a Vercel preview so support and engineering see the same truth.
Support the people doing support
If answering is painful, the site is wrong. Signals from Success are high-priority input alongside Design and Engineering—not an afterthought.
Track frequency
Repeat questions get issues or labels on GitHub (linked from conversations) so we spot trends, bundle fixes, and close the loop in release notes.