Your organization, in conversation.
Nobody should have to learn a dozen systems to do their job. OrgOS is the customizable, AI-native organizational platform Phenomeny is designing — where you tell the system what you need instead of learning where it lives.
Where this stands today: OrgOS is on our roadmap and in active design. This page describes the intended architecture and product direction — not software you can buy today.
The problem
The information is there. Finding it is the job.
Most enterprise software does not fail because it lacks features. It fails because using it requires knowing the software. Employees end up trained on systems rather than focused on their work.
Too many systems
Separate tools for sales, operations, inventory, support and reporting — each with its own login, its own layout and its own idea of how work should be done.
Training before value
New employees learn the software before they can do the job. Every system added to the organization adds another thing to be taught.
Knowing where to look
The information usually exists. The difficulty is knowing which system holds it, which screen shows it, and which filter reveals it.
What an employee is asked to learn
The question they actually had: “What's the status of this order?” Everything between the question and the answer is software the organization had to teach.
The OrgOS idea
One organizational layer. Every role. Every resource.
Rather than adding another system for people to learn, OrgOS is designed to sit across the resources an organization already uses — and to become the single place where its people ask for information and get work done.
One layer, not one more tool
The intent is not to replace every system an organization runs, but to provide a single conversational surface across them.
Access follows the organization
Who should see what, and when, is designed to follow real roles, responsibilities and permissions — not a flat list of users.
Customizable by design
One underlying system, but no single fixed dashboard imposed on every organization, department or person.
The central idea
You should not have to learn
your own company's software.
Conversation is intended to become the primary interface to the organization itself. You do not need to know where a capability lives. You need to know what you want.
Traditional enterprise software
4 stepsLearn
Be trained on the system, its modules and its vocabulary.
Navigate
Find the right module, screen and view.
Search
Filter and drill down to the record you need.
Act
Finally perform the task you set out to do.
Value arrives only after the training does.
OrgOS — intended model
3 stepsAsk
Say what you need, in your own words.
Understand
Your role, permissions and context are applied.
Act
The answer or the action comes back to you.
The learning curve is meant to be the conversation itself.
The kind of request the interface is being designed around
Illustrative of the intended interaction model. These examples describe the product direction being designed, not a list of functions available today.
Customizable by role
One system underneath. A different experience on top.
This is not a permissions checkbox. The organization runs on one underlying system, and each person is intended to get the experience that matches their role, responsibilities and access — down to individual preference.
Leadership
- Performance across the organization
- Strategic information
- High-level reporting
Sales
- Customer and account context
- Pipeline and follow-ups
- Sales information
Operations
- Inventory and stock
- Operational status
- Workflows and processes
Customer support
- Open customer issues
- Support activity
- Unresolved requests
On these examples: the roles above illustrate how the customization model is intended to work. They are not a list of modules that exist and ship today — OrgOS is in design.
AI-customizable interface
In developmentChange the interface by asking for it.
Changing a dashboard usually means raising a ticket and waiting for a developer or an administrator. The concept we are building toward is that the person using the software can simply describe the change they want.
To be unambiguous: the exchanges above are a design illustration of where OrgOS is headed. This conversational interface-customization is product direction under development — it is not a deployed capability you can use today.
Organizational intelligence layer
How information is meant to move.
The hard part is not connecting systems. It is understanding who should have access to what information, when they should have it, and how it should travel through the organization.
Step 1
Organizational resources
The systems and information an organization already runs on.
Step 2
OrgOS
Designed to sit across those resources as one conversational layer.
Step 3
Role, permission, context
Who is asking, what they are responsible for, and what they may see.
Step 4
Personalized experience
The view and the information appropriate to that person.
Step 5
Action
The request is answered, or the work is carried out.
This flow describes the intended architecture of OrgOS. It is how the system is being designed to work, not a description of a running deployment.
Intended scope
RoadmapOne conversational layer. Many business functions.
OrgOS is intended to become a broad organizational platform rather than a single-function product. The important part is not the length of that list — it is that the way you interact stays the same across all of it.
Sales
Customers, pipeline and follow-ups.
Operations
Processes, status and workflows.
Inventory
Stock, movement and availability.
Customer support
Issues, requests and customer context.
Management
Oversight, performance and reporting.
Internal information
Documents, records and organizational knowledge.
These are not shipped modules. They describe the long-term scope OrgOS is intended to cover. Which areas get built first is a decision we would make with early partners.
The Phenomeny ecosystem
OrgOS is the layer the others report into.
MeetOS captures conversations. SalesOS holds the customer relationship. OrgOS is intended to decide where all of that information belongs and who should see it. BharatBaaS is intended to be what it all runs on.
Organizational information, access and experience
Intended to be the conversational layer across the organization — deciding how information flows, who should have access to it, and what each person sees.
In build · enterprise pilotsMeeting and conversation intelligence
Captures what is actually said in business conversations and turns it into structured signals.
Available for partnersSales and customer intelligence
Holds the customer relationship — requirements, objections, commitments and pipeline context.
Backend and data infrastructure
Intended to provide the underlying backend and data infrastructure layer the ecosystem runs on.
To be clear about status: SalesOS is available for partners and MeetOS is in build with enterprise pilots. OrgOS and BharatBaaS are on the roadmap. The connections between these products are being built progressively — they are not all live today, and we would rather say so than imply a finished platform.
Long-term architecture
Vision — not a productToward an AI-native ERP.
An ERP is normally a large collection of modules that an organization must be trained on. The direction we are working toward is different: the organization interacts with its business systems through a conversational layer instead.
The conventional ERP
- A large set of modules, each with its own interface.
- Implementation projects measured in quarters.
- Training as a precondition for using it.
- The employee adapts to the software.
The direction we are building toward
- One conversational layer over many business functions.
- The system carries the organizational context.
- Access and information follow real roles and responsibilities.
- The software adapts to the employee.
Today versus the future architecture: what exists today is SalesOS, available for partners, and MeetOS, in build with enterprise pilots. OrgOS, BharatBaaS and the AI-native ERP environment described here are the long-term architecture — they are not deployed products, and nothing on this page should be read as a shipped ERP.
Why OrgOS
Software that fits the organization.
Traditional enterprise software asks the organization to reshape itself around the system. OrgOS is being designed the other way round — configured to how a given organization actually works, so people can interact with it naturally.
Built as one system
OrgOS, SalesOS and MeetOS are designed to share context — not to be wired together after the fact with connectors that break.
Configured, not imposed
Organization, department, role, permissions and personal preference are intended to shape the experience, rather than one fixed dashboard for everyone.
Engineers, not resellers
These products are engineered in-house by PDDT Labs — the same studio behind the systems we run for partners.
Let's design this around your organization.
OrgOS is in design, which is exactly when your input shapes it most. Start with a strategy session: how your organization actually works, which systems your people are forced to learn, and what a conversational layer over them would need to do.
Step 1
Strategy session
Map how your organization works and where the friction is.
Step 2
Architecture review
Where a conversational layer fits your systems and roles.
Step 3
Design partnership
Shape what gets built first, as an early partner.
Sales@pddt.in · +91 99903 77727