Pipeline cards, phases and tasks, plus the core system
First entry per stage, no duplicates, business hours
Funnel, conversion, losses and SLA by stage
Dashboard, AI agent and deadline alerts
What it solves
- The number of applications per stage matches the pipeline system, with no duplicates or test cards.
- Management sees where applications get stuck, with whom and for how many business hours.
- Losses and declines show up by reason, channel and partner.
Business questions it answers
Ask your agent these questions once the case is live.
What you need
- The pipeline system connected to Nekt (Pipefy, Zeev or a lending core system), with the phase or task history
- The mapping from phase to funnel stage, by product
- The team's working hours and the calendar of holidays and company-wide breaks
What you get
- A table per application with the date of first entry into each stage
- A monthly funnel by channel, partner and loan officer, with losses and open inventory
- An AI agent that answers questions about the pipeline with the right rules
- Alerts for tasks stalled past their deadline
Where to activate
Funnel by channel, partner and loan officer next to open inventory and business time per stage.
Answers about conversion, losses and bottlenecks with the stage mapping and exclusions already applied.
Tasks stalled past the SLA by analyst, refreshed every few hours in Slack or the team's email.
The bulk of the work is exploding the Pipefy fields and settling the phase mapping. The business-hours SLA requires the team's calendar. The detailed view has the business rules, the pitfalls and the acceptance test. Or send everything straight to your agent with the Nekt MCP.
A credit application lives across several pipes, each with differently named phases, custom fields packed into an array and duplicate cards when the customer comes back through another channel. Counting by current phase loses the month's history, and joining the core system without deduplicating inflates the funnel. For the SLA, measuring in calendar days and in UTC blames the analyst for weekends and holidays.
How it is usually done, and the rule
Each row is a mistake that already happened in practice.
Pivot the phase history (firstTimeIn in Pipefy) into one date column per stage, using the first entry. Pipefy custom fields come in the fields array and must be exploded and pivoted by field_id. The month's funnel counts the application in the month it entered each stage.
Map each pipe's phases to a fixed list of business stages, for example: lead, qualified, sent to credit, credit approved, legal review, signature and disbursement. Generate the complete month x channel x stage grid with zero where there were no applications, so the chart does not skip stages.
A card can move to Lost, come back and be lost again. For the loss month and reason, use the last entry into Lost (lastTimeIn), not the first. The reason comes from the main closing reason field.
Remove cards whose closing reason starts with duplicidade (duplicate), in any spelling (compare lowercased and without spaces). When the same CPF (individual tax ID) has several cards in the product, keep the card with the latest activity. Test and sandbox cards also come out.
The pipeline system is the source of the count. The core system or database comes in via LEFT JOIN from the card, after deduplication: one record per card id and one per normalized CPF (digits only), the most recent. Keep a column with how the match was made: by id, by CPF or no match. A raw CPF never goes into the final table, only hashed or masked.
Classify the channel by origin: paid media and the company's own website are B2C; correspondents and commercial partners are B2B. For a product that only comes through brokers or partners, the B2C and B2B split does not apply. Do not store a total row in the gold table; sum in the dashboard.
The credit amount on the card arrives as text '1.234,56'. Remove the thousands separator, replace the comma with a period and only then convert. A stage's VGV (gross credit value) is the sum of the amounts of the applications that reached it.
Time in a stage or task = business hours between start and end, within working hours (for example 9 a.m. to 6 p.m.), excluding weekends, national and local holidays and company-wide breaks, with half days where they apply (such as Ash Wednesday). A task still open uses now in America/Sao_Paulo as the end.
Tasks closed with a result of sending the request back come out of the stage time and go into the rework rate. When the same stage is done again, open a new execution block, and a sub-block when the assignee changes, to measure each pass by whoever did it.
Pipeline phase to funnel stage
Sample mapping. Each pipe and product has its own.
Definitions
Pitfalls that already happened
One pipe had two closing reason fields. Using both counted the same loss twice in the lost applications report.
Use only the main reason field.
In one product, the referrer field was filled on about 6% of cards, and conversion by person came out almost entirely without an owner.
Measure the fill rate and use the reliable role, such as the loan officer.
Lists of team emails and operator ids inside the transformation went stale with every hire, and the SLA silently lost people.
Keep the team in a connected table, with start and end dates.
A pipeline task was replaced by another one from a certain date, and the stage's historical series dropped by half.
Map the old and the new task to the same stage, with effective dates.
In the CRM, the pipeline recorded on the stage change event was not always the deal's current pipeline, and applications showed up in the wrong funnel.
Read the deal's pipeline, not the event's.
One product had no CPF on the card, and enrichment from the core system failed silently.
Flag those cards as no match and report the match coverage.
Acceptance test
The case is done when every item passes.
- For a closed month, applications per stage match the count of cards in the pipeline system with first entry in the month, already without duplicates and tests.
- Every month x channel x stage combination exists in the gold table, with zero when there were no applications.
- Each CPF appears only once per product, and no raw CPF appears in the final table.
- A task started Friday at 5 p.m. and completed Monday at 10 a.m. measures 2 business hours (9 a.m. to 6 p.m. working hours, no holiday).
- Sent-back tasks do not count toward the stage's average time and appear in the rework rate.
Agent package
Paste into Claude, ChatGPT or any client with the Nekt MCP connected.
Origination funnel and pipeline SLA - Source of the count: the pipeline system (<Pipefy/Zeev>). The core system only enriches via LEFT JOIN, deduplicated by card id and by normalized CPF (individual tax ID). - Each application counts in the month of its first entry into each stage. Fixed stages: lead, qualified, sent to credit, credit approved, legal review, signature, disbursement. - Lost: use the last entry into Lost and the main closing reason field. - Exclude cards whose reason starts with duplicidade (duplicate) and test cards. One card per CPF per product, the one with the latest activity. - Channel: paid media and website = B2C; partners and correspondents = B2B. There is no total row in the table; sum B2C and B2B. - The credit amount comes as Brazilian-formatted text: normalize it before summing. - Stage and task time in business hours, working hours <9 a.m. to 6 p.m.>, excluding weekends, holidays and company-wide breaks, time zone America/Sao_Paulo. An open task uses now as the end. - Sent-back tasks do not count toward the SLA; they count as rework. - Never show a full CPF. Use the hash or the masked CPF. Per-client exceptions: - <client>: the mapping from pipe <product> phases to funnel stages is in <table>. - <client>: SLA for stage <stage> = <N> business hours. - <client>: product <product> has no B2C channel; partners are brokers.
Build the "Credit origination funnel with SLA" case in my Nekt workspace following the rules at https://academy.nekt.com/en/industrias/financeiros/funil-originacao-credito.md. 1) Find the source tables and confirm the columns the rules use. 2) Create a transformation at the stated grain applying every rule. 3) Run the acceptance test and show me the result of each item. 4) Create the case's context document in the workspace, leaving my clients' exceptions open for me to fill in.
Variations
Most recent month's leads x average ticket of signed applications x conversion scenarios (pessimistic, base and optimistic).
Fixed probability by card temperature (approved by committee, hot, warm, cold); a card without a temperature takes the lowest.
The same business-hours SLA for claims awaiting an operations response and tickets by partner.