Consultant referral-partner outreach: define a useful referral boundary

Define the decision

Consultants protect their credibility when introducing another provider. Give a prospective partner enough information to understand your scope, evidence and limits. Do not ask for client names in the first exchange or imply that a conversation creates an obligation to refer business.

Work through the procedure

1. Define the problem you solve and the cases you decline.
2. Identify a complementary service boundary with the prospective partner.
3. Offer a sample scope or fictional case to test referral criteria.
4. Discuss introductions, client permission and commercial terms explicitly before using the relationship operationally.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

I handle reporting-definition ownership reviews but do not implement warehouse infrastructure. Your service appears to cover that implementation work.
Would it be useful to compare a fictional case and decide where a referral would or would not help the client?

Read the result

The case discussion tests whether the boundary is real. If both consultants claim the same scope, a referral arrangement may need a narrower definition or may not fit. A client should not be passed between providers merely to satisfy a reciprocal promise.

Check before moving on

1. Verify the partner's current capabilities.
2. Ask before describing someone as a referral partner publicly.
3. Keep client information out of exploratory correspondence.

Limits and next action

This is a relationship-design worksheet, not legal or compensation advice. Zintara does not formalize referral agreements or authorize client-data sharing. Maintain a clear record of what both parties actually agreed.

Source: Zintara product context; role-specific procedures are editorial guidance