Working with partners and suppliers
A supplier is a Company, a partner contact is a Person with identities, and the correspondence is threads and calls — the same records a customer produces. What changes is the scoping: partner traffic usually deserves its own mailbox role, its own autonomy setting and its own memory at the endpoint tier, because the tone and the authority you want are not the ones you want facing customers.
Nothing new is needed to model it#
There is no partner object, and adding one would be the wrong move. A Person is the canonical human; an Identity is one address on one channel and a person may hold many; a Company is the organisation several people attach to. A supplier's account manager who writes from a personal address on Tuesday and a shared one on Friday resolves to one Person either way, which is the whole point of identities being separate from addresses.
Lifecycle stages come from journey.py and are a vocabulary rather than a fixed sales funnel, so a partner relationship can be moved through stages that mean something to your side of the arrangement. Support cases work identically: a supplier problem is a case with context, and resolving it leaves the same trail as resolving a customer's.
Scope the behaviour, not the channel#
Autonomy resolves at four scopes and the narrowest wins: contact, endpoint, channel, workspace. That ordering is what lets partner correspondence behave differently from customer correspondence without changing anything global.
| Scope | Good use with a partner | Effect |
|---|---|---|
| Contact | One supplier's account manager who must always be answered by a person | ask_before_send or draft_only for that contact alone |
| Endpoint | A dedicated purchasing mailbox | Everything arriving there follows one rule, whoever writes |
| Channel | Partner calls answered but never initiated | Voice set to ask before calling, email left autonomous |
| Workspace | The default for anything not otherwise covered | The floor, not the instrument for one relationship |
Mailboxes carry a role and their own signature and autonomy, so purchasing@ reading as purchasing rather than as sales is a mailbox setting rather than a prompt instruction. Memory at the endpoint tier holds the things true of that mailbox — the account number format, the person who signs off — without leaking into customer replies.
What must stay with a person#
- Agreeing terms
safe_salesis the rule that Connect does not invent commercial terms. A price, an SLA or a warranty Knowledge does not support is refused and escalated. Committing your business to a supplier's terms is the same class of act in reverse, and it is not one Connect should be making.- Anything contractual
- Connect drafts, sends and records. It does not sign, accept, or accede to a change of terms on your behalf, and no page in this corpus should be read as saying it does.
- Clearing a do-not-contact entry
- A person, recorded against their name. The Assistant cannot do it at all.
- Disputes
- A case can hold the history and the evidence. The decision to escalate a dispute is a person's, and the
taskfollow-up channel exists to carry that instruction to them.
The failures that show up here first#
- A quiet mailbox. A purchasing address that authenticates and returns nothing is a health signal rather than an error, and it is easy to miss on a low-traffic mailbox where silence looks normal.
- One person, two companies. Somebody who is both a supplier contact and a customer contact is one Person with identities on both companies. Duplicates are proposed rather than merged, and the merge preserves both sides.
- A block set on the wrong tier. A
block:<channel>directive against a contact holds across every channel and every future conversation. That is correct for a nuisance sender and wrong for a supplier you simply do not want called. - Follow-ups without reasons. A commitment with no reason is not useful to the person who inherits it, and partner chases are inherited more often than customer ones.
Where the money goes#
Less than customer traffic, usually, and for a structural reason: partner threads are longer-lived and lower-volume, so the daily allowance is rarely the binding constraint. The cost concentrates in calls — the same audio-token economics as any other voice work, with the session re-billed for its whole context every turn — and in research, which partner relationships mostly do not need because you already know who they are.
Questions#
Should suppliers live in the same workspace as customers?
Yes. A workspace is the isolation root for a business, not for a relationship type, and splitting them would give you two halves of one company's history. Separate them with a mailbox role, a lifecycle stage and scoped autonomy, all of which are designed for exactly this.
Can Connect chase a supplier for a late delivery on its own?
It can send the chase under the channel's autonomy rule and keep the follow-up alive with its reason attached. It cannot decide what to do when the answer is unacceptable — that is a commercial judgement, and the honest shape is a task follow-up that puts the decision in front of a person with the thread attached.
Will a partner see that they are talking to software?
That is your decision and your wording. Connect writes under the mailbox's signature and the standing instructions you set; it does not add or remove a disclosure by itself. On calls, whether disclosure is required depends on where you and the caller are, and that is a question for your own advice.