Cash Flow Copilot
An ongoing financial assistant on WhatsApp that forecasts cash inflows, flags shortfalls and helps managers decide what to do next.
BRL 399 / company / month
Explore the CopilotKaigoo / Product alignmentProduct review
Three products.
One cash flow operation.
Cash Flow Copilot is the core product. Partner Workspace brings it to companies through their advisors. Cash Flow Diagnostic gives companies a free starting point.
Partner Workspace
A workspace for accountants and advisory firms to manage their client portfolio and work within each company's financial context.
Free for partners
Explore the WorkspaceCash Flow Diagnostic
An automated diagnostic using ERP data to compare scheduled receivables with likely collections and quantify the gap.
Free for companies
Explore the DiagnosticProduct definitions and commercial terms from Designing the product for GTM, pp. 1–5 and WOW Pitch 2026.2 (EN), p. 8. These descriptions do not establish current product availability.
01
What does each product do?
The GTM plan defines three distinct roles: deliver recurring value, distribute the solution through partners and convert the initial experience into a subscription.
01 · CORE PRODUCT
Cash Flow Copilot
Anticipate cash shortfalls and support day-to-day financial decisions.
- Who it serves
- Business owners and finance managers who need to know when cash will be available.
- Commercial model
- BRL 399 per company per month. The pitch describes a subscription with no long-term commitment or implementation fee.
- Primary interface
- WhatsApp, through the Teteu assistant. ERP integrations retain the company's existing systems.
Product definition
A subscription to an ongoing financial assistant combining document capture, reconciliation and predictive intelligence. Liquidity monitoring and decision support are part of the same offering.
Capabilities
- Capture: processes documents, photos and audio, then prepares drafts for review.
- Reconciliation: matches bank data, accounting entries and supporting documents; discrepancies and exceptions require resolution and human approval.
- Forecasting and monitoring: predicts collection dates and monitors cash shortfall risk over 7-, 30- and 90-day horizons.
- Decision support: explains the issue, its cause and the proposed action; identifies the funding need, the receivables amount to bring forward and a reference rate for negotiation.
- Conversation: answers managers' financial questions in natural language on WhatsApp.
Kaigoo does not transfer funds, provide credit or act as a credit intermediary. Rates are indicative; companies negotiate with their chosen financing provider.
Related screens and journeys
C01–C03 · monitoring, alerts and conversation · C04–C06 · capture, approval and outcome
J3 · understand cash flow and act · J4 · submit, review and post
GTM · pp. 3–4, 6–7 · Pitch EN · pp. 4–6, 8 · Forecasting Engine · p. 1
02 · PARTNER CHANNEL / B2B2B
Partner Workspace
Help partners serve more companies with the same team.
- Who it serves
- Financial advisory firms, accounting practices and outsourced CFO providers.
- Commercial model
- Free for partners. Each client company pays for its own Kaigoo subscription.
- Primary interface
- A multi-company portfolio view, with access to each client's context and data isolated by Brazilian corporate tax ID (CNPJ).
Product definition
A workspace for managing a partner's client portfolio. It brings client companies together and provides access to each company's diagnostic and financial workflows, distributing the Copilot through accounting and advisory firms.
Capabilities
- Client portfolio: a view of the companies served by the partner.
- Company context: navigation from the portfolio to the selected client's diagnostic and financial workflows.
- Shared diagnostic: the Cash Flow Diagnostic supports consultative sales and ongoing client monitoring.
- Operational scale: automation of repetitive tasks to increase analyst capacity.
The materials target up to 40 companies per analyst. This is an ambition, rather than measured productivity or a contractual limit. Prioritization, filters and permissions require specifications to deliver the planned operation.
03 · ACQUISITION / ENTRY PRODUCT
Cash Flow Diagnostic
Expose the gap between cash scheduled in the ERP and cash likely to be collected.
- Who it serves
- Companies using ERPs that want to understand their exposure to collections arriving later than expected.
- Commercial model
- Free analysis. An initial experience of the value delivered by the Cash Flow Copilot.
- Interface in the current plan
- A diagnostic in the Console. The GTM plan defines the offering; the Console interface comes from the documented implementation context.
Product definition
An automated report using ERP data to compare receivables recorded at face value with forecast collections based on payment behavior. It exposes the cash that appears on the receivables schedule but may not arrive as expected, before the company subscribes to ongoing monitoring.
Capabilities
- Comparison: the scheduled receivables amount versus the amount likely to be collected within the period.
- Diagnostic: the gap between those expectations and its implications for interpreting receivables.
- Initial value: concrete evidence of the issue the Copilot monitors on an ongoing basis.
- Subscription path: a route to explore and subscribe to the Copilot; the commercial transition still requires specification.
The local implementation compares receivables per ERP app connection. Without bank balances and accounts payable in the calculation, its result does not represent the company's full net cash position. D01 and D03 cover fields, data coverage and presentation.
Related screens and journeys
R01–R03 · entry, diagnostic and subscription path
J1 · review the diagnostic · D01 · report content · D03 · data coverage · D02 · conversion
How the products work together
For owners and finance managers
Free Cash Flow Diagnostic to uncover the issue; Cash Flow Copilot for ongoing cash flow monitoring.
For accountants and advisors
Partner Workspace to serve the client portfolio; Cash Flow Diagnostic as the entry diagnostic; each company maintains its own subscription to the Copilot.
The two commercial entry paths are described in GTM · pp. 6, 8; per-company subscriptions are described in Pitch EN · p. 8.
Commercial definitions and delivery sequence
The Copilot is the core product. The first documented implementation step is the Diagnostic in the Console, followed by reuse in the Partner Workspace, forecasts and alerts, financial questions on WhatsApp, and capture with approval. This sequence organizes implementation. Launch requires the complete planned scope to be delivered and validated; an individual increment does not replace product delivery.
Review screens and status · Review user journeys · Review open decisions
02
Which screens are defined?
Delivery direction is established for the Diagnostic and its reuse in the Partner Workspace. The full inventory of screens, fields and layouts has not received blanket approval.
Established direction
The Console diagnostic uses the selected company's context and is part of the planned scope. The local implementation documents work completed to date; its existence does not establish complete delivery.
Still to specify or validate
Verify all planned report content, time horizons, organization by ERP app/company and communication of calculation limits. Validate the remaining work against the plan; the local 7/30/90-day implementation does not cap the scope.
Established direction
The earlier inspection documented sign-in, the Hub, ERP integrations, ingestion progress and a reconciliation queue. E03 groups modal dialogs, rather than additional pages.
Still to specify or validate
Use this foundation as implementation context. The inspection does not constitute redesign approval or demonstrate the complete financial operation.
Established direction
The second increment reuses the Diagnostic for partners. Portfolio management and invitations are documented as existing code.
Still to specify or validate
Specify the planned multi-company operation: metrics, columns, filters, prioritization, navigation and permissions. Portfolio management, access and diagnostic review must form the complete P01–P03 journey.
C01–C03 · Monitoring, alerts and conversation
Sequence approved; scope documented in the PDFsProduct: Cash Flow CopilotEstablished direction
Forecasts and alerts precede financial questions. The materials specify daily monitoring over 7-, 30- and 90-day horizons, with WhatsApp as a channel.
Still to specify or validate
Specify messages, horizon-specific rules, delivery frequency and any supporting Console interface. C01–C03 are touchpoints; they do not imply approval of three additional pages.
C04–C06 · Capture, approval and outcome
Delivery stage approved; design unresolvedProduct: Cash Flow CopilotEstablished direction
Document submission, draft creation, approval and ERP posting form the fifth increment. The PDFs require human approval and exception review.
Still to specify or validate
Define the review interface or channel, permissions, correction and rejection behavior, and distinguish ERP draft persistence from effective posting. Tarik has not explicitly approved the technical write sequence.
R01 / R03 · Entry and subscription path
Existing code + open decisionEntry through the Diagnostic; subscription to the CopilotEstablished direction
The inspected R01 code opens a WhatsApp sales conversation. The materials describe the free diagnostic and the path to the Copilot.
Still to specify or validate
Specify and validate the flow from diagnostic to offer, contract, automated billing and Copilot access. The existing sales contact does not replace this journey.
03
Which user journeys are defined?
The implementation sequence is documented. All planned journeys are part of delivery; their detailed specifications and acceptance criteria still require definition and validation.
Implementation sequence · complete scope
- Diagnostic in the Console
- Reuse in the Partner Workspace
- Forecasts and alerts
- Financial questions on WhatsApp
- Document capture, approval and ERP posting
J1First implementation authorized
Cash Flow Diagnostic · acquisitionReview the diagnostic
Sign-in → Hub → ERP connection → ingestion progress → Diagnostic is the documented local workflow.
To resolve: Implementation approval does not settle the commercial steps, report content or behavior when data is insufficient.
J2Reuse approved in the delivery sequence
Partner Workspace · distributionManage client companies as a partner
Portfolio → company → diagnostic is the direction for the second increment.
To resolve: Specify the liquidity view, navigation back to the portfolio and permissions required for the complete planned portfolio experience.
J3Commitment in the source materials
Cash Flow Copilot · ongoing decisionsUnderstand cash flow and act
Daily monitoring over 7/30/90 days → contextual WhatsApp alert → recommendation and questions.
To resolve: Tarik approved these deliveries' position in the sequence; notification rules, availability and the final UI remain unresolved.
J4Stage approved; workflow requires reconciliation
Cash Flow Copilot · financial workflowsSubmit content, review and post
Content → draft pending approval → outcome and reconciliation is the documented commitment.
To resolve: The PDFs place drafts in the ERPs. Tarik has not approved a technical sequence for persistence, effective posting and approval.
04
Decisions required to deliver the complete scope
The delivery commitment is established. The open items below specify how to implement and validate everything planned for all three products.
Tarik's direction · October 2, 2026
Deliver everything in the plan.
Launch criterion: complete planned scope, delivered and validated. The implementation sequence organizes the work; it does not authorize removing features, reducing report content or replacing the planned experience with a partial release.
Existing code is evidence of work completed. The product, screen and journey specifications define the delivery commitment. Implementation gaps remain work to complete.
Review product definitions and documented scopeDIAGNOSTIC
Specify the complete Diagnostic experience
D01Diagnostic · report content and presentation
How should the complete diagnostic be presented?
Specify the report that quantifies the gap between scheduled receivables and likely collections, making the cash timing mismatch clear.
Required scope
- An automated ERP-based diagnostic for the selected company, comparing scheduled receivables with forecast collections and quantifying the difference.
- The information required to interpret the result: reporting periods, model date, data coverage and calculation limits.
- A Console experience connected to sign-in, ERP integration, ingestion progress and the subscription journey.
Open specifications
Check fields and time horizons against the complete plan, then specify presentation, organization by ERP app/company and interpretation of the result. The local 7/30/90-day implementation is evidence to review; it does not define the product's scope ceiling.
Acceptance evidence
Trace each requirement to the report and validate its data, calculations and J1 journey. A receivables analysis must not be presented as the company's full net cash position unless bank balances and accounts payable are included.
D03Diagnostic · coverage and confidence
How should coverage, confidence and availability be represented?
Specify behavior for each data state, retaining the planned experience and an accurate interpretation of the diagnostic.
Required scope
- Identify the company/ERP app, data freshness, coverage and receivable records included in the calculation.
- Distinguish ingestion in progress, technical failure, missing data and a result calculated from partial coverage.
- Communicate statistical confidence and the use of industry benchmarks when payer-specific history is sparse.
Open specifications
Specify display criteria, messaging, the next action and recovery behavior for each state. Service availability, data coverage and statistical confidence each require distinct rules.
Acceptance evidence
Validate every planned state with evidence. Missing data must not be treated as zero. Label partial results explicitly and do not present them as completion of the full journey.
SUBSCRIPTION AND PARTNER CHANNEL
Complete the subscription flow and portfolio operation
D02Conversion · Diagnostic to Copilot
How should subscription follow the diagnostic?
Specify the complete path from free analysis to a recurring Copilot subscription.
Required scope
- A connected journey from Diagnostic results through the offer to Copilot subscription.
- Contract execution, automated billing and subscription confirmation, as planned in the pitch's commercial workstream.
- Per-company subscriptions, documented commercial terms and their relationship to product access.
Open specifications
Finalize screens, information, integrations and states for contracts, billing and activation. Confirm the deck's commercial wording against the current offer and specify WhatsApp's role in the journey.
Acceptance evidence
Validate the journey from diagnostic to subscription and corresponding access. Assisted sales can support the customer, but must not replace the planned contracting and billing flow.
D04Partner Workspace · client portfolio
How should the planned multi-company operation work?
Specify the partner's portfolio experience and the transition to each company's diagnostic and financial workflows.
Required scope
- Client portfolio, relationships, access and invitations specified in P01 and P02.
- Reuse of the Diagnostic and multi-company review of diagnostics and attention signals described in P03.
- Navigation between portfolio and company, retained context and data isolation by CNPJ.
Open specifications
Specify metrics, columns, filters, comparison and prioritization rules, and permissions against the plan. P03's design still requires validation; this decision must deliver that experience in full, rather than reduce it to a shortcut to individual diagnostics.
Acceptance evidence
Validate P01–P03 and J2 end to end, including navigation back to the portfolio and the boundaries of each role. The multi-company view must retain client data isolation; cash positions and ERP apps must not be aggregated without a defined rule.
FINANCIAL WORKFLOWS
Specify forecasting, conversation, capture and approval
D05Copilot · monitoring and conversation
How should complete monitoring and decision support work?
Combine forecasts, alerts and conversation into an ongoing experience that explains issues and supports action.
Required scope
- Daily monitoring over 7-, 30- and 90-day horizons, including predicted collection dates.
- Contextual alerts with the issue, its cause, the date and amount of the cash need, the next action and a reference rate where applicable.
- Financial questions and natural-language answers on WhatsApp, grounded in the company's context.
Open specifications
Specify horizon-specific triggers, calculation of the receivables amount to bring forward, notification rules, message updates and the supporting Console interface included in the design. Resolve source discrepancies before finalizing these rules.
Acceptance evidence
Validate C01–C03 and J3 using traceable data and rules, including answer availability and company context. A daily monitoring refresh does not, by itself, determine message frequency.
D06Copilot · capture and approval
How should review and effective ERP posting work?
Specify the complete workflow from submitted content to draft, approval, outcome and reconciliation, with clear side effects and responsibilities.
Required scope
- Receipt of supported content, data extraction and draft preparation.
- Human review with defined permissions, correction or rejection, and approval before an entry takes effect.
- A clear operation outcome, reconciliation and exception handling.
Open specifications
Validate the distinction between draft records and effective postings in each ERP integration. Specify the review channel, permissions and ordering of draft persistence, approval and posting. The PDFs place drafts in the ERPs; the technical discrepancy must be resolved with evidence.
Acceptance evidence
Validate C04–C06 and J4 end to end, including approval, correction, rejection and failure. The visible confirmation must match the actual effect in the ERP. Kaigoo does not transfer funds.
These six open items specify execution of the planned scope. None permits dropping features for implementation convenience. Completion requires evidence that the full planned journey works and has been validated; this document does not establish current production delivery.
+
Supporting detail for each decision
The complete inventory, workflows and source audit are available below. Expand the relevant section or follow a reference link directly to the cited item.
Complete screen and touchpoint inventory17 items · What users see, do and achieve
03
Screens and touchpoints
Experience inventory by product. An item may be a page, modal dialog, message or interface responsibility; it does not automatically require a new screen.
Access and infrastructure shared by all three productsEvidence from the earlier review
Shared access and operational foundation
Sign in, connect an ERP, track ingestion and select a company.
The user reported that onboarding had worked. The available evidence does not confirm the complete production journey or establish that the reconciliation queue constitutes the entire product.
Sees
Sign-in, email verification and registration completion, when required.
Does
Enters an email address, follows the sign-in link and completes registration.
Outcome
Access to the Hub and company context permitted for the account.
Earlier inspection described in the DOCX. COD · earlier code inspection
Sees
Companies, registration options and ERP connections.
Does
Selects an existing company or starts a new connection.
Outcome
The company's context or the start of onboarding.
Earlier inspection described in the DOCX. COD · earlier code inspection
Sees
Modal dialogs for companies and advisory firms, ERP connection validation and company identification.
Does
Enters connection details and a name, then selects "Get started".
Outcome
Data preparation begins. These are Hub modal dialogs, rather than additional pages.
Earlier inspection described in the DOCX. COD · earlier code inspection
Sees
Data preparation status within the Hub.
Does
Tracks progress; the local increment provides a "View Diagnostic" action.
Outcome
Data preparation visibility and access to R02 in the local implementation.
Earlier inspection described in the DOCX. COD · earlier code inspection
Sees
The day's queue items awaiting analysis.
Does
Reviews items and performs the corresponding human action in the ERPs.
Outcome
Progress in the financial workflow. This does not demonstrate autonomous execution or the complete draft lifecycle.
Earlier inspection described in the DOCX. COD · earlier code inspection
Documented routes: /entrar, /verificar-email, /completar-cadastro, /hub and /conciliacao. The /dev/progresso route is a development simulation and is excluded from the actual user journey.
Acquisition product · Cash Flow DiagnosticAcquisition
Cash Flow Diagnostic
Users review their company's diagnostic before deciding whether to subscribe to ongoing monitoring.
Sees
A sales call to action for the Diagnostic.
Does
Selects the button on the marketing page.
Outcome
Opens the sales WhatsApp conversation in the originally inspected version. This CTA did not demonstrate automated report delivery.
Earlier inspection described in the DOCX. COD · earlier code inspection · GTM · p. 5
Sees
Per ERP app: scheduled inflows, predicted collections and their difference over 7, 30 and 90 days, with the model date.
Does
Selects "View Diagnostic" in the Hub and reviews the selected company.
Outcome
Analysis of eligible receivable records. It does not cover the entire portfolio or full cash position; the actual query and complete journey still require validation.
The Console interface and 7/30/90-day horizons describe the local implementation; the PDFs do not prescribe this Diagnostic format. LOC · local implementation · GTM · p. 5
Sees
The next step after the free diagnostic.
Does
Decides whether to subscribe to the Copilot through the commercial flow that is approved.
Outcome
Transition to the recurring subscription, including the offer, contract, automated billing and confirmation. Interactions and integrations require specification and validation.
What the local increment documents
- The API and responsive interface were retained, with company access validation before the query
- Read access to estimador.p1_gatilho_diario, without rerunning the model or aggregating ERP apps
- Preview with synthetic data; the documented validation passed 1,522 tests, TypeScript checks, Biome checks and the build
Still unverified
- A query against actual financial data and the end-to-end user journey
- Deployment of the local Diagnostic to the Console
- Final report format, commercial delivery and insufficient-data handling
Partner product · Partner WorkspaceMulti-company
Workspace for partners
Move between the portfolio and individual companies, reusing the diagnostic and financial workflows.
Sees
The partner advisory firm's Hub and associated client companies.
Does
Selects the company to monitor.
Outcome
Enters the client's context within the user's access permissions.
Earlier inspection described in the DOCX. COD · earlier code inspection
Sees
Access management and invitation controls.
Does
Reviews or manages existing relationships.
Outcome
Access administration. An invitation does not, by itself, grant financial approval authority.
Earlier inspection described in the DOCX. COD · earlier code inspection · D04 · permissions
Sees
A multi-company view of diagnostics and attention signals.
Does
Selects a company and opens its diagnostic or financial workflows.
Outcome
Access to R02 and Copilot capabilities. Metrics, prioritization and navigation still require design.
The pitch describes free partner access and a separate subscription for each company. The Hub's presence in the code does not demonstrate the complete portfolio liquidity experience. PITCH · p. 8
Core product · Cash Flow CopilotRecurring value
Cash Flow Copilot
Understand cash flow, ask financial questions and manage financial workflows with human oversight.
Daily monitoring over 7/30/90 days and a WhatsApp experience are already specified in the source materials. Layout, notification frequency, detailed criteria and the division between conversation and Console require definition.
Sees
Daily projections over 7-, 30- and 90-day horizons, highlighting cash pressure.
Does
Reviews the forecast, the receivables amount to bring forward and the risk-based reference rate.
Outcome
Context for a financial decision. The product does not provide credit, transfer funds or guarantee outcomes.
Sees
A projected cash shortfall, including its date, amount and context or cause, in the planned WhatsApp experience.
Does
Reads the context and decides which issue to investigate.
Outcome
A next action and suggested receivables amount to bring forward, where applicable. The conceptual trigger is a deficit or funding need; horizon-specific rules and notification frequency remain unresolved.
Sees
A WhatsApp conversation within the company's context.
Does
Asks a question about the company's financial position.
Outcome
An answer in clear Portuguese, the documented product language, explaining the issue, its cause and a suggested action. A question does not authorize a financial operation; simulations and operational limits require design.
Sees
A conversation for submitting an invoice, boleto payment slip, Pix payment receipt, photo or audio. Actual media support has not been validated.
Does
Submits content from which a draft is prepared.
Outcome
The PDFs describe drafts persisted in the ERPs. The earlier document placed approval before execution; this does not establish an explicit decision by Tarik on the technical write sequence.
Sees
The draft and supporting information required for review. The review interface or channel and user roles are not yet defined.
Does
The manager reviews and approves; people resolve exceptions.
Outcome
An entry subject to human approval. Distinguish draft creation, effective posting and funds movement before specifying the integration.
Sees
Operation outcome and daily reconciliation of bank statements, accounting entries and documents, including discrepancies and exceptions.
Does
Checks the outcome and reviews exceptions such as interest, penalties and partial payments.
Outcome
Continuation of the financial workflow and the data feeding forecasts and alerts. The integrated workflow has not been validated end to end.
Source commitments and verified capabilities
The previously inspected WhatsApp handler recorded metadata and opt-outs. That inspection did not verify media processing, financial AI, drafts, approval or execution. The absence of evidence in that inspection also does not establish absence across the entire system.
Journey diagrams and stepsJ1–J4 · Paths, dependencies and boundaries
04
Complete journeys and their boundaries
Each step links to the inventory above. The diagrams describe the experience and its dependencies; they do not certify production functionality.
J1
A company requests and reviews the Diagnostic
Goal: connect an ERP and obtain a useful view of likely collections.
E01 · Sign-inSign in by email
E02 · HubSelect or register a company
E03–E04 · ERP connectionConnect and track ingestion
R02 · DiagnosticReview the local Diagnostic
R03 · Subscription pathEvaluate the Copilot
This path combines the documented foundation with the local increment. R01's sales entry point opens WhatsApp; the connection from that conversation to the Console remains unresolved. The transition from R02 to R03 is a commercial decision, rather than an implemented subscription flow. D01 · D02
J2
A partner monitors the client portfolio
Goal: reach the correct company's context while preserving access boundaries.
E01 · Sign-inIdentify the partner
P01 · PortfolioFind associated companies
P03 · LiquidityProposed multi-company view
R02 / C01 · CompanyDiagnostic or financial workflows
P02 supports relationships and access. Viewing, editing and approval permissions require separate rules. P03 reuses the diagnostic and financial workflows, but its metrics and interactions have not been approved. D04
J3
Understand cash flow and decide
Goal: turn forecasts, alerts and conversation into an informed decision.
SubscriptionCommercial transition to specify
C01 · Monitoring7/30/90 days; daily refresh
C02 · AlertAttention signal on WhatsApp
C03 · QuestionClarify the financial position
Forecasts, alerts and questions complement one another; they do not form a mandatory four-screen sequence. The product provides guidance on the amount needed and an indicative rate, without providing credit or transferring funds. PITCH · p. 4–6 · EST · p. 1
J4
From submitted documents to financial workflows
Goal: reduce manual work while retaining human review and exception handling.
C04 · ContentDocument or audio on WhatsApp
DraftPDFs: persisted in the ERPs
C05 · ApprovalManager reviews and approves
C06 · OutcomeTrack reconciliation
Errors and exceptionsThe materials assign responsibility to people. Correction, rejection, resubmission and failure messaging still require design.
After approvalDefine what is posted in the ERPs, the confirmation returned and how duplicates are prevented. This is an integration decision, rather than authorization to transfer funds.
The PDFs explicitly describe an ERP draft pending approval. The earlier document describes draft creation, approval and ERP recording, without establishing an explicit decision by Tarik on the technical write sequence. Draft persistence and effective posting must not be assumed to be the same operation. Resolve the distinction before implementing the integration. PITCH · p. 4 · GTM · p. 6–7 · D06
Reading the evidenceSource, maturity and limits of each claim
02
What the evidence labels mean
These labels describe the evidence behind this product map. They are not states that must appear in the customer interface.
Requirement in the source materials
An explicit commitment in the attached PDFs. It does not establish that the capability works in production.
Code documented in the earlier review
Behavior identified in the earlier inspection and described in the DOCX. The code was not re-audited for this version.
Local implementation increment
A recent implementation retained locally. Technical checks do not establish validation of the actual user journey.
Proposed experience
A proposed structure or behavior for discussion. It does not constitute approval of an additional screen.
Open decision
A decision requiring product, business or engineering validation before it can be finalized.
Conversation context
Implementation context and user direction given after the PDFs. Conflicts are surfaced rather than removed.
This review read the three PDFs directly. Code and local implementation evidence comes from the earlier document, with its limitations retained.
Source audit and discrepancies10 corrections · 10 source discrepancies
05
Source audit
A direct reading of the three PDFs compared with the earlier document. The corrections below distinguish commercial commitments, technical evidence and subsequent decisions.
The three-product structure is supported
The Copilot is the core product; the Workspace serves the partner channel; the Diagnostic is the acquisition product. The Forecasting Engine is a shared capability, and the five increments define the implementation sequence.
The sources do not agree on every detail
Readiness, triggers, statistical weights and ERP draft timing contain explicit inconsistencies. None has been silently treated as an implemented requirement.
Corrections applied to the product map
A01
The Forecasting Engine is included in the product foundation
Earlier documentThe third source was missing from the reference set, leaving part of the intelligence capability undocumented.
This versionThe shared engine and its limits are included in the architecture. Complete liquidity monitoring includes current balance + expected collections − accounts payable, rather than predicted inflows alone.
A02
Copilot monitoring has documented horizons and a channel
Earlier documentC01, C02 and D05 previously left the channel and time horizons entirely open.
This versionThe sources specify daily monitoring over 7/30/90 days and WhatsApp. A supporting UI, notification cadence, precise triggers and horizon-specific rules remain under discussion.
A03
Alerts must support a decision
Earlier documentAlerts were described only as signals to investigate.
This versionThe specification now includes the issue, cause, shortfall date and amount, next action, suggested receivables amount to bring forward and a reference rate where applicable. This does not imply credit provision or funds movement.
A04
The automated Diagnostic differs from the local prototype
Earlier documentChannel and format were left entirely open, while the local implementation used the Console and 7/30/90-day horizons.
This versionThe GTM plan specifies a free automated report. It does not fix detailed time horizons or the delivery channel; the Console and per-app 7/30/90-day calculations remain identified as local implementation choices.
A05
Commercial terms and data isolation are included
Earlier documentThe main product map omitted pricing, free partner access and data isolation.
This versionThe pitch describes a Copilot subscription at BRL 399 per company per month, with no long-term commitment or implementation fee; a free Partner Workspace; separate company subscriptions; and data isolation by CNPJ. These are source terms, rather than evidence of current commercial availability.
A06
ERP drafts: the discrepancy is explicit
Earlier documentC04/C05/J4 previously placed approval before any ERP operation.
This versionThe PDFs place drafts in the ERPs before they take effect, subject to manager approval. The earlier document placed approval before execution. That wording does not establish an explicit decision by Tarik; persistence, effective posting and approval must be reconciled.
A07
Conversation and reconciliation reflect the complete commitment
Earlier documentQuestions and outcomes were described generically; the existing queue risked standing in for the full commitment.
This versionAnswers must explain the issue, cause and action. Daily reconciliation matches bank statements, accounting entries and documents, with human exception review. The current queue does not establish delivery of that commitment.
A08
Two acquisition paths; a separate source for existing code
Earlier documentThe commercial structure and implemented screens were presented without a clear distinction.
This versionThe GTM plan recommends separate entry paths for owners/managers and accountants/advisors. The Hub, email sign-in, modal dialogs, invitations and routes come from the earlier code inspection, rather than prescriptions in the PDFs.
A09
Sparse history still has documented fallback rules
Earlier documentD03 previously left all data handling unresolved.
This versionThe sources document a blend of payer-specific and industry data, a fallback at n=0 and sample-based confidence. These rules do not resolve missing balances, accounts payable or ingestion, or validate the complete diagnostic.
A10
Implementation status is updated without asserting delivery
Earlier documentThe DOCX described engineering as paused pending review and cited local tests as evidence.
This versionThe latest direction resumed local engineering in parallel. The blueprint remains under review; tests, marketing claims and the existence of code do not establish production delivery.
Discrepancies and limits within the source materials
These issues remain visible for review. The audit does not choose a technical interpretation without additional evidence.
V01
Readiness of alerts, rate guidance and collections
The report describes available analytical assets, but also lists alert activation, rate guidance and collections as next steps. The English pitch describes the product workflow and states that the engine, pipeline and WhatsApp channel are in production; contracts, automated billing and monitoring appear as work still to complete. Finding: the commitment is documented; this review does not demonstrate complete current delivery to customers.
V02
Which horizon triggers and sizes the alert?
The report references 7/30/90 days, but explicitly defines valor_necessidade_caixa = abs(caixa_projetado_90d) and mentions 30/90 days in its next steps. It does not define a consistent contract for each horizon. To specify: the field, sign convention, amount calculation and deduplication rule.
V03
A conversation example does not define the algorithm
The pitch illustrates a BRL 18,400 deficit and a suggestion to bring forward BRL 12,000 in receivables, without explaining how one amount produces the other. It explicitly identifies names and amounts as fictional. Do not infer a formula, calibration method or risk rule from this example.
V04
Draft persistence versus effective posting
The PDFs place drafts in the ERPs; the earlier document places ERP recording after approval. Neither source verifies the API mechanism. Retain human approval and specify the sequence before implementing writes to an actual ERP.
V05
The reported figures have different scopes and dates
The Forecasting Engine report and pitch use different volumes, entities and portfolios. The pitch includes a September 2, 2026 snapshot; the GTM document also abbreviates "payers and suppliers". Do not combine these figures into growth claims, current totals or customer metrics for this site.
V06
No payment history: commercial risk and statistical fallback
The report classifies missing history as critical under its commercial policy while also describing an industry-based statistical fallback. These may be distinct policies. Reconcile confidence, risk and user messaging; missing history does not establish default.
V07
The formula does not support 90% with 30 purchases
The presentation claims 90% payer-specific history above 30 purchases and 100% personalization. However, n/(n+12) yields 71.43% at n=30 and reaches 90% only at n=108. Explicit inconsistency: do not repeat those percentages as mathematical facts.
V08
Accounting checks do not guarantee predictive performance
Accounting conservation, distribution normalization and a claimed absence of temporal leakage do not demonstrate accuracy or calibration on future data. Describe forecasts and estimates, without promising exact collections, no false alerts or guaranteed outcomes.
V09
Acquisition cost and scale are targets or estimates
The sources differ on acquisition cost ranges and baseline analyst capacity, while retaining a target of up to 40 companies. Do not present them as measured CAC reductions, verified productivity or contractual limits of the Partner Workspace.
V10
Risk scoring and collections span existing assets and planned work
The report describes a risk score and a preventive collections sequence; collections deployment also appears as a next step. Do not recast these as a fourth product, a mandatory additional screen or a newly approved increment.
Sources and traceabilityThree PDFs · Earlier document · Existing evidence
07
Sources and traceability
References use physical PDF page numbers. The audit checked the attached documents; it did not revalidate repositories, databases, metrics or the production product.
Designing the product for GTM.pdf
12 pages; content on pp. 1–8. Pages 9–12 were checked and are blank.
pp. 1–5: roles of the three products · p. 5: free Diagnostic and automated report · p. 6: two commercial entry paths · pp. 6–7: capture, drafts and reconciliation.
Kaigoo · WOW Pitch 2026.2 (EN).pdf
16 pages. The English version supplied for this review was checked on October 2, 2026. It replaces the earlier version's Portuguese pitch reference. Commercial terms and metrics belong to the deck's dated snapshot.
pp. 4–6: capture, reconciliation, forecasting, human approval and conversation · p. 8: BRL 399 per company per month, free analysis and free Partner Workspace · pp. 9, 11: channel and commercial development · pp. 13–16: historical data and glossary.
RELATORIO_EXECUTIVO_ESTIMADOR.pdf
4 pages. The formula, table and diagram on pp. 2–3 were checked visually.
p. 1: liquidity calculation and recommendations · pp. 2–3: risk, confidence, payer/industry blending and weights · p. 4: next steps. Inconsistencies between commitments, status and formulas remain documented in V01–V10.
Kaigoo_produtos_telas_e_jornadas.docx
The earlier eight-page document audited here. It is retained as a reference; this version is the requested website.
IDs E01–E05, R01–R03, P01–P03, C01–C06 and J1–J4 are retained for traceability. Code and local work described in that document are prior evidence, rather than a new inspection.
Code inspection documented in the DOCX
An earlier inspection, not repeated in this audit. The existence of a component does not establish end-to-end delivery.
Console: CtaSection.tsx, onboarding/empresa/route.ts, OnboardingModal.tsx, hub/page.tsx, progresso-store.ts, fila-do-dia.tsx and whatsapp-inbound.ts. Intelligence layer: forecasting models identified in the earlier inspection.
Local Diagnostic increment
An earlier record, subject to engineering resumed in parallel. This review does not verify a query against actual data, production deployment or the complete journey.
EmpresaBloco.tsx · RaioX.tsx · API /api/raio-x · read access to estimador.p1_gatilho_diario · branch codex/raio-x-v1. Documented checks: 1,522 tests, TypeScript, Biome and build. These checks do not establish access to actual customer data.
User conversation context
Tarik approved the five-increment sequence and the resumption of local engineering in parallel. Initial work on the Diagnostic in the Console was authorized; this does not constitute blanket approval of layouts, fields or time horizons.
The three-product structure comes from the PDFs. Interface details and the technical ERP write sequence have not received blanket approval from Tarik. Source discrepancies do not authorize product deployment, funds movement or additional permissions.
Direction given on October 2, 2026: deliver the complete planned scope. Open decisions specify how to implement and validate it; they do not authorize feature cuts, feature deferrals or substitution with a partial release. Launch requires completion of the full plan. View scope direction and execution specifications.
Product terminology: specific vendors named in the materials are represented by the category ERPs. The audiences are companies and advisory firms. Technical coverage depends on the integrations actually delivered.
Scope of this website
This site is a product alignment document. Publishing it does not deploy the Kaigoo product or enable financial operations. Actual customer data was not used as a functional demonstration.
Demonstration data supports technical validation and is not a manual step required of customers. There is no evidence that customers must prepare synthetic data to use the journey.
Repositories cited in the earlier document: techteu-console and camada-inteligencia-kaigoo. Access depends on the account's permissions.