MyClient.software
Separate useful model features from actions a person can actually take.
This page is a guide to reading feature claims, using the actual distinctions in the existing MyClient reference material. The examples are invented adult business conversations, not customer evidence. A feature does not become available because it has an attractive name, and a public explanation does not create a record. The detailed legacy pages remain the place to inspect the model and the measured gaps.
01 · Working example
Several contacts can preserve several responsibilities
A fictional adult arts organisation discusses a commercial service with a studio. Fern handles logistics, Asha reviews the scope, and Noel is the studio contact. Their roles in the example are different. A note that calls Fern "the decision maker" merely because Fern replied first would lose the distinction. The feature question is not whether a product can store more names; it is whether the relationship can be described without assigning authority that has not been established.
Noel's manual specimen reads: "Fern answered the location question. Asha is reviewing the proposed scope. No approval is recorded in this exercise." The result supports a clearer conversation about multiple contacts. It does not create contact rows, validate roles, or grant anyone permission to sign. The pause is to check the responsibility behind a label before using it in a handoff. If someone objects that the extra distinction slows a sale, the problem it avoids is costly: asking the wrong person to confirm a decision they do not own. The existing contact model gives that discussion a vocabulary; the public feature page does not verify a real organisation's authority structure.
02 · Working example
An organisation relationship should survive an individual opportunity
The same fictional organisation may discuss one service now and a different service later. Treating every proposed deal as a new client would split the relationship into fragments. Treating every new proposal as an edit to the old deal could erase what was previously discussed. The distinction between the organisation and the opportunity matters before any amount or stage is attached.
Noel draws a manual diagram with one organisation heading and two separately labelled proposals. One is an illustrative completed discussion; the other remains a draft idea. The output shows why the two pieces of work should not be confused. It does not demonstrate an automatic duplicate detector, a migration tool, or a merge feature. Asha pauses before adopting the diagram because the real relationship might have a different structure. The objection that an account is simply a company record misses MyClient's stated school-account and district-resolution model. That model has a specific shape described on the object-model page. This adult exercise explains the value of separating relationships from opportunities without claiming that this public page performs the resolution or writes any account.
03 · Working example
Derived figures need their inputs beside them
A proposed value and a weighted forecast answer different questions. For an illustrative amount of 18,000 cents and probability of 3,000 basis points, the simple weighted calculation is 5,400 cents. That does not mean the organisation owes 5,400 cents. It is an expected-value result from a stated assumption. The existing arithmetic reference describes integer units, effective probability, and the product's treatment of the relevant deal set.
Noel places the input values above the result in the fictional worksheet. Fern's first draft of the meeting note says "expected payment." They revise it to "illustrative weighted value" because no invoice or settlement is involved. The output is less likely to be mistaken for cash. The pause is to check both the units and the meaning of the probability before comparing the figure with another proposal. If a colleague objects that the difference is obvious, copied numbers often lose their headings. A feature that explains its inputs is easier to use responsibly than a bare total. This page does not bill the example amount, estimate an actual customer, or offer a live payment action.
04 · Working example
A transition is a request with prerequisites
The advertising reference describes proposals, insertion orders, invoices, and their allowed transitions. A transition label is not merely decorative: the actual route can refuse a requested change. That is useful when the refusal prevents a record from claiming an event that has not been supported by the required evidence. The public feature description must keep the relevant condition attached rather than saying that every request always succeeds or always fails.
In a fictional adult discussion, Noel has a draft scope and a note that somebody intends to review it. Fern writes "approved" in a summary, then corrects the word to "awaiting review" when the evidence is checked. The output is a manual wording correction. It neither invokes the advertising route nor supplies a signature or payment record. The pause is to ask what actually happened before choosing the stronger state. An objection that the software should infer approval from a positive conversation assumes a capability not offered here. No AI approval judgement is claimed by this page. The existing transition reference describes the implemented conditions; the example illustrates why preserving those conditions matters to a person reading the result.
05 · Working example
The missing action belongs in the feature assessment
The existing reach material names capabilities with no reachable screen and describes the sequence work as a spine without an executing outreach engine. The public site has no checkout. With the live payments switch off, the described settlement path is an attested offline record, not a provider charge. These limits affect whether a feature fits a particular job just as much as its underlying computation or data shape.
Noel's final worksheet has an open question: "We need an actual supported workflow for this action; the reference describes a gap." The result prevents a feature list from becoming an instruction to click something that is absent. Fern pauses before promising an automated follow-up or live payment to the fictional organisation. If the objection is that naming gaps makes comparison harder, it makes comparison more accurate: a missing outreach action cannot be counted as delivered merely because sequence-related types exist. An enquiry can ask about that boundary without assuming activation. The reading page offers no account creation, email sending, automatic workflow, checkout, or transfer of responsibility for the organisation's real commercial decisions.
A human enquiry, with its scope intact
Contact MyClient.software with a product question. This reading page creates no account, agreement, payment, or automated outreach. The reachability reference and existing refusal reference retain the detailed limits.