Understand your work OS
A colleague leaves. Your customer relationships continue.
Keep the exchanges received by your OS, commitments and open questions with the customer record. Assign the work to the next person, with the access they need to take over.
Your team and customers have different access.
Sharing your customer application does not open internal records. The responsibilities, collaboration and permissions described here organise the team’s work within its own scope. A complete employee workspace is separate from the customer base application.
Everyday work
Hand over the work. Not hours of reconstruction.
When someone leaves, their replacement should not have to ask customers what your company promised. Information captured from connected exchanges is already part of the available work history. The handover can build on that history, with missing details still to clarify.
Léa leaves. Alex takes over Marc’s case.
01Before the departureThe relationship already has a history.
What did Marc ask Léa?
Marc asked what maintenance includes. Léa promised a written explanation before he decides. The available exchanges retain both the question and the commitment.
The history uses content received by the OS; missing conversations still need clarification.
02Organize the handoverChange responsibility. Review access.
Who will follow Marc after Léa leaves?
The manager assigns the case to Alex and reviews the permitted scope. Departing-user access is withdrawn through the relevant administration procedures, separately from assigning the case.
Assignment, collaboration access and assistant connections require their respective controls.
03The new colleague startsPick up the promise, with the right method.
“What did we promise Marc, and which procedure should I follow?”
Marc is waiting for the maintenance explanation. Review the applicable terms in the shared team knowledge, then prepare the written reply. His acceptance is still pending.
Alex uses the web or a compatible assistant with his own identity and permissions.
Fictional example, not a product screenshot. Sources and access require configuration; illustrated answers use the information shown.
People change. The work can continue.
The new colleague finds the available customer history and approved team knowledge in the permitted scope. Withdrawing OS access restricts future access; it does not erase information already read, exported or retained in an assistant conversation.
Explore the history behind a customer relationshipOn this page
Distinguish ownership from collaboration
Shared memory does not erase responsibility for follow-up. The primary owner carries the relationship or next action; other colleagues can help without taking their place.
The existing AlefOS team model organizes this access. The term Team in technical contracts describes this operating scope; it is not a new commercial offer to subscribe to from this page.
Company queue and primary owner
New, released or unassigned work can remain in a visible queue within the authorized scope. Returning a contact, mission or appointment to this queue removes its individual assignment without deleting its context.
A primary owner identifies the person responsible for the relationship or next action. Assignment, reassignment and takeover must be explicit. A collaborator does not automatically become the owner.
Viewer and contributor
A viewer reads only the sections they are granted. A contributor can help within authorized sections. These roles are separate from primary ownership.
For example, someone can contribute notes to a file without access to every private conversation, identity detail or other protected section.
Duration, revocation and traceability
Collaboration access can have an expiry date and can be revoked. Assignments, role changes, access changes and revocations are recorded.
Company membership does not make all data visible. Permissions remain limited to the context and sections actually granted.
Contacts, missions and calendar
A contact retains the relationship owner and collaborators. A mission has an execution owner or returns to the queue. An appointment keeps a visible owner together with customer context and linked missions.
This model follows responsibility from the relationship to the next action. Available tools and authorized roles must be checked for each object.
Work through an assistant
An authorized colleague can ask who owns a file, consult their scope or use an available assignment workflow. The same permissions and records apply as in other interfaces.
The assistant does not act as an unrestricted collective identity or impersonate a team member. Three questions must remain clear: who is responsible, who can help and what can each person access?
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.
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. |
Missions and responsibility
Read the source and execution state before acting. Confirming executes a pending mission; rejecting and archiving have different effects. Assignment follows company roles.
Scroll the table to read every column. With a keyboard, use the left and right arrow keys.
| Tool | Function and effect |
|---|---|
missions. | List the current user’s missions, optionally grouped by contact. |
missions. | Read a mission’s source, related objects and execution state. |
missions. | Confirm and execute a pending mission. |
missions. | Reject a pending mission without executing it. |
missions. | Archive a mission without executing or deleting its action. |
missions. | Assign from the company queue or reassign with the required role; changes are audited. |
Calendar and booking context
An invitation, a booking link and a confirmed event are not the same state. Draft tools support review; authorized internal calendar operations can also run directly, according to the deployed tool policy.
Scroll the table to read every column. With a keyboard, use the left and right arrow keys.
| Tool | Function and effect |
|---|---|
calendar. | List appointments, optionally filtered by date range. |
calendar. | Read an event’s available owner, contact, mission and provider context. |
calendar. | Prepare an event creation preview with an action_id. |
calendar. | Prepare an update or move preview for an existing event. |
calendar. | Assign or reassign an event with the required company role and audit trail. |
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 ↗