Everyday work
Customer follow-up: preserve the promise and its reason
A useful reminder states who expects what, why, from whom and by when. AlefOS keeps those details with the relationship.
A contextual enquiry, then organised follow-up.
The customer application can send the need and contact details to the company. The follow-up described on this page adds commitments, responsibilities and actions from the selected internal functions. Receiving an enquiry and completing its next step are different stages.
Workflow example
A concrete workflow, from the signal to the next step
A customer requests a quote and promises a document.
The document is still missing; the mission keeps the reason and owner.
A colleague reviews earlier reminders before preparing the next one.
The authorized action is checked and its result recorded.
Fictional illustration. Available capabilities, sources and access depend on your environment; conditions are explained below.
On this page
- The problem is the missing story
- Make the follow-up actionable
- Signals exist in everyday work
- Review before preparing a response
- Complete example: permission before an intervention
- Responsibility and continuity
- Controlled preparation and execution
- Quote, document or callback: find the dependency
- Tools and prerequisites
The problem is the missing story
This workflow concerns professionals and teams whose customer relationships depend on calls, messages, meetings, documents and repeated follow-ups: sales, service, real estate, consulting, field work or case management.
A quote promised over the phone, a document requested through WhatsApp or a group decision may remain in its original channel. A few days later the reminder still exists, but the person must reconstruct the reason to act.
Make the follow-up actionable
“Send the proposal” becomes “send the revised version requested on Tuesday, with the reduced installation scope and expected pricing clarification”. “Call on Friday” should explain what the customer needed to review before the call.
The mission preserves the contact, context, relevant offer or document, responsible person, date and any approval. It is more than a task label.
Signals exist in everyday work
A call brings a callback request. A message confirms a date or raises an objection. A meeting assigns responsibility. An appointment creates preparation; a group shares an instruction; an intervention reveals the need for a second visit.
Sources must be connected or entered through an authorized workflow. Not every signal automatically becomes a mission, and the OS must not invent content from an inaccessible channel.
Review before preparing a response
Retrieve recent useful exchanges, promises, objections that remain valid, received documents and missing ones. Ask the assistant about the situation before preparing a message, call or next appointment.
The draft uses authorized context and confirmed business information. The recipient, commitments and documents to share still need checking in the sending workflow.
Complete example: permission before an intervention
The customer requests work at a hotel. The exchange establishes that signed access permission is missing. The mission links that document to the contact, proposed date and person responsible for following up.
A draft recalls the outstanding document and the reason for the request. After approval and the sending result, follow-up remains open while the dependency is unresolved. Receiving the document does not validate its legal effect.
Responsibility and continuity
Employees see their commitments; managers retrieve delays and decisions within their scope; the company keeps memory of its promises. Reassignment should transfer the reason for follow-up, not only its title.
Groups can hold shared procedures and authorized coordination points. Customers should not have to repeat their whole story because a file changes hands.
Controlled preparation and execution
The workflow distinguishes a prepared action, required approval, execution and result. A provider failure must not be shown as a delivered message. A closed mission does not by itself prove the customer received a document.
The OS supports the relationship without replacing the professional or guaranteeing a response or sales outcome. Source, role and availability limits remain real.
Quote, document or callback: find the dependency
A quote waits for a validated price; do not promise it before approval. A document request waits for the person who holds the document; check the last reminder. A callback waits for a supplier response; keep that dependency with the mission. In each case, review the proposed action and record the actual outcome.
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. |
IBOX messages
A stored message, an external notification and a read receipt are different states. A temporary /m/:token link grants access to its message; keep that link private.
Scroll the table to read every column. With a keyboard, use the left and right arrow keys.
| Tool | Function and effect |
|---|---|
ibox. | List IBOX messages visible to the current user. |
ibox. | Read one accessible IBOX message. |
ibox. | Record a message as read. This does not send a reply. |
messages. | Prepare an outbound message preview with an action_id for confirmation. |
actions. | Execute previously prepared work identified by action_id after confirmation. |
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
This workflow uses capabilities configured in your company’s environment, under your brand. Your team can use a compatible assistant to consult authorized context through its configured MCP connection. Understand your AI connection ↗