How to Design a Business Tracking System That Doesn't Rely on Memory

Many companies believe they need more leads when in reality they are losing continuity between the moment an opportunity comes in and the moment someone decides what to do with it. The lead arrives through a form, a call, WhatsApp, a recommendation or an email. Someone answers. Information is requested. Maybe a budget is prepared. Then silences appear, tasks without responsibility and follow-ups that live in a person's memory.

Buying a CRM alone does not correct this problem. A CRM records information. The trading system is the set of rules that determines what each status means, who is responsible, what event forces action, how long an opportunity can wait, what is automated, and how it is detected that something has stopped.

1. Start by measuring where continuity is lost

Before changing tools, rebuild a sample of recent opportunities. Don't just ask how many were earned. Ask what happened between stages. For each opportunity, identify origin, entry date, first response, agreed next action, responsible person, status changes, proposal, last contact and result.

Look for four types of friction: espera, when no one acts; loss of context, when the next contact does not know what happened; ambiguity, when two people believe that the other is responsible; and avoidable manual labor, when copying data or chasing reminders that the system could manage.

There is no correct universal SLA. An urgent consultation and a six-month consultative sale require different rhythms. The company must define them based on customer expectations, complexity and economy of the process.

2. Design the process before the CRM

A good business flow can be described without mentioning software. For example: input → validation → qualification → conversation → proposal → decision → won/lost. That sequence is just the skeleton. What is important are the transition conditions.

For each stage it defines what must be true to enter, what minimum information must exist, who is responsible, what action is expected, what event allows exit and what happens if the case does not progress. If “Proposal submitted” only means that a PDF exists, the status contributes little. If it means that the proposal has been sent, there is a follow-up date, an identified decision maker and next action, then the status represents an operational condition.

A useful pipeline doesn't describe where the lead is on a screen. Describe what should happen next and who is responsible for what happens.

3. States, responsible parties and next actions

Avoid pipelines with too many decorative states. Each state should change a decision, a responsibility, or a metric. “Interested,” “very interested,” and “hot” are often subjective labels if they have no observable criteria.

Ownership must also be explicit. An opportunity can involve sales, pre-sales, management and operations, but there must be a person responsible for continuity. Consults and collaborators can change; the owner should not be ambiguous.

The next action is more important than the last activity

Recording that “an email was sent” explains the past. Registering “call Thursday if no response” rules the future. That is why every active case should have, when appropriate, a next action with a date and person responsible. If there is no next action, there must be an explicit reason: waiting for client, discarded, nurturing, closed or another defined condition.

4. Design times and scales

A commercial internal SLA doesn't have to become a minute chase. It serves to make visible cases that go beyond the expected pace. Define windows by stage and priority. When an opportunity exceeds the window, the system can warn, reassign or request review.

Scaling should be reserved for exceptions. If management receives each lead without a response, the system has simply moved the work. A better rule can only escalate opportunities of a certain value, strategic clients, cases with two breaches or situations where the person in charge is not available.

5. What should be a source of truth in the CRM

The CRM should contain the data that governs the business relationship, not an indiscriminate copy of all systems. At a minimum: identity, company, contacts, origin, owner, stage, next action, relevant activity, value or rank when useful, decision and reason for loss.

Large documents, operational data or entire conversations can live in other systems if a stable link exists. The right architecture reduces duplication and makes it clear which is the authoritative source of each data.

Data quality

Required fields should be few and linked to decisions. If twenty fields are requested that no one uses, the team will learn to fill them in anyway. It is better to require the minimum information necessary to pass the stage and enrich the record when the process requires it.

6. What to automate and what not

Automate deterministic events: create tasks, normalize data, deduplicate, enrich with authorized sources, remember follow-ups, synchronize systems, generate drafts, classify requests or notify of non-compliance. Maintain human supervision where there is negotiation, contractual commitment, sensitive interpretation or a decision that may materially affect the client.

AI can help summarize conversations, extract needs, prepare questions or propose a follow-up draft. But design must assume that a model can make mistakes. If the system generates an unsupported business claim, an incorrect economic condition, or a non-existent promise, the cost may exceed the time saved. For high-impact actions, use human approval and record what information originated the proposal.

Idempotence and duplicates

A business automation must know what to do if it receives the same event twice. Resubmitted forms, repeated webhooks and retries exist. Defines idempotency keys, deduplication rules, and which system has the authority to create or update a record.

7. Metrics that explain the system

The final conversion rate is important, but it comes too late to diagnose. Add process metrics: first response time, percentage with next action, age by stage, time from proposal to decision, stalled opportunities, complete data ratio, conversion between stages and reasons for loss.

Segment when it makes sense by channel, type of customer, product, manager or complexity. An overall average can hide that one channel is performing very well and another is consuming unconverted capacity.

Hypothetical example: If two channels produce the same revenue but one requires three times as many conversations and manual tracking, the analysis should consider acquisition cost and operational cost, not just revenue.

8. Design the closure and handoff to operations

“Livestock” should not be the end of the system. Defines what information goes to delivery: sold scope, commitments, contacts, dates, restrictions, documentation and pending decisions. A bad handoff turns a good sale into rework and erodes margin.

The loss process matters too. A structured reason allows us to distinguish price, timing, absence of need, competition, lack of decision or mismatch. Don't force a false taxonomy: allow notes when the cause is unclear.

9. Omnichannel commercial service without creating chaos

If email, phone, forms and messaging generate opportunities, they all need an identity and routing strategy. The goal is not to put every message into the CRM, but to ensure that a relevant conversation can become a case, preserve context, and reach the right person in charge.

Before adding a chatbot or agent, define what it can solve, what data it can query, when it scales, and what context it delivers to the human. The experience gets worse if the customer has to repeat everything after escalation.

10. Practical audit in 90 minutes

1. Select 15–30 recent opportunities with different outcomes.
2. Rebuilds your timeline with data, not memory.
3. Flag waits, duplications, context losses and manual tasks.
4. List current states and delete those that do not change a decision.
5. Defines owner and next action for each active state.
6. Define two or three relevant SLAs and their exceptions.
7. Identify what data is mandatory to decide.
8. Separates deterministic automations from human decisions.
9. Choose five metrics that allow you to detect deterioration before the final conversion.

Conclusion

A robust trading system is not one that automatically sends more messages. It is the one that preserves context, assigns responsibility, makes the next action visible and allows exceptions to be detected before the client notices them. Automation comes after those rules.

If a company can't explain why an opportunity is stuck, who should move it and when, the first job is not to add AI. It is to design the commercial operating system.

En how we work We explain the ProjectCore approach to analyzing processes and designing systems before implementing technology.