# From Lead Capture to a Scalable Sales Pipeline > A financial services lender where every enquiry arrived somewhere different, and the forecast was assembled by hand the day before the board pack was due. - Source: https://synconai.com/case-studies/lead-capture-to-scalable-sales-pipeline - Publisher: SynconAI (https://synconai.com) - Type: Case study - Evidence: Illustrative scenario. This describes how SynconAI approaches the problem. It is not an account of one named customer, and no outcome is claimed as measured. - Organisation: A mid-market financial services lender operating across several regulated products - Industry: Financial Services - Products: Sales Cloud, Financial Services Cloud, Flow, Reports & Dashboards - Service: Salesforce Sales Cloud Consulting (https://synconai.com/salesforce-sales-cloud-consulting) - Reading time: 6 minutes ## In short A lender with four lead channels and no shared definition of a lead consolidated intake into one service, ran deduplication before assignment, routed on licensing rather than round robin, and tied each opportunity stage to buyer-verifiable evidence. The forecast then reads captured evidence instead of being assembled by hand each month. ## Key points - Route on who is permitted to advise, not on whose turn it is. In a regulated product that is a compliance boundary, not a preference. - Deduplicate before assignment, never after. Once two reps own two records for one person, merging is a conversation rather than a job. - A stage definition that cannot be verified by something the buyer did is a rep opinion with a percentage attached. - The forecast is an output of the pipeline design. If it needs rebuilding by hand, the pipeline is not designed. ## Lead intake to forecast Enquiries arrive from four channels into a single intake service rather than four inboxes. Deduplication runs before assignment, so a returning applicant lands on the existing record instead of creating a second one. Assignment uses product and licensing rather than round robin. From there the opportunity carries the evidence each stage requires, and the forecast reads that evidence rather than a rep judgement. ### 1. Channels - Web enquiry form - Broker portal - Inbound call - Referral partner Four sources that previously wrote to four different places, with no shared definition of a lead. ### 2. Intake and matching - Lead - Duplicate rules - Matching rules - Person Account Matching runs before assignment. A returning applicant is the same person, not a new one. ### 3. Assignment - Product line - Licensing and accreditation - Capacity - Queue Routed on who is permitted and available to advise, which in a regulated product is not a preference. ### 4. Pipeline - Opportunity - Stage evidence - Required fields by stage - Approval Each stage names the artefact that proves it. No artefact, no stage. ### 5. Forecast - Forecast category - Dashboards - Stage-change history Reads the evidence already captured, so nobody rebuilds it the night before. ## The problem, as it actually presented The brief we get in this situation is almost never "our lead management is broken". It is "we cannot trust the forecast". That is a symptom, and chasing it directly leads to dashboard work that changes nothing. Trace it back and the same shape appears: enquiries arrive through four channels that were each built by a different team in a different year. The web form writes a Lead. The broker portal writes to a spreadsheet that somebody imports weekly. Inbound calls are typed into whatever the adviser has open. Referral partners email a named person, who forwards it. Four channels, four definitions of a lead, and no single place where an enquiry is known to exist. Downstream, the effects compound. The same applicant appears three times because nothing matched them across channels. Two advisers work the same person without knowing. Reporting counts three enquiries where there was one, so conversion rate is understated and nobody can say by how much. And because stage definitions were never agreed, every deal sits at a high probability until the day it either closes or vanishes. ::: warn The tell for this problem is not a metric. It is that somebody rebuilds the forecast by hand, in a spreadsheet, in the days before it is due. That work exists because the system cannot answer the question, and it hides the gap rather than fixing it. ::: ## What we designed, and why ### One intake, not four front doors The first decision is that every channel writes to the same object through the same service, and nothing is permitted to write around it. That sounds obvious and it is the part that gets negotiated hardest, because each channel has an owner who is confident their route is fine. The argument that lands is not about tidiness. It is that deduplication cannot work if records arrive by four paths at four times with four shapes. One intake is what makes matching possible at all. ### Matching before assignment, always Deduplication has to run before a human is attached to a record. This ordering is the single decision that saves the most pain later. Once two advisers own two records for the same applicant, you no longer have a data problem. You have a conversation about whose pipeline shrinks. That conversation is political, it takes weeks, and it recurs. Matching first makes it a non-event: the returning applicant lands on the record that already exists, with its history intact. In practice this means matching rules on the identifying attributes that are stable, and accepting that some matches need a human decision. A queue for ambiguous matches, reviewed daily, is a far cheaper thing to run than a merge programme a year later. ### Routing on permission, not on turn Round robin is the default because it is fair and easy to explain. In a regulated lending business it is also wrong, because not every adviser is permitted to advise on every product. So assignment reads product line, the adviser's licensing and accreditation, and current capacity. Fairness is preserved within the set of people who are actually allowed to take the enquiry, which is the only place fairness is meaningful. This is worth stating plainly to the business: routing is a control, and it should be evidenced like one. The rules live in configuration that an auditor can read, not in a formula that has to be reverse-engineered. ### Stage definitions tied to evidence The forecast problem is solved here rather than in the reporting layer. Every stage names an artefact the buyer produced. Not "adviser believes the client is interested" but "application submitted", "documents received", "credit decision issued". Each is something that either exists or does not, and none of them requires anyone to estimate a probability. Then the required fields for each stage are exactly the fields that prove the artefact exists, and nothing else. We take fields out during this work as often as we add them, because a required field that no report, approval or obligation consumes is pure friction, and friction is what teaches people to type anything to get past the screen. ## Implementation The sequence matters more than the components. **Settle the stage definitions first, before building anything.** This is a facilitated argument, not a workshop. The people who own the number and the people who move the deals have to agree what qualified means, in writing. Everything downstream is cheap once this is settled and expensive to change afterwards. **Then the data model and matching.** Person Accounts versus a contact-and-account pair is one of the decisions that is close to irreversible once the org holds real data, so it is made deliberately and early rather than defaulted into. The same applies to how related parties are represented. **Then intake, one channel at a time.** The web form first, because it has the cleanest shape and the fewest owners. Each subsequent channel gets migrated only when the previous one is stable, so a routing defect is attributable to one change rather than four. **Then routing, then the pipeline fields, then reporting last.** Reporting is built against a pipeline that already behaves. Building it first produces dashboards that have to be rewritten. ::: note We deliberately did not automate the ambiguous-match queue. A confident automatic merge on a near-match is how two people's financial records become one, and that error is far more expensive than a daily review task. Some things should stay manual on purpose. ::: ## The decisions that were contested **Removing fields.** Every mandatory field had someone who asked for it. The rule we applied was that a field stays mandatory only if it can be traced to a report someone reads, an approval that gates something, or a regulatory obligation. Several did not survive, and the conversations were not comfortable. **Not building a scoring model on day one.** There was appetite for lead scoring. We argued against it in the first phase, because a score built on the historic data would have learned from the duplicated, mis-attributed records we were in the middle of fixing. Scoring is worth doing on evidence that is trustworthy, which it was not yet. **Keeping the broker portal as a separate channel.** The tidier design collapses it into the web form. The business reason not to is that brokers have a different relationship, different disclosure requirements and different service expectations, and flattening that into one form would have made both experiences worse. ## What changes The outcomes worth claiming from this design are operational, and they follow from the decisions rather than from effort. | Before | After | What made the difference | | --- | --- | --- | | Four channels, four definitions of a lead | One intake, one definition | Every channel writes through the same service | | Duplicates found after assignment | Matching runs before a human is attached | Ordering, not better matching rules | | Routed by turn | Routed by who is licensed and available | Assignment reads permission as a control | | Stages set by adviser judgement | Stages tied to buyer-verifiable artefacts | Definitions agreed before anything was built | | Forecast rebuilt by hand each cycle | Forecast reads captured evidence | The pipeline produces the number as a by-product | The second-order effect is the one leaders notice: the conversation in pipeline review changes. When a stage requires an artefact, the question stops being "how confident are you" and becomes "has the credit decision been issued", which has an answer. ## What we would tell you before starting If your forecast is not trusted, do not start with the forecast. Start with what a stage means, get it agreed in writing by the person who owns the number, and be prepared for that to take longer than the build. Every implementation of this shape that goes badly goes badly there. And if the enquiry volume is genuinely low and the team is genuinely small, some of this is over-engineering. Three advisers sharing one inbox do not need routing rules. The design above earns its cost when volume, product complexity or a licensing boundary makes the coordination cost real. ## Questions ### Do we need Financial Services Cloud, or will Sales Cloud do? It depends on whether you need the relationship model. Financial Services Cloud earns its place when households, related parties and multiple products per person matter, because modelling that on plain Sales Cloud means building it yourself and maintaining it forever. If you sell one product to one individual with no relationship graph, Sales Cloud is honestly enough and the extra licence is not doing work. ### How long does this kind of intake and pipeline rebuild take? The build is rarely the long pole. Agreeing stage definitions with the people who own the forecast usually is, because it surfaces disagreements about what counts as qualified that predate Salesforce. We would rather spend two weeks settling that than ship stage names nobody trusts and revisit it in a quarter. ### Our reps say the CRM slows them down. Does this make it worse? It makes it worse if you add fields without removing any. Required-by-stage fields are only defensible when each one is used by someone downstream, so the work includes taking things out. If a field cannot be traced to a report, an approval or a regulatory obligation, it should not be mandatory. --- SynconAI. https://synconai.com/case-studies/lead-capture-to-scalable-sales-pipeline