MyClient.software
One relationship can contain several different decisions.
This guide follows a fictional studio conversation with adult organisational contacts. It is a manual reading exercise, not an interactive CRM demonstration. The existing reference pages describe the model and its measured reach; this page shows how to ask clearer questions about that model. Nothing entered, saved, sent, provisioned, signed, or paid is implied by reading the example.
01 · Working example
Identify the organisation without collapsing the people
North Window Studio is an invented business discussing an adult staff-portrait service with an invented organisation called Alder Centre. Rowan handles practical arrangements at the centre. Kim reviews the proposed scope. Dev at the studio maintains the conversation notes. None of these people is a learner, and the example contains no actual customer record. The starting problem is simple: Dev's note says only "Alder wants portraits," although the conversation contains several different voices and responsibilities.
Dev rewrites the note with three separate statements: "Alder Centre is the organisation under discussion. Rowan is the practical contact for this conversation. Kim is reviewing the proposed scope." The result preserves the organisation while distinguishing who said what. It does not establish that either adult has authority to sign a contract. The human pause is to check that responsibility before describing an agreement as approved. An objection often follows: why bother with separate contacts for a small opportunity? Because a single name beside an organisation can quietly turn an enquiry into an instruction from someone who never gave it. The model's distinction between an account and its contacts helps frame that question; this worksheet does not create either record.
02 · Working example
Write the proposed deal as a proposal
Dev has a draft description of one staff-portrait session and a tentative date. Rowan has asked whether the studio can accommodate a shorter session. Kim has not answered the scope question. Calling the whole discussion a confirmed booking would combine three different states: interest in a service, negotiation about its shape, and acceptance of a particular commitment. The fictional conversation has reached only the first two.
The revised specimen says: "A staff-portrait session is under discussion. Rowan has asked about a shorter format. The scope and date remain proposals while Kim reviews the wording." The output is a clearer working summary. It does not move a deal, execute a contract, or put a date into a calendar. Dev pauses before using a stage label because the label needs to match the evidence in the conversation. The objection that a tentative opportunity belongs in a pipeline is not a contradiction. A pipeline can represent uncertainty, but only if uncertainty stays visible. The existing object-model and reach pages describe separate stored objects and available or missing screens; a prose example cannot substitute for the actual workflow required to change them.
03 · Working example
Keep an activity separate from an outcome
An adult colleague reads the proposed scope and asks one question about preparation time. That is an activity in the relationship. It is not automatically approval, rejection, a signed agreement, or evidence of payment. A useful note says what happened at the level the observation supports. "Kim asked whether setup is included" is stronger evidence than "the client is nearly ready," even though the second sounds more optimistic.
Dev's manual note records the question and identifies the answer still needed. The output gives Rowan something concrete to check without assigning an invented probability to the deal. A pause remains before anyone tells the studio team that the session is confirmed. If a colleague objects that detailed activity notes take too long, the specimen is only one sentence longer than the vague version. The gain comes from a precise verb, not from an elaborate report. MyClient's existing reference material distinguishes activities, deals, and contacts. This guide uses that distinction to improve a fictional working note; it does not log an activity, start a cadence, send a follow-up, or infer the other party's intent from silence.
04 · Working example
Use amounts and probabilities for the question they answer
Suppose Dev's fictional worksheet contains a proposed amount of 42,000 cents and a probability assumption of 2,500 basis points. Multiplying and dividing by 10,000 gives an illustrative expected amount of 10,500 cents before any separate grouping rules. That arithmetic is a planning calculation. It is not cash received, a charge, a customer balance, or a promise that a quarter of the proposed amount is payable.
Dev writes the input values beside the result and labels the probability as an assumption in this manual example. The output is something a colleague can inspect rather than a persuasive number with its origin removed. The pause is to check whether the assumption has any agreed basis and whether the opportunity belongs in the chosen set. The existing arithmetic page explains the product's integer units, effective probability, and exclusions in detail. It should be read before interpreting a real forecast. The objection that a single weighted number is easier to compare is valid, but easier comparison does not eliminate uncertainty. A number can be calculated precisely while the underlying proposal remains undecided. Nothing in this guide opens a checkout or converts an expected amount into money.
05 · Working example
Leave the next action with an actual owner
At the end of the fictional review, Kim still needs an answer about setup. Dev can ask the relevant studio colleague to clarify that point, while Rowan can confirm the practical constraints already discussed. Those are separate human actions. A message saying "all sorted" would conceal the open question and make the next person believe that the agreement was complete. The useful handoff names the pending work without claiming it is underway merely because someone has been named.
The specimen reads: "Dev will ask the studio colleague about setup. Rowan's practical note remains available for that conversation. The scope is still unapproved in this example." The result is a manual handoff with an explicit remaining decision. The pause is to obtain the colleague's agreement before treating the proposed owner as committed. If someone asks whether MyClient automatically chases that person, this public guide does not offer that action, and the existing sequence account describes a spine without a running outreach engine. Contacting the product address is likewise an enquiry, not account creation or activation. The example finishes with a better question and a clearer record of uncertainty, rather than an invented finished sale.
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.