Flowgrammer

Separate Fit, Engagement, and Timing

Design a transparent scoring model that keeps fit, engagement, timing, negatives and unknowns visible.

What you will complete

Complete a scoring model that shows why each lead received its priority and what action follows.

Start with the action the score supports

Write the decisions before assigning points. A practical first model may choose among priority review, standard review, enrichment, nurture, referral and decline. Each output needs an owner and an evidence standard.

Fit asks whether the organization and request match what you can serve. Engagement asks what the person has done. Timing asks whether the request requires action now, later or after more information. Negative signals capture confirmed conflicts. Existing context protects customer relationships, owners and open opportunities.

You can use points, bands or explicit rules. Use the simplest method your team can explain and test. A total without visible components makes correction harder.

Design the evidence table

DimensionExample signalEvidence ruleUnknown action
Account fitSupported market and use caseForm plus approved public or CRM sourceEnrich or review
Person fitResponsible for the affected workSubmitted role or existing recordAsk during review
EngagementRequested a scoped conversationOriginal request eventKeep the known event only
TimingNamed implementation windowPerson-supplied statementDo not invent urgency
NegativeConfirmed vendor solicitationRequest contentManual review if ambiguous

Record source, observed value, model version and reason beside the score. If activity becomes less useful over time, define a decay rule. Do not let an old download keep a lead permanently “hot.”

Worked example: Harborline scoring

Fictional example: Harborline scores account fit and request fit from 0 to 4 each, engagement and timing from 0 to 3 each, and confirmed negative signals from 0 to minus 4. It displays every component. A priority-review candidate needs strong combined fit, a meaningful current request and enough evidence. The score never creates an SQL.

A 60-person Ontario manufacturer requests a manager-training proposal for the next quarter. The record has strong account fit, strong request fit, meaningful engagement and stated timing. It enters priority review. A student downloads a general checklist from the same industry. Industry fit is present, but the request and purchase context are not. The record receives an appropriate resource path, not a sales task.

An existing customer using a personal address matches through the company name and conversation history. The system preserves the account owner and sends the conflict to review. A personal address alone does not prove poor fit.

Complete section 2 of the workbook

  1. Name the actions your model may recommend before you choose points.
  2. Write signals for fit, engagement, timing, negatives and existing context.
  3. For every signal, record the source, value rule, unknown action and owner.
  4. Define thresholds, any decay rule, and when a score must go to review.
  5. Require an override reason while preserving the original recommendation.

Use section 2 of the workbook.

Check the model for false precision

Review any field that depends on an inferred budget, private financial data or a vague “intent” label. Remove it or replace it with evidence you can name. Keep confidence separate from priority: a lead can look promising while the available evidence remains weak.

Version the model. When criteria change, you need to know which rules produced an old decision. Review overrides by reason rather than treating every disagreement as model failure.

Check your decision

1. A lead has strong engagement but a confirmed unsupported use case. What should remain visible?

2. What should a scoring threshold always connect to?

3. A person overrides the recommended route. What should the system retain?

Return to Build a Lead Qualification and Sales Handoff System