• Series voir-pages
  • page 07 / 26
  • department 1 of 8
  • implemented 0 stages

Sales is not “call and persuade”. It is five funnel stages, a loss branch and a return loop.

The sales department in VOIR AI is built as a funnel: an inbound lead moves down five stages — inquiry, qualification, demo, offer, close. Every stage has two side paths: a loss branch where a lead that failed the step goes, with the reason recorded, and a follow-up loop that picks up the stalled ones and returns them with another touch. Below is the honest picture: what the department should do according to the target architecture, where leads come from (the marketing department), what already runs inside the Marisova ecosystem as our own tooling, and how the department fits into the AI CEO cycle.

VOIR AI product · zero stages implemented Marisova ecosystem · internal request loop

See the department funnel Honest statuses

Demonstration · department funnel

One lead, five stages, two side paths

A funnel without a loss branch turns into a pretty picture where every lead reaches the close. The real shape is different. At each stage some requests go sideways — into a refusal with the reason recorded; some stall between touches, and the follow-up loop picks them up and returns them to the stage with another contact. Below is the same structure that is described in text in the “Five stages” section.

Structural numbers of the page: 5 funnel stages, 5 touches in the target sequence, 8 departments in the architecture, 0 stages implemented in the product.

Funnel · lead → stages → branch and loop → close

Demonstration · prepared scenario
INQ QLF DMO OFR CLS Inquiry Qualification Solution demo Offer and negotiation Close and payment demo: 0 demo: 0 demo: 0 demo: 0 demo: 0 LOSS BRANCH FOLLOW-UP LOOP IN Inbound lead CLS Deal closed LOSS Refusal · branch STATIC DIAGRAM · motion off
  1. INAn inbound lead enters the funnel from any source: a site form, an email, a request passed on by marketing or by support. Sources are not mixed — the lead card records where it came from.
  2. INQThe inquiry stage: the lead card is created, the first reply is prepared, and the task is written in the customer's own words rather than in our internal categories.
  3. QLFThe qualification stage: a check against criteria fixed before the work starts — budget, authority, need, timing. The verdict names a source for every fact.
  4. DMOThe demo stage: a script built for the specific task, materials, and a demo record with the customer's questions and our answers.
  5. OFRThe offer stage: a draft proposal, variants of terms, a calculation. Sending anything externally happens only after the owner confirms it.
  6. CLSThe close stage: a record of the agreements, payment control, handover to finance and a report to the owner.
  7. LOSSThe refusal branch: a lead that failed a stage goes sideways with the reason recorded. The reason is mandatory — without it the funnel cannot be improved, only recounted.
  8. FUThe follow-up loop: a stalled lead is picked up on the touch schedule and returned to the stage by another contact. The loop is finite: after the set number of touches the lead goes to the branch instead of spinning forever.
  9. OUTThe report to the owner: what moved through the funnel, what went to refusal and why, which decisions stayed with a human, what changes in the next cycle.

The demonstration runs a prepared scenario and is not connected to a live AI service. The “demo” counters next to the stages count only the dots of that scenario: in the static frame and with animation off they are zero. This is not a conversion, not a forecast and not data about real sales — the project has no sales.

Target architecture

Five stages: input, work, output, artefact

A stage is not “a sales phase in general” but a contract: what comes in, what is done, what comes out and which artefact remains after the step. A stage without an artefact cannot be checked independently, and therefore cannot be improved. All five stages on this page carry the same status: they are not implemented in the VOIR AI product.

INQ 01 / 05
Target architecture

Inquiry

  • inputa request from any source: a form, an email, a lead from marketing, context from support
  • outputa lead card created, the source recorded, a first reply prepared

The first stage is responsible not for “replying fast” but for making sure the request is neither lost nor misunderstood. The task is written in the customer's words: if we translate it into our categories immediately, the qualification step then checks our guess rather than the real need.

artefactlead card: source, the task in the customer's own words, time of the request, the owner of the step

QLF 02 / 05
Target architecture

Qualification

  • inputthe lead card and the criteria fixed before work with this lead began
  • outputa verdict: into work, into the follow-up loop, or into the loss branch — with a reason

Qualification without criteria fixed in advance turns into fitting the answer to the question: a “promising” lead gets judged by the tone of the correspondence. That is why the criteria are declared before the start, and every fact in the verdict has a source. When data is missing, the mark is “no data”, not a plausible estimate.

artefacta qualification scoring model and a verdict with sources for the facts; the refusal reason if the lead goes to the branch

DMO 03 / 05
Target architecture

Solution demo

  • inputa qualified lead, its task and constraints, product data
  • outputa demonstration delivered, a demo record with the customer's questions and our answers

The demonstration is assembled for a specific task instead of “showing everything we can do”. A separate rule of this stage is not to show what the product does not have: capabilities that do not exist are marked as target architecture during the demo, not discovered after signing.

artefacta demo script for the customer's task, presentation materials, a demo record with questions and honest marks about what is not implemented

OFR 04 / 05
Target architecture

Offer and negotiation

  • inputthe demo record and terms agreed with product and finance
  • outputa draft offer and calculation handed to the owner for confirmation

The stage prepares variants but promises nothing: a discount, a deadline, a scope of work, payment terms are financial and product decisions the department does not take on its own. The draft goes to the owner and a human makes the final call. Until that point the lead receives no external commitment on behalf of the company.

artefacta draft proposal, variants of terms, a cost calculation, a mark showing that a human confirmed it

CLS 05 / 05
Target architecture

Close and payment

  • inputthe offer and agreements confirmed by the owner
  • outputa deal record, data passed to finance, a report to the owner

Closing is not “getting paid” but passing on exactly what was promised: scope, timing, terms, constraints. If the deal record differs from the draft offer, the difference is recorded explicitly. The sales department does not declare a deal closed until payment is confirmed by the finance loop.

artefacta deal record with terms and constraints, an entry about the handover to finance, a line in the report to the owner

The return loop

The touch sequence: what happens between stages

Leads stall not because they lost interest but because the next step was never scheduled. The follow-up loop on the diagram is a touch calendar: every touch has a deadline, content and an owner of the step. Below is the target architecture of the sequence; each touch is prepared by the department and goes out only after a human confirms it.

T+0

Reply to the request

Confirm receipt, record the task in the customer's words, ask which format of the next step is convenient. No promises about timing or terms.

step owner: INQ stage · artefact: lead card

T+1

Clarifying the task

Clarifying questions along the qualification criteria: budget, authority, need, timing. The answers go into the scoring model with a source for each.

step owner: QLF stage · artefact: qualification verdict

T+3

Solution demonstration

A show built for the customer's specific task, not a generic product tour. Capabilities that are not implemented are marked as target architecture during the demo.

step owner: DMO stage · artefact: demo record

T+7

Offer and terms

A draft proposal and a calculation. Sending it externally happens only after the owner confirms; until then the lead receives no commitments.

step owner: OFR stage · artefact: draft offer

T+14

Control touch

The last step of the loop: a decision was made, more material is needed, or the lead goes to the loss branch with the reason recorded. There are no endless reminders.

step owner: FU loop · artefact: entry closing the loop

The T+0 … T+14 deadlines are parameters of the target architecture, not statistics: they set the rhythm in which a lead is never left without a next step. The project has no real data about which deadlines work better, because there have been no sales, and we are not going to invent an “average deal cycle”. How the department gets leads at its input is described on the AI Marketing page, which also states honestly that the GTM pipeline runs in dry-run and real sends are blocked by a hard gate.

Qualification

The scoring model: criteria are declared before the start

Qualification is the most vulnerable stage of the funnel: this is where it is easiest to “draw in” a lead's promise. So the model works the other way round: the criteria are fixed before work with the lead begins, every fact has a source, and missing data is a verdict of its own rather than a reason to score “by feel”.

Qualification criteria of the target architecture. There are deliberately no weights or point thresholds: without deal history any score would be an invented number.
Criterion What we check Source of the fact If there is no data
B · Budget Whether the customer has a budget for the task and whether it is approved inside their company. We check existence, not size: a size without the task context decides nothing. the customer's direct answer; an entry in the lead card mark “no data” — the lead stays in work and the question moves to the next touch
A · Authority Whether the person we talk to decides, or prepares the decision for whoever does. Without this the offer goes to the wrong place and the deal stalls at the OFR stage. the customer's direct answer; the list of demo participants FU loop — a touch asking to clarify the role and who takes the decision
N · Need Whether the customer's task matches what the product does or will do. A task of “solve everything” cannot be qualified: there is no readiness criterion. the task in the customer's words; product card data LOSS branch — reason “task outside the product area”, the lead is passed back to marketing
T · Timing Whether the task has a deadline and what happens if the deadline slips. No deadline is not a refusal but a signal that the lead is not ready for the demo stage yet. the customer's direct answer; a link to their internal event FU loop — a control touch on schedule, without pressure
F · Fit Whether the request is compatible with our limits: we do not take tasks that would require promising unimplemented capabilities or working without acceptance. the department's limits (the “Hard limits” section); platform data LOSS branch — the reason is recorded and the decision is escalated to the owner

Statuses

The honest matrix: product and ecosystem are different things

The most common mistake on pages like this is presenting an internal working tool as if it were a product capability. We keep two columns apart. The first: what is implemented in the VOIR AI product (right now — not a single funnel stage). The second: what already runs inside the Marisova ecosystem as our own tools. The second column is not for sale and is not provided to customers.

Status of the sales department's functions as of 2 November 2026. Verified against the code, the configuration and live URLs — not against plans.
Function In the VOIR AI product In the Marisova ecosystem (internal)
Taking requests (INQ) not implemented
Target architecture: the first funnel stage		 works
Inbound request handling exists as an internal loop: requests are taken, sorted and recorded by our own tools. It is not provided to customers as a service
Lead qualification (QLF) not implemented
Target architecture: the scoring model		 dry-run
The GTM lead generation pipeline: research, qualification against set criteria, draft communications. Real sends are blocked by a hard gate
Lead and deal tracking not implemented
Target architecture: lead card and deal record		 works internally
CRM tracking of leads is kept locally as part of our test run. It is data of our own loop, not a customer base and not a product metric
Solution demonstration (DMO) not implemented
Target architecture: demo script and record		 none
There is no separate tool. Product demonstrations are assembled by hand for a specific request
Draft offers (OFR) not implemented
Target architecture: draft proposal and calculation		 dry-run
Draft letters and communications are generated by the pipeline and put into a drafts folder; the real-send flag is off as a hard gate, not as a default setting
Closing and payment (CLS) not implemented
Target architecture: deal record and handover to finance		 none
The project has no sales, so there is nothing to close. The finance loop is described on the platform page as a target
Touch sequence (FU) not implemented
Target architecture: the T+0 … T+14 schedule		 limited
Reminders about next steps are kept inside our own loop; there is no automatic sending of touches to customers, and there should not be one without a human confirming it
External communication with a lead not implemented
By architecture — always escalated to the owner		 works
The rule is enforced in practice: letters and messages go out only after the owner confirms, and the pipeline's dry-run mode fixes it technically

The works mark refers to our internal tools that we use in our own projects. It is not a feature of the VOIR AI product and not a promise to a customer. There are deliberately no numbers here about the count of leads, conversion or average deal size: the project has no customers and sales have not started. The actual status of the project is published on the About the platform page; the structure of the platform is on the AI Operating System page.

Link to the AI CEO

The sales department does not assign tasks to itself

Sales in VOIR AI is the executive part of the AI CEO cycle. The AI CEO takes the task, decides what goes to sales — an inbound lead, an offer to prepare, an analysis of refusal reasons — and merges the result into a report for the owner. The department's artefacts pass independent acceptance by a role that did not do the work. The list below shows what the department does at each of the five steps of the cycle.

  1. 01 Setting the task The department receives a brief and readiness criteria fixed before the start: which lead or pool of leads we take, what counts as the result of the step, what limits apply to terms and tone. Sales does not set its own task — otherwise the funnel starts pushing leads that do not suit the product.
  2. 02 Analysis and allocation The AI CEO decides which part of the work goes to sales and distributes it across the department's roles: qualification to one role, demo preparation to another, calculation and the draft offer to a third. The autonomy grade is fixed: what a role does on its own and what must go to the owner for confirmation.
  3. 03 Execution The roles move the lead along the stages: lead card, qualification verdict, demo script and record, draft offer. Each role keeps a trace of its actions and passes the artefact on together with sources for the facts or an explicit “no data” mark. There are no external sends at this step.
  4. 04 Independent check A QA role that did not handle this lead checks the artefacts against the criteria of step 1: a source for every fact, no promises of unimplemented capabilities, the ban on external communication respected, the refusal reason correct. The verdict is VERIFIED or REJECT with a list of discrepancies.
  5. 05 Acceptance and report The AI CEO merges the checked artefacts into one report for the owner: what moved through the funnel, what went to refusal and why, which decisions stayed with a human, what changes in the next cycle. Rejected artefacts and missed deadlines go into the report as they are, without smoothing.

Department roles in the target architecture

SDR

SDR qualifier

Runs the INQ and QLF stages: takes the request, creates the lead card, asks clarifying questions along the criteria, and issues the verdict “into work / loop / refusal”. Does not promise terms and does not discuss price — that belongs to the offer stage.

DME

Demo engineer

Runs the DMO stage: builds a show script for the customer's task, prepares materials, keeps a demo record with questions and answers. Is obliged to mark unimplemented capabilities as target architecture honestly.

NGA

Negotiation analyst

Runs the OFR and CLS stages: prepares the draft offer and the calculation, agrees terms with product and finance, writes the deal record. The final word in a negotiation belongs to the owner, not to the role.

Artefacts the department leaves behind

  • Lead cardsource, the task in the customer's words, the touch history
  • Scoring modelcriteria fixed before the start, and a verdict with sources for the facts
  • Demo script and recordwhat was shown, which questions were asked, what was marked as not implemented
  • Draft offervariants of terms, calculation, a mark about human confirmation
  • Deal recordthe final agreements, constraints, handover to the finance department
  • Refusal logreasons for every LOSS branch — the only way to improve the funnel

Interaction points with neighbouring departments

  • Marketing → sales Qualified leads come from the marketing department together with the communication history and the materials for the deal. Without that history the next step is taken blind.
  • Support → sales The context of requests and recurring problems comes from support: it shows what already hurts for the customer and stops us from promising what the product does not cover.
  • Product and finance → sales Deal terms — scope of work, timing, cost, payment order — are agreed with the product and finance departments before the draft offer goes to the owner.
  • Sales → owner and QA All stage artefacts go to independent acceptance, and external communication goes to escalation with the owner. A role sends nothing out on its own.

How a single executor is built is on the AI Agents page; how the headquarters assembles several departments for one task is on the AI Teams page; roles across all departments are on the AI Employees page.

Boundaries

What the sales department never does

Sales is the area where automation is doubly tempting: here you can both promise and push. That is why the limits are built into the contract of the stages, not into settings: no role of the department can bypass them.

Does not call or write to customers itself

Any external communication — a letter, a message, a call, an offer — is escalated to the owner. Drafts circulate freely inside the department; nothing goes out without a human.

Does not promise discounts or deadlines

Deal terms are a financial and product decision. The department prepares variants and a calculation; a human makes the final call. A promise given without confirmation counts as a defect of the artefact.

Does not sell what is not implemented

Capabilities the product does not have are marked as target architecture both in the demo and in the offer. Presenting a draft architecture as a working function is grounds for rejecting the artefact at acceptance.

Does not invent metrics or customers

No conversions, no average deal cycle, no “typical results”, no testimonials or logos. If there is no data, the mark is “no data”. There is not a single performance figure on this page because there have been no sales.

Does not push after a refusal

The follow-up loop is finite. After the control touch the lead goes to the branch with the reason recorded. Endless reminders and pressure are not our method, and the architecture forbids them.

Does not accept its own work

A role's self-check stays, but only the verdict of independent acceptance goes into the report. A lead card or a draft offer that never reached QA does not exist as far as the report is concerned.

Questions

What people ask about AI sales

Is the AI sales department already running?

As a VOIR AI product — no. All five funnel stages on this page describe the target architecture: not one of them is implemented in the product code. The funnel demonstration runs a prepared scenario and is not connected to a live AI service. Separately there is the Marisova ecosystem, where request handling, lead qualification and internal tracking exist as our own tools and the GTM pipeline runs in dry-run. They are not the VOIR AI product and are not provided to customers.

What does the status “target architecture” mean?

It is an honest mark that the function is described in the project but not implemented in the product. We keep two statuses apart: “target architecture” — how the department should work according to the VOIR AI project; and “works in the ecosystem” — the tool already exists and we use it internally. Mixing them up is not allowed: the second status does not mean the customer gets that capability.

Does the sales department write to customers on its own?

No, and that is an architectural constraint, not a setting. Any external communication with a lead is escalated to the owner: the department prepares the lead card, the qualification verdict, the demo script and the draft offer, and a human makes the final call. In the Marisova ecosystem the rule is enforced in practice — real sends of the pipeline are blocked by a hard gate rather than switched off “by default”.

Which metrics does the funnel show?

No performance metrics appear on this page on purpose: no conversions, no percentages, no average deal cycle, no deal size. The “demo” counters next to the stages count only the dots of the prepared demonstration scenario, and in the static frame and with animation off they are zero. The structural numbers are five stages, five touches in the target sequence, eight departments in the architecture, zero stages implemented.

How is the sales department linked to the AI CEO?

The department does not assign tasks to itself. The AI CEO takes the task and the readiness criteria, distributes the work across the department's roles — the SDR qualifier, the demo engineer and the negotiation analyst — merges the result into a report for the owner and decides what to change in the next cycle. The stage artefacts pass independent acceptance by a QA role that did not handle the lead. Details are on the AI CEO and AI CEO Cycle pages.

Can the sales department be used separately from the platform?

Architecturally it makes no sense. The funnel runs on the platform's shared data: leads come from marketing with their communication history, request context comes from support, deal terms are agreed with product and finance, acceptance uses the common mechanism, and the decision log is kept by the AI CEO cycle. A standalone “AI sales manager” without that data turns into a letter generator with no product knowledge and no quality control.

Where to go from this page

Sales is one of eight departments: leads come from marketing, the task is set by the AI CEO, and the work is done by agents and roles.

Funnel input

AI Marketing

Where leads come from: six channels, a measurement bus and the same honest “product / ecosystem” status table.

Open → Process

AI CEO Cycle

Five steps inside which the department gets a brief, moves the lead along the stages, passes acceptance and reports to the owner.

Open → People and roles

AI Employees

Roles of all eight departments: who runs the funnel stages and who accepts the work independently.

Open →

See the plans Ask about the platform