Prices change. Services get added. Websites go stale.
Not because updating a website is hard, but because updating one usually means editing code, and editing code means finding whoever edits the code.
So the site quietly falls behind the business, and you and I have both browsed sites where the real price was "call to confirm".
The knowledge post split your business's knowledge into the explaining stuff and the exact stuff.
This post is about the records. Structured data is one of the Second Brain OS Website Operator's jobs: it holds your products and services in one catalogue, your company details in another record and your team in a third.
It is trained to put the exact thing in the place it belongs. The outcome is the one every service business dreams of but very few have.
Change a price once and the pricing section on your site, the answer on WhatsApp, the answer on Instagram and the quote in a proposal all agree the same minute, with nobody touching the website and nobody retraining the AI receptionist.
Three kinds of records: Company, People and Products
An API endpoint is the unglamorous name for an address a system exposes so other systems can ask it to do something. The Operator keeps three kinds of records this way: your company details, your team and your product catalogue.
Now for your product catalogue, there are two endpoints:
addProductsputs a product or service into the system: name, description, price.listProductsreads the catalogue back out.
It's simple stroed in a lightning fast database that both, your website and AI receptionist can pull from. The product id, name, description, price and currency are standard, but feel free to include more fields.
And best part? You can add your products in one of two ways:
- Through the Second Brain OS Website Operator via Claude Code
- By loggging into secondbrainos.com and just adding the product details
Bonus: there's a complete funnel visualizer in the Second Brain OS, so that you can predict the return for every $1 in Ad Spend and solve the natural next problem in advance.
What do I mean by that? Well think of the magic I've been doing here.
From Day 0 I have been asking & answering one simple question: 'If you as my customer get this, what do you need next?' Or in other words, if I give you an AI Receptionist then what would be the next problem I can solve for you.
So we went from AI Receptionist -> Availability & Appointment Booking -> Full Appointment Lifecycle -> Public Knowledge -> Website with Chat, Forms, Emails and Analytics.
Just like that, the dashboard's ROI calculator reads your product catalogue and helps you models your real offers with real numbers.
Don't like a product or it doesn't make sense as part of your funnel? Kick it out, change the pricing or change the order. Bottom line: you can see what the problem in your funnel is and what you need to change.
Now I've learnt to do this the hard way. But the funnel visualizer in the dashboard puts everything I've learnt into an intuitive UI. Which you play with to learn.
The website calls listProducts
The products section on this site is not hardcoded. When the page renders, it calls listProducts and displays whatever comes back.
Add a service through addProducts, and it appears on the website. Change a price, and the page shows the new one.
No deploy, no code change, no developer in the loop.
The catalogue is data, and the website is just one reader of it.
The receptionist calls it too
Now the part that makes it a system rather than a convenience: your AI receptionist reads the same catalogue.
When a customer asks what something costs, the receptionist quotes the current price, because it looked it up rather than memorised it. When a visitor describes what they need, the receptionist matches them to the right offer from the live list.
One source of truth, two readers.
Change a price once and the website, the website chat, WhatsApp, Instagram and Telegram all agree in the same instant. The disagreement between what your site says and what your bot says, the one from the start of the knowledge post, is not fixed here so much as made impossible.
Company details: one record, every email
The second kind of record is smaller and easier to forget: your company itself. Name, address, phone, email, and the bank details a customer needs to pay you.
Two endpoints again. updateUserCompanyDetails writes the record, getUserCompanyDetails reads it back. The dashboard has a plain form over the same record for the days you would rather type.
Here is why it earns its own record rather than a line in a system prompt. Those details appear everywhere and nowhere in particular: in the footer, in the booking confirmation, in the receipt, in the proposal, in the newsletter's legal line. Type them in five places and one of them will still carry the old phone number two years from now.
So the Operator reads them from the record when it writes for you. The emails post covered the "thanks for booking" and "thanks for paying" messages the events trigger; the Operator fills the signature, the address and the payment details in those from getUserCompanyDetails, and the same for proposals and any document it drafts. Move office once, update the record once, and every email sent after that carries the new address.
And the read endpoint can be attached to your AI receptionist as a tool. "Where are you based?", "What is your number?", "Can I pay by bank transfer?" get answered from the record, on every channel, and stay right when the record changes.
Your team, starting with you
The third kind of record is people, and at this point in the series it assumes exactly one of them: you.
A solo founder, a single practitioner, one person who is the face of the business. That is the default the Operator sets up. addFireStoreEmployee creates your record, name, title, bio, photo, your calendar link and your status, and getFirestoreEmployeeRecord reads it back.
The website reads that record for the 'About You' page . The receptionist reads it when a customer asks who they will be speaking to. Same rule as products: change your bio or your calendar link once and both surfaces follow.
Why a record for one person? Because the day there are two of you, nothing has to be rebuilt. The record already has the shape a team needs, and the team post at the end of the series is where several people, each with their own services and calendar, get matched to the right customer. That is a separate, heavier setup. For now, one record, your name on it.
Why this suits a one-time purchase
There is a reason this matters more here than on a subscription platform.
The website code is free and open source, and the $397 SBOS Website Operator that brings it to life is one-time. A one-time purchase has to stay current for years without a retainer, or it was not really a purchase.
The way you get that is exactly this separation: the code is stable and yours; the knowledge, the catalogue, the company record and the team record move freely on top of it, at the speed of your business.
The exact stuff through records, the explaining stuff through the knowledge base, code untouched by either.
A note on prices: every price in this series is the price inside its funnel, where each purchase unlocks the next. Bought on its own, outside the funnel, the same product can cost up to 30% more.
Next up: the analytics deep dive, where consent, sessions and the CRM meet.