Sales Pipeline Analysis
Sales pipeline analysis examines deal stages, activity dates, ownership and next actions to identify records that need attention. Use a consistent export and explicit review rules, calculate factual findings from the data, then add commentary that points back to the underlying deals.
This example produces an evidence-linked pipeline review from supplied records. It flags stalled activity and missing responsibility; it does not forecast revenue or synchronise a CRM.
By Ai Flowi · Published
example configuration, not a recorded test
documented in the catalogue; not production-tested by Ai Flowi
1. Choose the review question and snapshot
Decide what the report should help your team do: assign an unowned deal, verify an old next action, or examine why a record remains in a stage. Write each question as a check against an available field. An apparent pipeline problem can be an incomplete export, so distinguish a missing date from a date that is genuinely outside your review window.
Fix an explicit snapshot date and timezone for the analysis. Do not use the model’s assumed current date to calculate inactivity. Record the export’s scope, such as open deals or all deals, and retain that scope in the report. Comparisons between snapshots are meaningful only when their populations and field definitions match.
2. Prepare the export contract
You need an authorised CSV export, a workspace and an agreed pipeline review policy. Useful columns include deal identifier, stage, stage-entry date, last-contact date, responsible person and next action. Include an action due date only if the source system supplies one. Preserve deal identifiers as text so leading zeros and case are not lost.
Document the date format and what each activity timestamp means. A note edit is not automatically a customer contact. Empty stage-entry dates cannot establish time in stage, and a last-contact date without a timezone needs clarification before comparison. Keep original fields alongside any normalised review fields.
Use narrative commentary only when the factual review table needs explanation; a data-only report can end before any model call. Configure your provider account and API key via the model credential instructions, with commentary charges billed by that provider. The Load CSV reference defines ingestion inputs, rather than validating the pipeline review policy.
3. Load records and isolate data-quality gaps
Use the CSV loading instructions for the chosen export input, then inspect the resulting deal records.
In a synthetic pipeline review, deal A has an old last-contact date but an agreed future review recorded as its next action. Deal B has no last-contact date and no responsible person. A can appear in a stale-contact view without a claim that the relationship has failed; its scheduled review provides context for the salesperson. B belongs in a data-gap and ownership view, with inactivity unresolved. Combining both into one urgent-deal total would erase the difference between observed age and missing evidence.
At JSON Operations, the loaded deal records enter through data. Choose the "JQ Expression" operation and define query to reject unusable shapes, preserve deal identifiers and distinguish data gaps from business findings. Check date parsing against this export’s format; unsupported date representations stay in the exception list until their interpretation is resolved.
For stalled-activity checks, use the team’s chosen threshold and include the threshold definition in the report. A record without a last-contact date belongs in an unknown-date group. If a stage is excluded from review, say why. Avoid using a single unqualified “stalled” label that mixes stale activity, overdue actions and missing data.
4. Build a reproducible review table
Prepare a Table from accepted deal records with Data → DataFrame, supplying the list at data_list. Give that Table to Table Operations through df. For the unowned-deal view, operation uses "Filter" and column_name identifies the validated ownership flag. Choose its comparison with filter_operator, then supply the flag representation sought at filter_value.
For a next-action view, use a separate Table Operations step with "Sort", the chosen column_name and ascending. Keep rows with unknown dates visible in a separate exception view. The catalogue includes filtering and sorting; it does not list a group-by or aggregate operation, so do not describe this component as calculating stage totals.
Calculate any counts in a checked JSON Operations query and reconcile them to the accepted input population. Count records, not unique customers, unless you have explicitly defined and checked customer deduplication. A filter result should preserve each source deal identifier so a reviewer can return to the original record.
5. Add evidence-bound commentary if needed
The table-to-text formatting reference supplies the Parser contract for a report outline containing deal identifiers, flag reasons and source dates.
Configure Structured Output.output_schema with finding, affected identifiers, cited fields, missing information and proposed question. Its system_prompt should prohibit new amounts, dates, probabilities or outcomes. Connect the configured Language Model output to model. The model may explain a finding, but the deterministic review table remains the source of record.
Sales pipeline report automation often fails when a fluent explanation turns correlation into cause. If the export shows no contact after a certain date, report that observation. Do not claim that the prospect lost interest or the salesperson failed to act without additional evidence.
Related: Accounts receivable automation: review ageing from supplied records.
6. Review the report against the source
The report identifies its snapshot, accepted population, policy version, data-quality exceptions and flagged deals with source references. Inspect the structured commentary in Chat Output against the deterministic review table before circulation. Any deal identifier absent from that table needs correction or an explicit source-gap explanation; leave unanswered business questions visible.
Test an empty export, duplicate identifiers, an unknown stage, a date after the snapshot, absent ownership and missing next-action text. Acceptance requires that all accepted rows are accounted for and that data gaps do not become fabricated findings. If you add project status report automation, define project-specific dependencies and dates separately; a deal stage cannot stand in for project completion.
When comparing successive exports, distinguish an unchanged deal from a record that disappeared from the exported population. A deal missing from an open-deal snapshot may have closed, moved outside the export filter or been omitted by a changed source query; absence alone does not identify which occurred. Check the source record before describing it as won or lost. Retain the population definition and deal identifiers for both snapshots so the review can report observed membership changes separately from stage movement. This keeps a narrower export from looking like an improvement in pipeline health.
What are the limits and unsuitable uses of sales pipeline analysis?
Revenue forecasting, a live CRM dashboard and automatic reassignment are beyond this export review. A stale snapshot cannot establish a deal’s current state. If the source report already provides the required filters and counts, use that report and reserve this proposal for missing review commentary.
The documented use cases describe existing starting patterns, while the Sheets tutorial covers its own intake and write behavior. Neither establishes this export analysis. Keep missing ownership findings separate from qualification decisions, which answer a different sales question.
Pipeline snapshot fields and review-view settings
| Component | Exact input names | Settings to prepare | Output port |
|---|---|---|---|
| Load CSV | csv_file, csv_string | Load one authorised pipeline snapshot; choose the input appropriate to your export. | data_list |
| JSON Operations | data, operations, query | Pipeline flags and population counts follow the agreed snapshot-date policy in a checked "JQ Expression". | data_output |
| Data → DataFrame | data_list | Deal-review Table contains accepted identifiers, dated activity evidence and ownership flags. | dataframe |
| Table Operations | df, operation, column_name, filter_operator, filter_value, ascending | Use "Filter" for ownership exceptions or "Sort" for a defined action-date view. | output |
| Parser | input_data, mode, pattern | Format deal identifiers and factual flags for optional report commentary with mode "Parser". | parsed_text |
| Structured Output | input_value, model, output_schema, system_prompt | Generate findings tied to supplied deal identifiers, with missing information retained. | structured_output |
| Language Model | model, api_key | Configure provider access only when narrative analysis is required. | model_output |
| Chat Output | input_value | Inspect the source-linked report before sharing it. | message |
Usage for sales pipeline analysis
Plans: Go from USD8/month billed yearly (USD10 monthly), Plus from USD16 (USD20 monthly), Pro 100 from USD80 (USD100 monthly), Pro 200 from USD160 (USD200 monthly) and Pro 500 from USD400 (USD500 monthly), with 5,000 to 250,000 Flowi Tokens/month and top-ups; 1 token per node run; third-party API and model usage is not included.