Moxby / Team work environment
Team workspace software for people who need the discussion beside the task, not buried somewhere else. Moxby brings chat, tasks and documents into the same working context, with a separate browser assistant for work on websites.
Price basis: individual scope after discussion of your requested workspace and browser behaviour. No published rate or online payment. Any later commercial proposal uses USD.
Start with a work item that loses its context during a handoff. If it involves a website action, identify where a person needs to review the proposed change.
The work ledger / Offers
Choose the part of the work that needs help. Shared decisions belong with the team; a requested action on a website needs its own scope. These are product areas to discuss, not subscription tiers to buy.
Keep the task tied to the conversation that explains it and the document it changes. A shared workspace for teams is useful when an instruction makes sense only after someone has hunted down the discussion behind it.
Inquiry basis: individual scope after discussion of the requested workspace. Describe the work item and the handoff you need to support; no published rate or binding quote.
Discuss work beside the website a person is using. The browser assistant has its own job: support a bounded activity in that environment without treating every open page as shared team material or every request as permission to act.
Inquiry basis: individual scope after the requested browser environment and assistant behaviour are confirmed. Browser support and permissions need review before a commercial proposal.
Start with the input a person chooses and the output they need to inspect. A local workflow request identifies what happens in the user's environment and where a website or external service enters the work.
Inquiry basis: individual scope per requested local workflow and environment, confirmed after review. Local does not mean offline, and it is not a privacy guarantee.
Name the website action, the point where a person reviews it and the condition that stops it. Preparing a proposed change is a different request from submitting that change. Keep the distinction in the scope.
Inquiry basis: individual scope per requested website action, subject to permission and feasibility review. A page change or unclear result can change what is possible.
Choose by the work
The setup builder combines these areas into a request. Local workflows and Website actions bring Browser assistant into that request because their environment must be discussed too. Selecting an area does not confirm access or compatibility.
Build a setupStart with Team workspace. If the work is already clear but the explanation gets separated from it, adding browser behaviour is not the first question. Describe where the decision is made and where the next person looks for the instruction.
A useful example is a revision request that arrives in chat while the draft lives elsewhere. The inquiry can focus on keeping that relationship understandable rather than moving every conversation the team has ever had.
Start with Browser assistant when the difficulty appears while someone is using a website. State what the person needs to see or prepare beside the page. A shared workspace may provide the reason for the work, but it does not itself define permission to read or change a website.
Add Local workflows when a chosen input in the user's environment matters. Add Website actions when the request concerns a change on a named site. These choices expose questions; they do not hide them inside an all-purpose automation label.
One request can touch more than one area. It should still name the point at which the user checks the proposed output before anything with an external consequence happens.
The amount and nature of the work depend on the requested setup, not on a rate shown on this website. Workspace relationships and browser-side permissions can produce very different scopes. A later proposal in USD must identify what is included and any conditions that need agreement.
There is no checkout after the option sheet. Send the request when the summary describes your intent; do not read the selected-area count as a price, a delivery estimate or a licence entitlement.
Working pattern / An inspectable example
A team wants to revise a public information page. The wording begins in a shared discussion, becomes a task and is checked against a working document. A website change is considered only after that review.
Four editorial stages
Not a performance measure
This is an illustrative request, not a record of a customer deployment. Read it as a way to test your own setup: can the person doing the work find the reason, inspect the current text and tell where their authority ends?
The conversation supplies the reason for the change. In this example, the public page describes an old routine and the team wants the wording to match the current one. That reason should remain visible when the work leaves the original discussion.
A request such as “update the page” loses the decision that made it necessary. The useful context is narrower: which passage is wrong, what the revised wording needs to explain and which question is still open.
Revise the guidance paragraph to describe the agreed routine. Keep the unresolved wording question attached to the draft, rather than treating it as an approved instruction.
Nothing here requires handing over the team's complete conversation history. A non-sensitive account of the relevant decision is enough to explain the relationship you want a workspace to support.
Current / 01 ContextThe task turns that reason into a bounded piece of work. It names the draft to revise and the expected handoff. The person preparing the wording should not have to guess whether they are also being asked to publish it.
For this example, preparation ends with a revised passage ready for review. Publishing is outside that task. This is a boundary in the proposed routine, not a claim about a permission control in a shipping product.
Prepare a replacement paragraph in the working document and relate it to the original discussion. Leave the public page unchanged while the wording is being checked.
The task can be understood without replaying the whole chat. Its context still matters, especially if a later question changes the intended wording.
Current / 02 TaskThe working document holds the proposed text. The review compares that text with the reason for the task, rather than counting a reply such as “looks fine” as approval of whatever happens to be on screen later.
A reviewer needs to know which passage was considered. If the draft changes after that check, the earlier decision may no longer apply. The setup discussion should cover how people identify the text they mean.
Check the replacement paragraph against the agreed routine. Leave a clear decision about that passage, including whether it is ready to be prepared for the website.
Document review is not a browser permission. Agreement on wording does not, by itself, authorise an assistant to write to an external service.
Current / 03 ReviewThe browser-side request begins with a named website and a proposed change. In this example, the user wants to prepare the reviewed passage in the relevant field and stop before submission so a person can inspect it.
The website may have changed since the request was written. A missing field, a different account context or an unclear result is a reason to stop and review, not a reason to guess the next control.
Do not submit the page. If the target passage cannot be identified confidently, leave the page unchanged and ask the user to inspect the situation.
That requested boundary belongs in the inquiry. Feasibility and the user's authority to act on the site must be checked before any browser behaviour is agreed.
Current / 04 Action
What the example establishes
The route connects a reason to a piece of work, then separates approval of the content from authority to change a website. It does not establish browser compatibility, a completed integration or an automatic return of results to the workspace. Those are scope questions.
A request you can inspect / Public guidance revision
The handoff test
The hard part of a handoff is often not the text itself. It is the difference between a suggestion and a decision. A short discussion may contain both, and a copied task description can accidentally make them look equally settled.
In the example above, the revised paragraph belongs in the document because that is the text being reviewed. The conversation explains why it changed. The task defines who is expected to inspect it next and what they should be able to decide. Each has a job; none needs to impersonate the others.
This is the working pattern behind the Moxby workspace. Ask for the relationship your team needs, not a promise to move everything into a single tool. If only one recurring handoff is unclear, use that handoff as the starting scope.
A website adds a second boundary. The person who can approve a paragraph may not be the person authorised to change the public page. A team agreement does not remove a site's account restrictions, and a browser assistant should not be scoped as though it does.
That is why “prepare” and “publish” are different words in this walkthrough. The proposed routine stops at preparation. A request for a further action needs its own permissions discussion and a way to judge the result without assuming that a successful-looking screen tells the whole story.
Follow the shared-context walkthrough for document and task handoffs. The browser assistant explanation takes up the part that happens beside the active website.
A
Ask what the next person would need if they had not read the original conversation. A task title alone is rarely enough to describe a disagreement about wording. Keep the relevant decision in scope without treating the entire chat history as required input.
B
Ask which draft or passage the reviewer means. A broad approval attached to a changing document can become ambiguous. Describe the expected review routine before asking about any specific revision or notification behaviour.
C
Ask what the user is authorised to do on that site and what environment they use. A page that is visible to a person is not automatically suitable for every assistant action. Site rules and account restrictions remain part of the feasibility question.
D
Ask how the team will distinguish a proposal from a completed change. If the last visible state is a review screen, the result is still awaiting review. The wording used in a handoff should not promote an uncertain event into a confirmed outcome.
From example to inquiry
Before sending an inquiry, choose the routine that is causing the confusion. Name the working document or the kind of task, without sending its private contents. A recurring review handoff is a stronger starting point than “we need better collaboration.”
The setup builder lets you choose the product areas that touch that routine. Existing team routine and New workspace routine change the preparation guidance, not a price or an availability promise.
State where preparation ends and someone else's decision begins. If the browser is involved, identify the environment and the website action at the level needed to discuss it. Do not send sign-in details to make the example more concrete.
Uncertainty is useful information. If you do not yet know whether a step should remain manual, say so; a scope discussion can address that decision without pretending it was settled in the initial request.
An inquiry opens a discussion about the requested setup. Availability and supported behaviour must be confirmed, especially where a browser environment or external website is involved. Nothing selected in the builder is a purchased feature.
A commercial proposal comes after those questions have a defined basis. Any proposal uses USD and must state its own scope; this site supplies no rate, billing period or delivery commitment.
Agreeing a scope is different from submitting a form. The request records what you want to discuss. It does not authorise access to a device or site, create an account, or turn an illustrative example into a promised implementation.
The setup inquiry process explains safe preparation and the distinction between a request and an agreement. Use it when your example needs more explanation than the option sheet can carry.
A useful fit
You can start with the workspace alone. A browser assistant is a separate area to add when the work actually reaches the browser.
A different requirement
No migration promise is needed to have a useful discussion. Keep the existing tools in your description and identify the relationship that needs work.
The next move
Build a setup around the work you recognised in this example. The live summary makes the selected areas and their questions visible before you send anything. You can change your choices without committing to an order.
Build a setupContact / Start with the work
A short description of the current routine is enough to start. Tell Moxby what should stay connected or what you want help doing beside a website. The request is not an order.
For access, correction or deletion of information you have sent, use Data requests. You do not need to describe a product setup to ask about your data.
Choose the main area and explain the intended result. If your request spans several areas, the setup builder can produce a summary first. Neither route calculates a price or reserves product access.
Provide a phone number or an email address so there is a way to reply. Each is optional on its own; at least one is needed. An address is not required for a software inquiry.
“Our reviewer gets a task but has to find the discussion before checking the draft. We want the task to lead back to the decision about the wording.” This is an example of scope, not a customer quotation.
“The user should prepare a proposed change beside a named website, inspect it, and stop before submission.” Add the browser environment you use. Do not assume the request implies support for that environment.