Simple Ops
The planned home for the operational products, not a product itself.
For Operations leaders evaluating more than one Simple Intelligence product who want to know whether they will eventually be one thing.
Six of the products in this portfolio cover work that most organizations run as one continuous operation: winning the work, planning it, doing it, billing it, marketing it, and administering the tenant underneath. Buying six things that behave like six things is a worse outcome than buying one. Simple Ops is the decision to organize those six under a single name and a single lifecycle. It is a decision, not a release. Nothing has been built under the name, nothing is for sale under it, and every one of the six is bought, signed into, and used on its own today.
When you can get Simple Ops
Coming soonNot open yet. Tell us where to send word when it is.
What you can do now
Get product updatesNone of these creates an account, a trial, or access. Each one records what you asked for so a person can answer it.
Where this stands
- Availability
- Coming soon
What it costs
No published price yet. Pricing is set before this product opens.
Routes that are not open
- Direct trial with Simple Intelligence Not open yet
- Direct subscription from Simple Intelligence Not open yet
- Microsoft Marketplace Not published yet
- Sponsored subscription for member companies Not open yet
Simple Ops on the same scale as everything else here
Every Simple Intelligence product is placed on one five-stage scale, so a stage means the same thing on this page as it does on any other. Nothing here is a schedule.
-
Now
Planned
Scoped and specified. Not being built yet.
-
Not started
Building
Under active development.
-
Not started
Validation
Built, and being tested against real work before anyone outside is let in.
-
Not started
Early access
Open to a reviewed group, with onboarding run by a person.
-
Not started
Available
Open to anyone who qualifies, without waiting for a review.
Simple Ops is a decision about how these products fit together. It is not software you can buy, and there is no date.
This is where the product sits, not what you can do with it today. What you can do is the button at the top of this page, and it is worked out separately from evidence about the product rather than from this scale.
The problem this name is meant to solve.
A services organization does not experience time tracking, project delivery, pipeline, service desk, campaigns, and tenant administration as six separate concerns. It experiences them as one operation with six views into it. Sold as six products, the seams between them become the customer's problem to manage.
What was actually decided.
On 2026-07-17 the portfolio was reduced from roughly forty product ideas to roughly twelve, and six of the operational applications were grouped under the name Simple Ops. That grouping is the whole of the decision. It set a direction for how the products are organized. It did not start a build, set a date, or create anything a customer can acquire.
What that means if you are buying today.
Buy the product that solves the problem you have. Each of the six has its own page, its own way in, and its own stage of readiness, and none of them depends on Simple Ops existing. If the suite is built, the products you are already using are the ones it is built from.
The six products Simple Ops is planned to bring together.
Each one is its own product with its own page, its own way in, and its own stage. Nothing here is a bundle you buy in one go.
Simple Time
The Microsoft 365 timesheet that closes the billable-hours leak.
Trial accessSimple Projects
Project delivery that starts at the signed scope of work.
Available on requestSimple Growth
The CRM that reads your Microsoft 365 calendar, not your data entry.
Available on requestSimple Service
ITSM on Microsoft 365, without the ConnectWise tax.
Available on requestSimple Marketing
Marketing automation built for the Microsoft 365 partner channel.
Available on requestSimple Admins
Tenant administration from a Teams chat, with a seam before every write.
Coming soonWhat exists under the name Simple Ops today.
Simple Ops is a decision recorded in the portfolio log. There is no Simple Ops repository, deployment, sign-in, or schema.
Working today
- The grouping is decided and recorded, so the six products are being designed with the same conventions
- All six products underneath it are independently reachable, each with its own page and its own access path
Not yet
- There is no Simple Ops application, sign-in, tenant, or bill
- There is no cross-product single tenant or single invoice, and no work has started on one
- There is no announced date, and no date will appear here until one is approved
- Simple Ops is not the same thing as SimpleOS, which is a separate planned shell with its own page
Verified against the product on 2026-08-24.
Simple Ops and SimpleOS are not the same.
The names are close enough that treating them as interchangeable would be easy and wrong. They describe different things and neither is available.
Nothing on this list is available today. This is the product we intend to build, written down so you can tell us whether it is the right one, and it will change.
Simple Ops is the grouping
It names which products belong together and are designed to share conventions. It is an organizing decision about the portfolio.
SimpleOS is the shell
It is the planned composition experience: one place approved products can be used together. It has its own page and its own separate status.
Neither is purchasable
Both are planned. Nothing on either page can be bought, started, or signed into, and neither has an approved date.
The products are real
The six products underneath are the part that exists. What they can and cannot do today is stated on each of their own pages.
If a future version of this page describes Simple Ops as software you can run, it has drifted from what was decided.
A planned suite changes nothing about who approves what.
Every Simple Intelligence product stops at a human approval before it changes a customer system, and grouping products under one name does not create a shortcut between them.
Approvals stay per product
The approval seam in each product is the one that governs it. There is no suite-level authority that can act across products, because there is no suite.
Your data stays where it is
Each product holds its own records in its own tenant-scoped database under its own stated storage posture. No Simple Ops store exists, so nothing has been pooled.
Nothing is migrated without sign-off
If products are ever consolidated, the portfolio rules require data migration with matching row counts, verified checksums, a retained rollback database, and explicit sign-off before any cutover.
Failures escalate per product
Detection, recovery, and escalation are the responsibility of the product you are using, and are described on that product's page.
Across the portfolio
From a campaign to revenue evidence
Five products and four handoffs. Each handoff carries its own state, because they are not at the same stage and one arrow drawn across all of them would say that they are.
In sequence: Simple Marketing, then Marketing hands a qualified lead to Growth (Planned), reaching Simple Growth, then Growth hands a signed scope to Projects (Gated), reaching Simple Projects, then Projects hands delivery work to Time (Gated), reaching Simple Time, then Approved time becomes billable (Available), reaching Approved billing evidence.
-
Simple Marketing
A campaign goes out and replies come back. Everything the agent writes lands as a draft, and launch is the effect that is gated behind a person.
-
Marketing hands a qualified lead to Growth Planned
The connection is specified and the production handoff is not proven customer-ready. Treat this today as two products that a person moves work between.
Simple Growth
Sales development runs on the lead. The agent stops at the moment a real person replies, and nobody can start it running without deciding to.
-
Growth hands a signed scope to Projects Gated
The route is built and it runs inside our own tenant. There is no path across it that a customer can reach today.
Simple Projects
The signed scope becomes a plan. Everything the agent concludes about that plan arrives as a proposal with a rationale, and an administrator applies or rejects it.
-
Projects hands delivery work to Time Gated
Both sides hold the link contracts for the transfer. No paired end-to-end test proves the whole transition, so this is written as gated rather than as built.
Simple Time
Hours are drafted from work that already happened, each with a confidence score, and each employee confirms their own drafts rather than having them confirmed for them.
-
Approved time becomes billable Available
This crossing runs inside Simple Time today. It is the one step on this path a customer can use.
Approved billing evidence
Only approved time can be invoiced, and the invoice traces back to the specific entries that were approved and to the person who approved them.
This is how the path is designed and how far each crossing is built. It is not a statement that the path runs end to end for a customer today, because it does not.
The human decision in this sequence
- What a person reviews
- Two people at two different points. In Simple Projects an administrator reads each proposed change to the plan against the scope it came from. In Simple Time each employee reads their own drafted entries before anybody can bill them.
- What gets approved
- The specific proposal as it was put, and the specific time entries inside the period being approved. Approval attaches to those, not to the project or to the person in general.
- What approval makes possible
- An applied proposal changes the plan. Approved time, and only approved time, can be placed on an invoice.
- What invalidates it
- A proposal that is not applied expires rather than waiting indefinitely, and a rejected one carries the reason it was rejected. On the billing side the enforced check is the direct one: an entry that is not approved cannot reach an invoice at all.
- How failure is detected
- A crossing that does not complete leaves the record in the product it started in, where the person who owns it can see it. Nothing is marked as handed over until the receiving product has it.
- Recovery and escalation
- The owner retries the handoff from the product it started in, because an automatic retry across a boundary is how a record ends up existing twice. Escalation is to the workspace administrator on the receiving side, since that is the only role that can apply a change without the proposing agent.
The first crossing on this path is planned, so none of the detection or recovery described here runs across it yet. There is nothing to detect until there is a handoff to fail.
Planned capability
Booking to follow-up, as it is planned
Scheduling is a planned capability of Simple Ops. There is no separate scheduling product to buy and no page for one. This is the sequence the capability is being designed around.
In sequence: Booking (Planned), then Teams meeting (Planned), then Authorized transcript reference (Planned), then Draft summary (Planned), then Human approval (Planned), then Simple Growth follow-up (Planned).
-
Booking
PlannedSomeone books a time. This is the only step a person outside the organization touches.
-
Teams meeting
PlannedThe meeting runs in Microsoft Teams under the organization's own policies. Recording is never silently enabled by this capability.
-
Authorized transcript reference
PlannedWhether a transcript exists at all depends on tenant policy, consent, participant notice, permissions, and retention. What travels onward is a governed reference and its metadata rather than a copy of the meeting.
-
Draft summary
PlannedA summary is drafted from that reference. It is a draft, it is marked as one, and it is not sent anywhere.
-
Human approval
PlannedA person reads the draft and approves it, edits it, or discards it. Nothing continues past this step without that.
-
Simple Growth follow-up
PlannedSimple Growth receives governed references, metadata, and approved summaries, and uses them as context for follow-up that a person still sends.
Every step below is planned. None of it is available, and the handoff into Simple Growth at the end is the least settled part of it.
What this diagram does not say
- Recording is never silently enabled.
- Transcript access depends on tenant policy, consent, participant notice, permissions, and retention. Any of those can make a transcript unavailable, and that is a normal outcome rather than a fault.
- Raw audio is not copied into Simple Growth by default.
- Simple Growth receives governed references, metadata, and approved summaries.
- The handoff from scheduling into Simple Growth is planned. Where any part of it exists it is partial, and none of it is available.
- AI does not place calls, and it does not send follow-up without a person approving it first.
The human decision in this sequence
- What a person reviews
- A person reads the drafted summary against the meeting it came from.
- What gets approved
- That draft, in the version being read. Approving a summary is not approval of the transcript, of the recording, or of any later revision of the summary.
- What approval makes possible
- An approved summary and the governed reference beside it can be written into Simple Growth as follow-up context. Nothing is sent to the other party by this step.
- What invalidates it
- A summary edited after approval is an unapproved summary again. A transcript permission that is revoked or expires removes the reference the summary was drawn from, and an approval does not outlive the source it depended on.
- How failure is detected
- A missing transcript, a withdrawn consent, or a permission the capability no longer holds is designed to surface as a refusal that names the reason, rather than as an empty summary that looks like a quiet meeting.
- Recovery and escalation
- The meeting owner supplies notes by hand instead, or requests access again. Escalation is to the tenant administrator who controls recording and retention policy, because that is where the decision actually sits.
This approval model is designed and none of it is built. Read it as the shape the capability has to take rather than as behaviour you can rely on.
What backs the claims on this page.
The questions this page exists to answer.
Can I buy Simple Ops?
No. Nothing has been built under the name and there is nothing to purchase, trial, or sign into. The products it is planned to group are each bought on their own.
When will Simple Ops be available?
There is no date. No schedule has been approved, and a date will not appear on this page until one is.
Is Simple Ops another name for SimpleOS?
No. Simple Ops is the grouping of operational products. SimpleOS is the planned shell they would be used through. Both are planned, and they are separate.
Will the products I use today be discontinued or renamed?
Each product keeps its own page, its own URL, and its own way in. Some module names were reserved for a future suite, for example Simple Revenue for Simple Growth and Simple Tenant for Simple Admins, but no product has been renamed and none of those names is in use.
What happens to my data if the products are consolidated?
Nothing moves without a verified migration. The portfolio rules require row counts to match per table, checksums to verify, compliance ledgers to be copied in full, the source database to be retained as a rollback, and explicit sign-off before any cutover.
The rest of the portfolio.
There is nothing to start here.
Simple Ops is a plan. If one of the six products underneath solves a problem you have today, start there. If you want to be told when the suite becomes real, ask for updates.