OpsPal
Process Management Anonymized

Sales process rules a growing team can run on

The sales process lived in the founder's head: stages, decline reasons, and when a lead goes back to the pool were all judgment calls. We wrote the rules down, built them into the CRM, and logged every change order so the process could survive a hire.

Business phase

A founder-led B2B company launching a new line of business, selling to owner-operators in the trades. Every deal needs a third-party approval before it can close, so which leads get worked, and in what order, decides revenue. The founder was about to hire the first phone rep.

The bottleneck

The founder acknowledged the process was "mostly in my head." Deals were tracked in a partner's board and re-keyed into the CRM. Why a deal was lost lived in memory. Nothing defined when a lead was qualified, when it had gone quiet, or when it should go back to the shared pool.

The operating drag

A rep cannot be onboarded into a process that is not written down, and a founder cannot step back from one. Reviews turned into arguments about definitions, and every lost deal was a one-line note instead of a reason anyone could count.

What we saw

The founder already knew the rules. They had never been stated as rules. Once they were, most of them could be enforced by the CRM instead of by reminders.

What we built

Written lead statuses and sequence statuses with definitions. A qualification flow that stamps the marketing-qualified and sales-qualified dates automatically, with one hard disqualifier instead of a list of soft ones. Separate decline and loss reason lists, later consolidated into one structured reason picklist that is required on every closed-lost record. Equipment and owner fields required at the stages where a rep would otherwise skip them. Aging rules that move quiet leads to nurturing after three days, return untouched leads to the shared pool after seven, warn on stalled applications on day two, and cap how many times a lead can recycle. A sales process playbook drafted from the founder's own job description for the role, and a client-facing log of errors, questions, and change orders so scope decisions were visible to both sides.

New→Qualified→Working→Application→Closed, with a reason

Handoff

The rules live in three places on purpose: on the record as per-stage guidance, in the playbook the rep is trained on, and in the CRM's own validation rules. Changing one means changing all three, and the change-order log says who asked and when.

The win

Lost deals became countable. With structured reasons on most closed-lost records, the two biggest avoidable losses turned out to be "would not send documents" and "already got approved elsewhere": speed and urgency problems, not lead-quality problems. That finding redirected the next build from scoring to routing.

What came next

The written rules became the spec for an automated lead queue and speed-to-lead clock, and the playbook became the first module of a rep training hub.

Before

  • Process in the founder's head
  • Lost deals explained in free text
  • Quiet leads forgotten
  • Scope changes argued from memory

After

  • Statuses, stages and reasons defined and enforced
  • One structured reason on every closed-lost record
  • Aging rules return quiet leads to the pool
  • A change-order log both sides can read

Want a system like this?

Book a scoping call and we'll map what to build for your business, in what order, and what it costs.