Understand your work OS
ProductOS: an offer becomes useful when it meets a need.
Your AI OS connects a customer’s expressed need with your products and services. Structure the catalogue, review the terms and find relevant relationships before preparing an offer.
The catalogue your customers can ask about.
In the customer base scope, your team adds, edits, activates or removes offers in the delivered interfaces. Visitors browse only the authorised catalogue and can submit an enquiry. Other ProductOS functions documented below are distinct from this initial scope.
Everyday work
You have the offer. Who was looking for it?
A service is mentioned during a call. Its conditions live elsewhere. A customer asked about it weeks ago. ProductOS helps turn an available, validated offer into information the team can use and share.
From a service mentioned to an offer worth sharing.
Diagnostic visit
Travel + diagnosis
Repair work
01StructureGive the offer its useful details.
A diagnostic visit is mentioned in the available work context.
Includes: travel and diagnosis. Repair: separate quote. Price and availability: to confirm.
A detected mention is a starting point, not a published product.
02ValidateKeep the conditions the team can rely on.
The responsible person reviews the description before commercial use.
The visit covers diagnosis. No repair is included. A separate quote follows if work is needed.
Missing commercial details still need confirmation before a commitment.
03Use and shareBring the offer back into the relationship.
“Who asked for a diagnostic visit?”
Review the accessible customer requests, check whether the need is still current and prepare a relevant reply. Publish a product page only when the offer is ready to share.
Searching, preparing a reply and publishing are separate operations.
Fictional example, not a product screenshot. Sources and access require configuration; illustrated answers use the information shown.
A catalogue your team can use in real conversations.
A product, property or service can support a customer answer and, once published, have its own public page. Publishing one offer does not expose the private catalogue or the company’s customer records.
Find the people behind an expressed needOn this page
An offer does not live only in a table
A product or service includes a description, conditions, a possible price and recurring questions. ProductOS makes a validated offer available in authorized AlefOS workflows.
The internal catalogue, a mention of an offer in a conversation and a published page are different objects. A passing mention does not automatically become a public offer.
Identify, structure and validate
A mention in authorized context can lead to a suggested product or service, or a validation mission. The user must be able to confirm, correct, archive or delete the proposal before a consequential use, publication or synchronization.
A detected proposal proves neither product availability nor its final price. Commercial conditions must come from validated information.
Use the catalogue in customer work
A confirmed product can help retrieve business information, prepare a product sheet, answer a request or structure a catalogue within the authorized scope.
For example, a customer asks about a maintenance package. The employee retrieves the validated service, its conditions and the request context before preparing a response. ProductOS is not a public marketplace by default.
Publish a specific object
A published product can have a public /p/:productId URL. The page presents the published offer and configured contact methods. It does not open the entire workspace or the complete private catalogue.
Publication must be an explicit decision in the relevant workflow. An internal change does not promise immediate synchronization to every external tool.
A published record is not the whole catalogue
A service record can keep its description, scope, conditions and validated pricing information. Its state matters: suggested, confirmed internally and published are distinct stages. A public page presents the selected information and configured contact options.
Ask “What is included?” or “Which page should I send?” using the confirmed offer. A catalogue does not by itself promise live stock, checkout, a marketplace or publication to every provider.
Let customers explore what you offer
A buyer describes the home they need. A customer asks which maintenance service fits their equipment. Your plugin draws on the catalogue you choose to publish: offers, properties, services and the useful conditions attached to them.
The next step can be a question or a viewing request. Finding an offer does not reserve it, guarantee its availability or expose your internal catalogue. You decide what is published and how the request reaches your team.
A useful product or service record
Scroll the table to read every column. With a keyboard, use the left and right arrow keys.
| Field | What it clarifies |
|---|---|
| Description | What is offered and which customer need it addresses. |
| Conditions | The applicable scope and validated terms; missing details remain questions. |
| Status | A suggested item, a confirmed offer and a published page are distinct. |
| Chosen public link | The selected public information, without exposing internal client context. |
Operational reference
Modules, tools and access conditions
This reference describes MCP operations and their effects. The list exposed to your assistant depends on the deployed server, enabled modules and permissions. Reading, preparing and executing are distinct operations.
ProductOS catalog
A detected suggestion, a confirmed internal product and a published /p/:productId page are distinct. Check the record and publication scope before sharing an offer.
Scroll the table to read every column. With a keyboard, use the left and right arrow keys.
| Tool | Function and effect |
|---|---|
products. | List managed products and services within current catalog limits. |
products. | Read a managed catalog product or service. |
products. | Prepare a product or service creation preview. |
products. | Update an internal product; preview mode returns an action_id. |
products. | Archive an internal product; preview mode is available. |
Contacts and relationship context
Search identity fields, read linked context and inspect confirmed products. Adding or enriching a contact is a write operation; the preview mode depends on the tool policy.
Scroll the table to read every column. With a keyboard, use the left and right arrow keys.
| Tool | Function and effect |
|---|---|
contacts. | Search contacts by identity fields, with cursor pagination and source filtering. |
contacts. | Read one contact profile and its available relationship context. |
contacts. | Find confirmed products in the contact’s product memory. |
contacts. | Add or enrich a contact; preview behavior follows the selected mode. |
The scenarios on this page illustrate workflows, not real customer data or guaranteed outcomes. Connections and capabilities must be enabled and verified for your environment. Official business systems retain their responsibilities.
Continue exploring
A capability of your company’s environment. Your team can use this capability from a compatible assistant through its configured MCP access. The deployment defines the enabled tools and permissions. Understand your AI connection ↗