# MQL vs SQL for a small sales team: the acceptance rule that keeps both stages honest in your CRM

https://salesbond.app/blog/mql-vs-sql-small-sales-team-crm-acceptance-rule/
Published: 2026-10-20 · Updated: 2026-10-20

An MQL is a lead marketing thinks is ready to talk; an SQL is a lead sales has accepted as worth a real sales conversation. For a small team the difference only holds if someone accepts or rejects each MQL in the CRM within a set time and records a reason.

Skip that step and the two stages are just two labels. A month later nobody can say which one a given contact deserves. This is written for the team of three to ten reps with no marketing operations person watching the handoff, and it is mostly about the step in between: four fields on the contact record and one report for the manager.

## MQL vs SQL, and the decision in between

A marketing qualified lead (MQL) is a contact whose behaviour and fit say “worth a look”: pages visited, a form filled, a job title and company size that match who you sell to. A sales qualified lead (SQL) is a contact a rep has spoken to, or at least looked at properly, and judged worth a real sales conversation. Between the two, larger companies put a sales accepted lead (SAL): the moment sales says “yes, this one is ours to work”, before anyone has qualified need or timing.

So the order is MQL, then the acceptance decision, then SQL. HubSpot’s default lifecycle stages say much the same in their own words: a Marketing Qualified Lead is one marketing has qualified as ready for the sales team, a Sales Qualified Lead is one the sales team has qualified as a potential customer ( [HubSpot: use lifecycle stages](https://knowledge.hubspot.com/records/use-lifecycle-stages)). Signals make the first label. A decision makes the second, and the decision is the part that gets lost.

If your MQLs come from a scoring rule rather than a person, check the rule before you trust the label; we wrote down [what a sales manager should check in HubSpot lead scoring](https://salesbond.app/blog/hubspot-lead-scoring-sales-manager-check/).

People also ask what a good MQL to SQL conversion rate is. We won’t give a number. We have no data to stand behind one, and a ratio without reject reasons tells you nothing anyway: a low ratio can mean bad leads or lazy acceptance, and the number alone cannot say which. Your own ratio, week over week, with the reasons next to it, is the only version worth tracking.

## Why small teams need a third step: accepted or rejected

Because without a recorded accept or reject decision, MQL and SQL drift apart and nobody can see where. Nearly every MQL vs SQL guide is written by the marketing side for companies that have a marketing department. HubSpot’s own guide describes workflows that route the lead to the right rep the moment it reaches SQL ( [HubSpot: what is a sales qualified lead](https://blog.hubspot.com/sales/sales-qualified-lead)). That works when somebody owns the routing. In a five-person team the routing is “the lead is in the CRM” and the owner is whoever notices first.

Here is what we see happen. MQLs arrive. Reps pick the ones that look easy and leave the rest. A lead nobody touched for three weeks is still an MQL in the report so the MQL count climbs while SQLs stay flat. Whoever runs the ads concludes that sales ignores leads. Sales says the leads are bad. Both are partly right and neither can prove it, because no record says what happened to each lead.

We don’t think a small team needs the extra SAL stage. It needs the decision behind it: every MQL gets accepted or rejected, by a named rep, by a deadline, with a reason when it is rejected. That is the whole rule. The next sections put it into the CRM so it survives a busy week.

## How an MQL becomes an SQL: four fields on the record

A rule you can say out loud on Monday: “Every MQL gets a decision from its owner within the deadline. Rejected means a reason is picked. Waiting is not a decision.” Four fields carry it. In HubSpot, three of them are custom contact properties you create once; the fourth already exists.

**MQL decision.** A dropdown with three values: Waiting, Accepted, Rejected. Waiting is the default the moment a contact becomes an MQL, and the only way out is a rep changing it. We keep this out of Lead status on purpose. HubSpot describes Lead status as the sub-stages inside Sales Qualified Lead, with defaults such as New, Attempted to Contact and Bad Timing ( [HubSpot: use lifecycle stages](https://knowledge.hubspot.com/records/use-lifecycle-stages)), so it is the field for what happens after acceptance, not for the acceptance itself. Accepted moves the lifecycle stage to Sales Qualified Lead. Rejected leaves the contact a Marketing Qualified Lead that sales declined, which is exactly what it is.

The **reject reason** is a dropdown too, never a free-text box. Free text gives you forty spellings of “no budget” and nothing you can count. What goes in the list is the next section.

**Decision due** is a date and time: the moment the contact became an MQL plus your response time. HubSpot already stamps the first half for you in Date entered Marketing Qualified Lead ( [HubSpot: default contact properties](https://knowledge.hubspot.com/properties/hubspots-default-contact-properties)). Store the deadline on the record as well. A deadline that lives in a rep’s head is a deadline nobody can report on.

Then **Contact owner**, the one field HubSpot ships with. One person. Not a team, not a round-robin queue nobody checks. If the owner is out, the manager reassigns the lead, and the change is visible because the owner field changed.

![Schematic contact record with four fields: MQL decision, reject reason, decision due and contact owner](https://salesbond.app/wp-content/uploads/2026/10/mql-vs-sql-small-sales-team-crm-acceptance-rule-2.png)

Accepted has a consequence too. The moment a rep accepts, there is a next task on the record, otherwise Accepted is just a politer way of saying Waiting. How to make the next task the thing you manage is in [the follow-up system built on owner and next task](https://salesbond.app/blog/lead-follow-up-system-owner-next-task-report/).

## Reject reasons that marketing can act on

The test for a reason is simple: can the person who produced the lead do something different because of it? If not, it’s a complaint, not a reason.

In HubSpot that means a dropdown property with six to eight values and no “Other”. Past eight, reps pick the first option that looks plausible and your report becomes a report about the order of teh dropdown. And the day you add “Other”, it becomes the most popular reason in the CRM. The full list we start from, with what each reason asks of the lead source, is in [the lead handoff agreement for Pipedrive](https://salesbond.app/blog/lead-handoff-agreement-pipedrive/); the values carry over to HubSpot as they are.

What matters here is that every value points somewhere:

- a pile of wrong-fit rejections says the form or the ad targeting lets the wrong people through;
- could not reach is a question about the ask on the form, or about whether the rep actually tried, and the activity log on the contact settles that;
- not now is the one reason that is not final, so it needs a date, and on that date the MQL decision goes back to Waiting.

## Response time: set one number and report it

The author of HubSpot’s guide says they try to reach a newly qualified lead within 24 hours, and often much faster ( [same source](https://blog.hubspot.com/sales/sales-qualified-lead)). Use that as a starting point if you have nothing else, but notice what the number is for here. It is the deadline for the decision, not for closing anything and not for a full discovery call. Looking at the record and making one contact attempt is enough to choose between Accepted and Rejected with a reason. That is minutes, not days.

Pick a number the team can hit on a Friday afternoon with one rep on holiday. A heroic target that is missed every week teaches everyone that the deadline is decorative, and then the whole rule is decorative. One number for the team, not one per rep, or the report stops being comparable.

The number does one more job. A lead that is still Waiting after the deadline is late, and “late” is something a manager can act on today: call the owner, or reassign. Without the number there is no late. There is only a vague feeling that leads are piling up.

## One weekly report: MQLs waiting, accepted, rejected

The report that keeps both stages honest fits on one screen. For the past week, one row per rep: MQLs received, Accepted, Rejected, and Waiting past deadline. Under it, one small table of rejected leads by reason.

![Sketch of the weekly report: rows per rep, a highlighted "Waiting past deadline" column, and a table of reject reasons](https://salesbond.app/wp-content/uploads/2026/10/mql-vs-sql-small-sales-team-crm-acceptance-rule-3.png)

Read it in order. Waiting past deadline first: that column is the only one that needs something done this morning, and the something is a conversation with one rep, not a process change. Rejected by reason second. That table is your weekly conversation with whoever produces the leads, and it replaces the argument about whether leads are good with a list of what was wrong with them. Accepted divided by received comes last, and only as a trend. That is your MQL to SQL ratio, measured on your own leads with your own rule.

In HubSpot, a saved contact view gets you most of the way: Lifecycle stage is Marketing Qualified Lead, MQL decision is Waiting, Decision due is in the past. A spreadsheet export covers the rest for a team this size. Once a lead is accepted the same habit continues as [the weekly saved view of stuck lead statuses](https://salesbond.app/blog/hubspot-lead-status-vs-lifecycle-stage/), so the two views together cover a lead from MQL to deal.

We build SalesBond, a sales management layer on top of the CRM a team already uses; we started with Pipedrive. A rule like this one lives or dies on whether the fields are actually filled in, and that is the part we spend our days on. If you want to see what your CRM currently says about leads nobody has decided on, [check your CRM with SalesBond](https://salesbond.app/).

## Where the decision lives in HubSpot

Lifecycle stage holds the MQL and SQL labels and says where a contact is in the journey; Lead status takes over once sales has accepted the lead; the acceptance decision sits in its own property between the two. Put Accepted and Rejected into the lifecycle and you lose the sentence “this was an MQL and sales declined it”, which is exactly what the weekly report depends on. How the two built-in properties behave and which values are worth keeping is in [HubSpot lead status vs lifecycle stage](https://salesbond.app/blog/hubspot-lead-status-vs-lifecycle-stage/).

The rule feels like extra admin on day one. It isn’t, or not for long. Reps already decide which MQLs to work; they just do it silently by choosing which ones to call. So create the three properties this week, set one response time and run the Waiting past deadline view next Monday. By the second Monday the manager stops asking “what happened to that lead from Tuesday?”, because the record already says.