A Matchmaker CRM Workflow: From First Enquiry to Follow-Up

A matchmaker CRM should answer four questions about every active person: Who owns the relationship? What has been agreed? What happens next? When is it due?

When those answers live across memory, inboxes and spreadsheets, clients wait, candidates receive conflicting messages and private information is copied more widely than intended. A clear workflow gives the team one operating language without turning a human service into a conveyor belt.

Design separate journeys for clients and candidates

A paying client and a potential candidate may be represented by the same person record, but their relationship with the agency is different.

A client has an engagement, scope, service dates, commercial terms and search strategy. A candidate has sourcing context, consent choices, suitability information and a decision about a particular introduction. One person may later hold both roles.

Do not duplicate the person to force them into two pipelines. Keep one identity with distinct roles, permissions and histories. Otherwise, a preference updated in one record may not reach the other, and deletion or correction requests become difficult to complete.

Use explicit lifecycle stages

The exact names can vary, but each stage should have an entry condition, an owner, required evidence and an exit condition.

1. Enquiry received

Capture only the information needed to respond: name, safe contact route, source, broad location and requested service. Assign an owner and response due date automatically.

Do not turn a contact form into full intake. A person who has not qualified should not need to disclose detailed relationship, health or identity information.

2. Qualification

Confirm service fit, geography, availability, expectations and any clear conflict. Record a short outcome:

• qualified for consultation;
• nurture or waitlist;
• referred elsewhere;
• declined, with an appropriate internal reason;
• unreachable after a defined sequence.

Qualification is not a hidden compatibility score. It is a documented decision about whether your service can responsibly help.

3. Engagement and consent

Before substantive intake, link the applicable agreement and privacy information. Record what the person agreed to, when, how and which version they saw. Consent is not a single universal checkbox: marketing, candidate search, profile sharing and collaboration can have different bases and choices.

If your legal basis is not consent, record that accurately rather than using a misleading toggle. Obtain jurisdiction-specific advice.

4. Intake

Collect information in layers. Begin with goals, practical constraints and high-value compatibility context. Ask sensitive questions only when the answer has a defined use.

Track intake completeness separately from matchmaker review. A submitted form can still contain ambiguity, contradictions or outdated information. Use the client intake questionnaire guide to design questions that produce useful conversation rather than an unnecessarily large database.

5. Profile approval

Separate three things:

1. private working notes;
2. structured matching information;
3. a profile approved for disclosure.

The client or candidate should know what the shareable profile contains. Record approval date and version. A later edit should not silently change information already shared with another person.

6. Search active

Create a search brief with hard boundaries, flexible preferences, context, geography and the next review date. Search should return explainable candidates, including missing-data warnings.

Log why a person was shortlisted or excluded. This prevents the same unsuitable profile from resurfacing without context and lets a supervisor review decision quality.

7. Candidate review and outreach

Before disclosing the client’s identity, check the candidate’s current availability, consent and relevant profile details. Record contact attempts with a reasonable stop rule; persistent outreach is not professional sourcing.

A candidate may be relevant but not interested. Keep those states distinct.

8. Introduction proposed

Use a controlled disclosure sequence. The first proposal may include a redacted summary. More identifying information follows only after the appropriate approval.

Record each party’s decision independently:

• interested;
• declined;
• needs clarification;
• unavailable now;
• no response by deadline.

A proposal becomes an introduction only when the required mutual consent is present. The privacy-first sharing guide provides a staged model.

9. Introduction active

Confirm logistics through approved channels. Limit staff access to what they need to coordinate. Do not expose home addresses, identity documents or private notes.

Set a follow-up date before the introduction occurs. The CRM should create the task; the matchmaker should conduct the conversation.

10. Feedback and next action

Collect each person’s feedback separately before sharing an appropriate summary. Distinguish:

• factual logistics;
• interest in continuing;
• preference learning;
• safety concern;
• private commentary that should not be forwarded.

Update the search brief only after a professional reviews the signal. One disappointing interaction should not automatically rewrite a person’s profile.

11. Pause, renewal or closure

A closed engagement needs a reason, a final communication and a data action. Record whether the profile may remain available as a candidate, must become inactive or should enter a deletion workflow.

A pause should have an end date. Otherwise, inactive work remains in reports and clients disappear without a deliberate decision.

Define the minimum record

Every active person record should show:

• stable internal identifier;
• current roles and statuses;
• owner and backup owner;
• preferred, verified contact route;
• jurisdiction and time zone;
• current consent or processing record;
• shareable-profile version;
• open engagement, if any;
• active search or candidate contexts;
• last meaningful contact;
• next action and due date;
• unresolved risk or complaint flag;
• retention or review date.

Do not display every sensitive field in the default list view. Operational visibility should not mean universal data exposure.

Model introductions as records, not notes

An introduction connects two people, two consent decisions, a proposal date, a current state and two feedback streams. Store it as a first-class record.

This makes important questions answerable:

• Has this pair been considered before?
• What information was disclosed, and under which version?
• Did both people agree?
• Who approved the introduction?
• When is follow-up due?
• Was there a concern that should affect future contact?

Free-text notes alone cannot reliably answer these questions.

Automate administration, preserve judgment

Good automation handles deterministic work:

• assign new enquiries by region;
• flag missing required intake fields;
• remind owners before an overdue follow-up;
• notify a reviewer when a profile changes after approval;
• close stale tasks after a documented outcome;
• schedule retention review;
• generate a draft update from verified status data.

Human approval should remain required for:

• deciding service suitability;
• interpreting sensitive information;
• selecting or excluding candidates;
• disclosing a profile;
• handling a safety concern;
• changing the scope of consent;
• communicating a rejection or complaint outcome.

AI can assist with summarization and comparisons, but the system should preserve source context and the accountable professional’s decision. See the AI-human matchmaking workflow.

Establish permission boundaries

Create roles around real responsibilities, not seniority labels. A coordinator may need scheduling details but not private assessment notes. A partner agency may need a redacted profile but not the client record. A finance user may need invoice status but not relationship history.

Review access when staff change role or leave. Log significant views, exports, changes and disclosures. Test permissions with representative accounts before importing live records.

Run a weekly operating review

A useful weekly review is short and exception-based. Examine:

• new enquiries without an owner;
• qualified people waiting for a decision;
• active clients without a next action;
• overdue profile approvals;
• searches with no activity during the agreed interval;
• introduction proposals awaiting one party;
• feedback overdue beyond the service target;
• expiring consents and retention reviews;
• complaints, safety flags and unresolved data requests;
• workloads above defined capacity.

The purpose is not to increase activity counts. It is to find promises at risk.

Measure flow without reducing people to inventory

Operational metrics can reveal failure points:

• median response time to qualified enquiries;
• days from engagement to approved profile;
• percentage of active clients with a current search brief;
• time from candidate shortlist to mutual decision;
• follow-up completed within target;
• proposals that become mutually accepted introductions;
• records returned for missing consent or outdated information;
• hours spent by stage;
• pause and closure reasons.

Segment carefully by service type and geography. Averages across unlike searches can create false conclusions.

Implement in three passes

Pass one: lifecycle. Configure roles, statuses, owners, next actions and introduction records. Import only current, necessary data.

Pass two: controls. Add permissions, consent evidence, approved-profile versions, audit events and retention dates.

Pass three: improvement. Add measured automations, saved searches, templates and management reporting after the team uses the base process.

Test with synthetic cases before migration: a duplicate person, a withdrawn consent, a rejected proposal, a reopened client and a safety escalation. A workflow that handles only the happy path is not ready.

Smart AI Match combines a CRM, professional directory and shared marketplace with AI-assisted tools. Whether you use it or another platform, make the lifecycle and control requirements explicit first. Software should make professional practice visible and repeatable—not replace it.