Deals and inquiries
A deal (or inquiry) is a specific customer process that you drive toward a result: a sale, a service request, a legal case, a recruiting search. The deal card gathers the client, the owner, the amount or value, the due date, the next step, tasks, documents, and history all in one place. When deals are run honestly, the manager sees the real picture of the pipeline rather than a tidy-looking board.
Deals live in the Deals and inquiries section (/crm/opportunities; /crm leads here as well).
Two board views
You can work with deals in two modes:
- List - a table of deals with columns (name, client, pipeline, stage, amount, source, contacts, links). Good for control, search, and bulk actions, including across all pipelines at once.
- Kanban - columns by the stages of the selected pipeline. Kanban is available when a specific pipeline is selected; for the "all pipelines" mode the system switches to the list. Good for seeing the flow of work and bottlenecks.
The chosen view is saved per pipeline, so you can look at each process in the most convenient form.
How to find the deals you need
The top panel offers search and filters:
- search by deal name and data;
- filter by owner, pipeline, stage, status, source, and type;
- quick filters: all, mine, open, overdue, due today, upcoming, unread, and a saved custom slice.
The filters you choose are remembered for each pipeline separately: switching between pipelines does not reset the slice you set up, and when you return to a pipeline you see it again. This is handy when different processes have different working slices.
When there are many pipelines, some chips move under “More N”. Open it and type a name into “Search pipelines”: the search covers every pipeline, including chips already visible in the row. The selected and recently opened pipelines stay in the top row; on a narrow screen the row shows fewer chips, while the rest remain available from this menu.
A separate attention filter gathers the deals that need action: those that require a reaction, overdue, due today, upcoming, unread. You can view it across "All" (the whole team) or "Mine." This is a working tool for the manager and the operator: start the day not by scrolling through the whole board, but with what actually needs attention.
The quick-filter menu also has two signal modes: "Needs attention" (for the whole team or just yours) and "No signals." The separate "My signals" and "No signals" choices keep the team queue distinct from your own. If you combine an attention reason, owner, or urgency sorting, the menu shows "Custom" — the filters are still active; they simply form a combination you can inspect or change.
"Assigned to me": don't miss handed-over work
When a deal is assigned to you, the portal doesn't wait for you to find it on the board yourself. The assignment is visible right away from three angles:
- A pop-up notification shows exactly who made you the owner — with an avatar and the deal name. It arrives in real time while the portal is open.
- A "Assigned to you" marker stays on the list row and on the Kanban card. It holds until you open the deal: opening it clears the marker, so you see exactly what you haven't dealt with yet.
- The top panel has an "Assigned to me" chip. It opens the list of new assignments and doesn't depend on whether those deals are loaded into the current list or filter — that is, it collects assignments across the whole pipeline, not just the ones currently visible on screen.
Each employee sees only their own assignments. This is a working tool to keep handed-over work from getting lost between people: you receive a deal, open it, see the context, and set the next step. For a manager it's a safeguard that an assignment really reached the owner rather than going unnoticed in the general flow.
What the deal card shows
On the board and in the list, the essentials of a deal are visible:
- the deal name;
- the client, company, and contact, sometimes with a decision-maker marker;
- the deal owner;
- the amount or value and the probability;
- the stage and pipeline;
- the expected close date and the next step;
- attention and priority markers: overdue, due today, unread.
In a normal board response, Kanban columns also show a per-stage summary: the number of deals and the total amount. During text search or when totals are incomplete, the count and amount may be unknown; visible cards then represent only the filtered result, and a missing summary does not mean a zero pipeline.
Changing a deal owner is guarded by permissions and the card's current revision. If you lack transfer rights, the selected person cannot own the deal, or the card changed meanwhile, saving is rejected with an explanation: request access, choose another person, or refresh the card and try again.
How to create a deal
Creation opens with the new deal button. The current form is a single column with the fields defined by the pipeline; the set of fields depends on the process. There is no separate readiness panel on the right—when a required field or rule blocks saving, the form explains it next to the field or action.
The order:
- Choose the right pipeline - it determines the set of fields and stages.
- Fill in the required fields; follow the inline message beside a field or action if it blocks saving.
- Specify the client, contact, owner, amount or value, expected due date, and next step.
- Use the primary create action. Additional choices, including Create and add another, are in the More menu; open the new deal after saving when needed.
In a multiple-choice field, each option appears as its own checkbox; select every value that applies, and a normal click toggles only that option—Ctrl/Cmd is not required. If the schema offers no choices, the field says that no choices are available; this is not a save error. If a value saved earlier is no longer offered, it remains visible and checked until you deliberately clear it.
Links and correspondence can be added after creation: they become available once the deal already exists.
How to run a deal through its stages
The stage must reflect the actual state of the work, not a wish to tidy up the board. Do not move a deal forward just because it looks neater that way.
Deal fields fall into system fields (name, amount, currency, owner, client, legal entity, stage, pipeline, status, probability, next step, expected close, source) and the fields a pipeline added for its own process.
After every significant event, update the stage and the next step and leave a clear comment. A deal without a next step is a signal that the work may stall.
Separate from moving through stages, an inquiry has its own lifecycle actions only in a list row and in the open card, not in Kanban. For an open inquiry that is not yet yours, Take is directly in the row; the other actions are under More. Hand over opens an employee picker and stays unavailable with a clear reason while the roster has not loaded. Close offers only Won or Lost; it does not ask for a free-text reason — a reason belongs to the final-stage transition described below. On a closed inquiry, Take, Hand over and Close disappear and Reopen is available instead.
The portal response is authoritative: a refusal stays next to the inquiry, and any possible paths it lists are explanatory text, not extra buttons. A “nothing changed” notice is not success; refresh the list or card and check the actual owner and status before taking the next step.
If the connection drops or the tab sleeps and no portal response was received, the outcome is unknown. Do not refresh or choose another employee or outcome: when connected again, repeat the identical action once in the same open page and verify the owner and status. A refusal that was shown is already a portal answer; correct its cause or request access before making a new decision.
Closing a deal with an outcome
When a deal reaches its final stage, the system asks you to record the outcome: Won, Lost, or another result. This is not a formality but data for pipeline analysis.
- The final stage may require a closing reason - without it, the transition will not go through. State the real reason, not the first one at hand: it is from these reasons that you later see the true conversion rate and the typical losses.
- After closing, a deal may become read-only. This protects the record of the result from accidental changes.
After closing, the card keeps an outcome summary — a permanent read-only panel: Won or Lost, the close date, who closed the deal ("Closed by" with the person's name), and the recorded reason. If no reason was given, the summary says so plainly — "not specified." This is a visible signal that the loss data is incomplete, and it's seen right away, without a separate report.
The same outcome lands in the activity feed as its own line, labeled "Close reason" and with a clear outcome status (Won, Lost, reopened) rather than a technical code. That way a manager reads the outcome and its reason right in the deal's history.
If the transition is blocked by a guard check
Moving to a stage or closing a deal may not go through: the process requires a condition to be met. The block explains what is wrong, and it is worth reading in full.
Distinguish three different causes. If you do not have permission to change the stage, request access to the pipeline or stage. If an automation process supplied invalid data for the stage change, the automation owner must fix the rule or its inputs — this is not a user-permission denial. If someone changed the card at the same time, refresh it and retry against the current state.
There can be several reasons at once. The message lists every unmet condition - each on its own line, not just the first. If you fix one line and immediately retry, the transition fails again, and it looks as if "the error will not go away". Go through the whole list before trying again.
The form helps you find the spot. When a condition concerns a specific field, the card scrolls to it and highlights it - no need to hunt through the whole form.
The highlight does not cover everything. The close reason is filled in the stage-change block, and the card does not scroll to it. If the message is about the close reason, look for it there yourself.
What to do:
- Read the message to the end and note down every reason line.
- Fix them all: fill in the fields, complete the required steps, add the data.
- Retry the transition.
- If the block persists after your fix, check whether a new line has appeared in the message - conditions can be checked in a chain.
The deal card at work
An open deal is a workspace, not just a record. The card brings together tabs for everything related to the deal:
- Deal - fields, stage, amount, participants, the next step;
- Tasks - tasks for the deal, with the option to set a new one from context;
- Files - the deal's materials;
- Documents - contracts, invoices, and other documents;
- Calendar - meetings, events, and reminders for the deal.
The calendar tab has a reminder switch with counters: "Reminders: active", "Reminders: completed", "Reminders: all".
By default only active reminders are shown. As soon as a reminder is completed or cancelled, it disappears from view - this is not data loss. To see it again, switch to "completed" or "all".
The switch affects reminders only. Task due dates and work plans are always visible in the calendar, whatever position it is in.
From the card you can reach an actions menu: set a task, add a reminder, create a workgroup or a client project, send an email to the client, call the client (when telephony is connected and voice eligibility permits the selected purpose), or run a robot rule. This lets you carry out work on the deal without leaving for other modules.
From the deal card, open the Actions menu and choose a manual rule that applies to this deal. Read the preview first: it shows the action count and how many actions will execute, be queued, or be skipped. Run the rule only after reviewing the preview. Permissions or conditions may leave the run blocked or denied; fix preview errors before running it.
Creating a client project opens a separate modal: the client root must be available, the name is required, and you should review the project kind, owner, and tag list before creating it. If the client root, permission, or required field is missing, the button is disabled and explains why. After creation, the portal may fail to link the project to the deal immediately; use the recovery link to check both cards instead of blindly creating a duplicate.
Creating a related deal or inquiry also opens a separate modal. The portal inherits the client, context, and available pipeline; you provide the name, next step, and owner. Missing permission or a required field blocks creation. After creation, the spawned_from link may be only partially saved, so use the recovery link and check both deals if an error appears.
In the email window, choose the sender mailbox; the recipient is taken from the deal contact's work email. Fill in the subject and body before sending. If validation or provider handling fails, correct the data and check the mailbox instead of blindly retrying. Use a synthetic contact for testing and do not send without a confirmed recipient.
The activity feed and history show what happened with the deal: stage changes, new tasks, emails, comments. Use the feed as a trail of agreements: a decision should be visible in the card, not only in private correspondence.
In the deal activity feed, switch among All, Communications, Tasks, Documents, Commercial, Automation, and Changes. Each tab supports the All, Unread, and Mine scopes, plus filters for date range and overdue items, closed/resolved and snoozed events, event type, source, visibility, and actor. Reset restores the default view. Bulk resolve is available only with the required permission; if some operations fail, review the partial-error list and retry only after fixing the reported causes.
When a comment is deleted, it should also disappear from an already open feed without a page reload. If the row remains visible, do not repeat the comment or make a decision from its text: refresh the feed and check the opportunity's current context.
For a recent comment of your own, the … menu offers Edit and Delete; Delete asks for confirmation. Those commands are unavailable for someone else's comment, after 30 minutes, or without permission. They change the record: review the text and context first; if no clear recovery message appears, do not repeat the action—ask the portal owner.
The card menu now offers “Create order” only when the pipeline allows conversion to an order and the inquiry has a company. If the pipeline purpose does not allow conversion or the company is missing, the disabled item explains the reason; do not bypass it with a direct URL. After creation, the fact may not arrive in the feed immediately: an empty feed straight after submission does not prove failure and is not a reason to create the same order again. When the entry appears, it says that the order was created and offers an Open order link. There is no separate retry for fact delivery: wait, refresh the feed, or open the order from the link. For documentation use only synthetic Rebranding — demo (CRM opportunity) and Demo Client North, with no actions or real data.
The CRM reply queue collects items that need a required email reply or a callback after a missed call. Each item shows open, snoozed, or resolved state, SLA (pending or breached), priority, due date, and assignee. Allowed actions depend on your permissions: assign or unassign, snooze, resolve, reopen, and view history. Mailbox and telephony remain source details; the queue does not replace their histories.
If you start writing a comment and get interrupted, the text draft and attached files survive navigation between screens and a page reload. When you return to the deal, review the restored draft and attachments before continuing or sending it. A successfully sent comment clears the draft.
Inquiry followers: track a deal without owning it
Sometimes a deal needs to be tracked by someone who does not run it and is not responsible for the result: a department head, an expert, an adjacent operator. That is what followers are for — people who receive notifications about an inquiry's events but do not become the owner and do not gain access to the client's other deals.
A follower is neither the owner nor a co-assignee: they do not move the deal or answer for it, they simply stay in the loop. The role is similar to a task watcher: a follower receives notifications about the deal's events but does not take part in the work and gains no rights to change it.
Follow management is gathered in the deal card:
- The "Follow" button in the card header. Click it to subscribe yourself: the button becomes "Following." This is available even to those whose access to the deal is read-only — following grants no editing rights. Clicking again unsubscribes.
- The list of followers next to the button shows who is already tracking the deal. Anyone with management rights can add or remove others through the employee search; everyone else sees the list and can only unsubscribe themselves.
- A marker on the card and in the list shows the number of followers. If you are among them, the marker is highlighted — so you can see at a glance which deals you are following.
- A notification reaches the person who was subscribed: "so-and-so subscribed you to an appeal." When you subscribe yourself, no extra notification is created.
A follower receives notifications about the significant events of this particular deal: a new message and comment, a stage change, field changes. At the same time, following does not open access to the client's other deals.
When to use it. Add as a follower someone who needs to stay informed but does not run the deal: a manager keeping an eye on a large deal, an expert on part of the work, or an adjacent operator. Following keeps a person in context without blurring responsibility: there is still a single owner.
What to avoid. Don't use following as a substitute for assigning an owner — tracking a deal is not the same as running it. Don't add everyone as a follower "for show": every follower gets notifications, and superfluous follows turn into noise. If a person should genuinely work on the deal, give them a role, not a follow.
Amount, value, and probability
A deal carries not only a name but also measurable indicators:
- amount or value - how much the result is worth; several currencies are supported, so check that the right one is set;
- probability - an estimate of the chance of success; it helps build the pipeline forecast;
- expected close date - when the result is planned;
- next step - exactly what to do next.
Stage summaries do not add amounts in different currencies into one number. If a selection contains RUB, USD, and EUR, the portal shows separate totals for each currency; do not read the list as one unified budget or convert it by eye. An empty or permission-hidden amount is not zero: check the filter, access, and deal currency, then confirm the total with the pipeline owner.
These indicators are not for show but for forecasting: from them a manager sees how much money is really in progress and which deals need attention. Do not leave amount and probability as rough guesses if a plan is built on them.
The deal card's Money tab shows three landmarks—deal amount, received, and planned—plus separate payment and budget lists. You can add a payment or budget there; deletion requires confirmation. The form takes its currency from the deal, defaults the payment date to today, and formats amounts for the selected locale. Row dates are produced by the browser engine, and a native field can follow its settings, so the portal locale alone does not prove a date format; record the browser language in evidence as well. For KK/KY, do not use a row date as localization evidence until its display is corrected. If receipts use different currencies, the remaining-to-receive value is not calculated because this tab does not convert currencies. This is money for one deal, not the Operations prepayment or invoice register; use synthetic data for screenshots/evidence and record currency.expected/currency.observed.
The labels follow the pipeline's declared purpose: a service-purpose pipeline speaks of a request or case, while a commercial pipeline speaks of a deal. For a reproducible check, use the same synthetic entities Delivery window — demo for the service request and Rebranding — demo for the commercial deal; do not infer the purpose from the tab title alone.
For a service request, the card currently does not show the linked service, client entitlement, remaining balance, or SLA, even when those links are stored on the server. Do not treat missing fields as proof that the service is not connected or the balance is zero; until a dedicated block exists, verify this context in Operations. Delivery window — demo is only a synthetic fixture for checking this limitation, and the UI contract remains source-blocked.
Related deals
Deals can be linked to one another: as parent and child, or simply as related. This helps you avoid losing context when one deal grows into several directions, or when a large piece of work is split into parts.
Link deals deliberately: a link should help you understand a dependency or a continuation of work, not just lengthen a list. If a deal has produced a standalone result, create a child or related deal rather than blurring the original one.
Removing a link opens a separate confirmation showing the link title and type. Check the target before confirming; cancelling is safe, and there is no reason to click again. Do not confirm the deletion in a capture or test.
Bulk actions
In the list you can select several deals and apply the same action, for example archiving. If the action did not apply to all of them (a partial result), handle the remaining ones separately rather than repeating the bulk operation blindly: some deals may have failed because of permissions, status, or a protective check.
Manager control
Regularly check, via the board and the attention filter:
- deals without a next step;
- stuck stages where work has stopped;
- deals without an owner;
- overdue deals and customer tasks;
- deals closed without a clear reason.
If the board stops reflecting reality, fix the process and the data first, not the report. The board is useful exactly as far as it can be trusted.
States you may see
- access to the module or the deal is denied by permissions;
- the board or list is empty, or Kanban requires you to select a pipeline first;
- a deal in a final or protected stage is read-only;
- a transition between stages is blocked by a protective check - the message lists every unmet condition, meet them all and retry;
- the calendar shows only active reminders - completed ones are available in the neighbouring switch position;
- completion requires an outcome and a closing reason;
- a bulk action completed partially;
- an export is running or has failed.
Good practices
- Create the deal in the right pipeline; it determines the fields and stages.
- Before saving, check the inline messages beside required fields and the action button; the form names the reason where the block occurs.
- Every deal should have an owner and a next step.
- Move a stage only after a real change in the state of the work.
- When closing, record an honest outcome and reason.
- Begin control with the attention filter, not by scrolling through the whole board.
Common mistakes
Moving a deal through stages just to keep the board tidy. The board stops reflecting the real work, and the forecast becomes false.
Leaving a deal without a next step. The work quietly stops, and no one notices in time.
Closing a deal without a reason. The team loses the data on why it lost and never learns from it.
Running several processes in one pipeline. The stages become unclear, and the CRM turns into an arbitrary list.
Repeating a bulk action blindly after a partial result. Some deals will fail again, and the cause will remain unexamined.
Fixing only the first line in a block message. Usually several reasons are listed; the transition fails again, and the time goes into repeated attempts instead of reading the whole list.
Deciding that a completed reminder has disappeared. The deal calendar shows only active reminders by default - the switch brings back the completed ones.
How to verify the result
- the deal is created in the right pipeline, with the required fields filled in;
- the client, owner, amount, due date, and next step are visible;
- the stage matches the real state of the work;
- a closed deal has an outcome and a reason;
- the attention filter shows no forgotten overdue deals left without action.
Related scenarios