What would need to be built for this to be real

• Read-only access to the systems the partner already uses, such as CRM, delivery, documents, and billing
• Optional, opt-in communication sources, used only as supporting evidence
• Clear limits on what is read, and a record of what was read

Open question: does the variety of partner systems create more work than the variety of destination systems?

• Signals from different systems need to be understandable together.
• Each signal should be tied to the right customer.
• The original source should always be traceable.

Keep customer signals in a consistent, easy-to-review format, tied back to where each signal came from.

• AI looks across approved customer signals and identifies a possible need, with the evidence kept so a person can understand why
• Evidence is grouped as primary, supporting, or corroborating
• AI interprets customer signals. Product rules and people decide what can happen next.

A new partner has no history to learn from, so the first rules have to make sense on their own.

• How much independent evidence supports the need
• Partners can set their own evidence rules
• Low confidence stops the process before any destination is considered

Confidence has to be explainable to a partner, not a hidden score.

• Which destination companies are approved.
• What type of need each one can help with.
• What kind of commercial relationship exists.
• What action is allowed.

This information has to stay current or the recommendations get worse.

• Is this destination actually a good fit for the need?
• Use Strong / Possible / Weak.
• A real need can still result in no action if the fit is weak.

If Vinculo recommends weak matches too often, partners will stop trusting it.

• What can be shared.
• Who needs to approve.
• Which actions are allowed.
• The partner can override or stop an action.
• Access to data and permission to act are not the same thing.

Legal and data-sharing rules need to be clear before this can run in production.

• Check whether the destination already has an active account or opportunity.
• Avoid creating duplicate activity.
• Suppress the recommendation if the opportunity already exists.

In the full product this may require access to the destination's system. In an early pilot, the same check can be done manually or with a simple lookup.

• Prepare the action and draft message.
• Track whether it is reviewed, approved, sent, changed, or stopped.
• Avoid sending the same action twice.

If something fails halfway through, Vinculo should not accidentally create the same action twice.

• Send the action into a place the employee already checks.
• This could be CRM, email, Slack, Microsoft Teams, or another workflow.
• The employee should not need to monitor a separate Vinculo inbox.
• The delivery method can vary by partner.

Open question: how much work is needed to support each delivery option?

• Check the destination's existing pipeline.
• Send or create the approved action.
• Get enough outcome information back to know what happened.
• Salesforce and HubSpot are examples of destination systems.

Open question: if two destination companies use the same system, how much of the work can be reused?

• Was the referral accepted?
• Was an opportunity created?
• Did the meeting happen?
• Did the opportunity move forward?
• Tie the outcome back to the original Vinculo action.

Vinculo only gets better if it can see enough of what happened after the action.

• Capture why a partner approves or dismisses something.
• Turn repeated feedback into clearer rules.
• Hold back similar recommendations when a partner has already shown they are not useful.
• Explicit partner knowledge can override an inferred recommendation.

Early on, there may not be enough feedback to train a strong model, so simple rules and human review matter.