RevCollect

RevCollect is an accounts receivable and collections platform designed to help businesses understand, prioritise and recover overdue revenue.

The product is based on a simple observation: invoice collection is rarely just an invoice problem.

A late payment may involve several conversations, multiple invoices, an unresolved dispute, a payment promise, an internal dependency, or a customer relationship that must be handled carefully.

Most accounting systems record the financial status of an invoice. Email records the conversation. Spreadsheets track follow-ups. Team members remember informal commitments. Founders or finance leaders often have to combine these fragments manually to understand what is actually blocking payment.

RevCollect brings invoices, customer context, communication history, payment behaviour, promises and follow-up ownership into one operational workspace.

The frontend product has been built. Backend integrations, automation and operational validation are still being developed and refined.

Target organisations: SMBs and mid-market companies, particularly businesses with recurring invoices or relationship-driven collections.

Businesses often know how much money is overdue but not what needs to happen next.

An aging report might show:

• Customer name
• Invoice number
• Amount
• Due date
• Number of overdue days

That information is important, but insufficient.

It does not answer:

• Has the customer responded?
• Did they promise a payment date?
• Is there a dispute?
• Is the invoice waiting on an internal document?
• Who owns the next follow-up?
• When was the customer last contacted?
• Is the relationship sensitive?
• Are several invoices connected to one conversation?
• Is the customer habitually late?
• Which overdue amount is genuinely at risk?

As a result, teams create parallel systems:

• Accounting software for invoices
• Email for communication
• WhatsApp or calls for informal follow-ups
• Spreadsheets for ownership
• Notes for customer context
• Slack for internal escalation
• Calendar reminders for promises
• Founder memory for high-value accounts

This creates three major failures.

1. Context is fragmented

A team member opening an invoice may not know the full history of the customer relationship.

2. Accountability is unclear

The business may know that payment has not arrived, but not whether the next internal action was completed.

3. Automation becomes impersonal

Traditional reminder systems often send messages based only on overdue days.

They do not understand disputes, promises, prior communication or relationship sensitivity.

RevCollect is built around four core hypotheses.

1. Collections should be organised around customer conversations, not isolated invoices

A customer may have multiple invoices but only one active conversation.

2. Every outstanding balance needs a clear next action and owner

Overdue status describes the problem. Ownership creates movement.

3. AI should prepare work rather than autonomously control sensitive communication

AI can draft, summarise and recommend, but humans should remain responsible for messages that affect customer relationships.

4. Founders and finance leaders need an operational view, not merely a financial report

They need to see what is blocked, who is responsible and what is expected to arrive.

Studying the collection process

Accounts receivable workflows were explored beyond the accounting system.

A common process looks like this:

1. An invoice becomes due
2. The finance team checks the ledger
3. A reminder is sent
4. The customer replies through email
5. The customer asks for another document
6. Someone internally must provide it
7. The invoice remains overdue
8. Another reminder is sent without the full context
9. The customer makes a payment promise
10. The promise is stored in someone's inbox or memory
11. Leadership asks for an update
12. The team manually reconstructs the story

The failure is not always a lack of reminders. It is a lack of shared operational memory.

Understanding different collection styles

Collections vary across customer relationships.

A small low-risk invoice may justify a standard reminder.

A large strategic account may require:

• Account-manager involvement
• A personalised message
• Awareness of an unresolved delivery issue
• A carefully timed escalation
• Approval before contacting senior stakeholders

Therefore, a single automated cadence cannot handle every scenario equally well.

Reviewing collection products

Existing products commonly focus on:

• Automated email sequences
• Aging reports
• Payment links
• Dunning schedules
• Risk scoring
• ERP integrations

These capabilities are useful, but many products still treat an invoice as the primary object.

RevCollect explores a different organising principle: the customer conversation as the centre of the collection workflow.

Identifying suitable initial users

The product is particularly relevant for organisations where payment recovery depends on ongoing business relationships, including:

• Agencies
• Staffing companies
• Logistics businesses
• Distributors
• Manufacturers
• Professional-service firms
• B2B SaaS companies
• Other invoice-driven businesses

Insight 1: The aging report shows exposure, not operational reality

Two invoices that are both 45 days overdue may require completely different actions.

Design implication: Overdue days are displayed alongside communication, promises, disputes and ownership.

Insight 2: One customer may have several invoices but one negotiation

Presenting each invoice as an unrelated thread creates duplicate communication.

Design implication: Conversations are organised around customers, with multiple invoices connected to the same context.

Insight 3: Payment promises are operational commitments

A promised payment date should not disappear inside an email.

Design implication: Promises become structured objects that can be tracked, reviewed and escalated.

Insight 4: Internal blockers matter as much as customer silence

Payment may be delayed because the business has not sent a purchase order, corrected an invoice or resolved a dispute.

Design implication: The platform distinguishes customer follow-up from internal action.

Insight 5: Full automation can damage relationships

An automated reminder sent after a customer has already raised an issue creates friction.

Design implication: The system supports human-reviewed drafts and context-aware recommendations.

Traditional AR dashboard

The earliest form could have been an aging dashboard showing totals and overdue buckets.

This provides financial visibility, but not enough context for teams to act.

Automated reminder tool

A cadence-based tool could send reminders automatically after specified intervals.

This reduces repetitive work but risks sending inappropriate messages when context changes.

Collection task manager

Invoices could be converted into tasks with owners and due dates.

This improves accountability, but can separate the task from the customer conversation.

Customer conversation workspace

An inbox-style interface could combine:

• Email threads
• Customer details
• Connected invoices
• Payment promises
• Internal notes
• Recommended next actions

This form factor better represented how collection work actually happens.

AI collection agent

An agent could monitor invoices, detect risk, generate drafts and recommend escalations.

The challenge was determining the appropriate boundary of autonomy.

The product therefore treats the agent as an optional operational assistant rather than as the entire product.

Executive revenue view

Founders and finance leaders need a different level of information from collectors.

Their view focuses on:

• Total outstanding revenue
• Expected inflows
• High-risk accounts
• Blocked payments
• Broken promises
• Owner accountability

Final direction

RevCollect combines:

• An inbox-first collection workspace
• Customer and invoice intelligence
• Aging and risk visibility
• Structured follow-up ownership
• Human-reviewed AI assistance
• Executive accounts receivable oversight

The product is organised around the relationship between customers, conversations and invoices.

Primary areas

• Inbox
• Customers
• Invoices
• Aging
• Tasks or next actions
• Reports
• Settings

Customer as context

Each customer can include:

• Outstanding balance
• Connected invoices
• Payment behaviour
• Communication history
• Promises
• Disputes
• Internal notes
• Account owner
• Risk indicators

Invoice as financial object

Each invoice contains:

• Amount
• Due date
• Outstanding amount
• Status
• Payment history
• Connected conversation
• Relevant promises
• Next action

Conversation as operational object

The conversation brings together:

• Emails
• Drafts
• Notes
• Attachments
• Customer responses
• Follow-up history
• AI-generated suggestions
• Linked invoices

This structure prevents users from having to move repeatedly between an accounting tool, inbox and spreadsheet.

Flow 1: Reviewing the collections inbox

The user opens an inbox containing customer conversations requiring attention.

Each item can display:

• Customer
• Outstanding amount
• Latest message
• Number of overdue invoices
• Risk or urgency
• Last contact
• Next action
• Owner

The inbox prioritises action rather than showing messages chronologically without context.

Flow 2: Opening a customer conversation

The interface is divided into three functional areas:

1. Conversation list
2. Active communication thread
3. Customer and invoice context

The user can read the latest correspondence while simultaneously seeing:

• Outstanding invoices
• Payment history
• Promises
• Risk indicators
• Relevant notes
• Suggested next action

This reduces the need to open several systems before replying.

Flow 3: Preparing a follow-up

The user can request or receive a draft based on:

• Invoice status
• Customer tone
• Previous communication
• Promised dates
• Outstanding documents
• Escalation level

The draft remains editable and requires human approval before sending.

Flow 4: Recording a payment promise

When a customer commits to paying on a particular date, the user can record:

• Promised amount
• Promised date
• Related invoices
• Source message
• Notes
• Responsible owner

The promise can then be monitored.

If the date passes without payment, the system can surface it as a broken promise and recommend the next step.

Flow 5: Managing a dispute

A customer may challenge:

• Invoice amount
• Services delivered
• Purchase-order details
• Tax information
• Contract terms
• Supporting documentation

The dispute is recorded with:

• Category
• Status
• Internal owner
• Required action
• Related invoice
• Communication history

This prevents the platform from sending routine reminders while a genuine issue is unresolved.

Flow 6: Assigning the next action

Every collection case can have:

• Next action
• Owner
• Due date
• Priority
• Escalation level

The system distinguishes between:

• Contacting the customer
• Waiting for a reply
• Waiting for internal resolution
• Monitoring a payment promise
• Escalating to leadership
• Closing after payment

Flow 7: Reviewing a customer profile

The customer profile provides a longer-term view of payment behaviour.

It can include:

• Average payment delay
• Outstanding amount
• Historical invoices
• Broken promises
• Open disputes
• Communication responsiveness
• Collection difficulty
• Relationship notes

Flow 8: Reviewing aging and risk

Users can analyse outstanding invoices by:

• Aging bucket
• Customer
• Owner
• Risk
• Amount
• Invoice status
• Promise status
• Dispute status

Unlike a traditional aging report, each record can lead directly into the relevant operational context.

Flow 9: Executive oversight

The leadership dashboard can surface:

• Total outstanding receivables
• Amount expected soon
• Amount at risk
• High-value blocked payments
• Broken promises
• Accounts without recent follow-up
• Work assigned to each owner
• Potential recovery forecast

The objective is to answer not only "How much is overdue?" but also "Why, who owns it, and what will happen next?"

Workflow simulation

Because the frontend was built before full backend implementation, realistic collection scenarios were used to test the product structure.

Scenarios included:

• A customer with one overdue invoice and no response
• A customer with several invoices in one thread
• A disputed invoice
• A partial payment
• A broken payment promise
• A strategic account requiring careful escalation
• An internal document blocking customer payment

These simulations helped identify missing states and relationships between objects.

Inbox-layout exploration

Different layouts were explored for balancing communication and financial context.

A conventional email inbox made conversations easy to understand but hid invoice details.

A financial table surfaced amounts clearly but weakened the communication workflow.

The three-panel inbox structure was selected to preserve both.

Data-density testing

AR teams may handle many customers and invoices. The interface needed to communicate urgency without filling every row with badges and warnings.

Hierarchy was created through:

• Outstanding amount
• Aging
• Risk
• Last activity
• Next action

Secondary information remains available when the user opens the record.

Draft interaction testing

AI drafting was designed as an assistive action rather than a replacement for user judgement.

The user can:

• Generate a draft
• Edit it
• Adjust tone
• Review supporting context
• Approve it
• Send it when integrations are available

State modelling

Significant prototyping effort went into non-visual states, including:

• Awaiting customer
• Awaiting internal action
• Promise pending
• Promise broken
• Disputed
• Escalated
• Partially paid
• Paid
• Closed

Collections cannot be represented accurately through only "open" and "closed."

Using an inbox-first interface

Collections work is communication-heavy.

An inbox gives users a familiar mental model while connecting the conversation to financial context.

Tradeoff: Financial users accustomed to tables may initially expect the invoice list to be the primary screen.

Connecting multiple invoices to one customer thread

This avoids duplicate communication and mirrors real customer relationships.

Tradeoff: Individual invoice ownership becomes more complex when one conversation affects several invoices.

Keeping AI drafts human-approved

The product does not assume that an agent should automatically send every message.

Tradeoff: Human approval reduces the maximum possible automation rate, but protects relationship quality and accountability.

Making next action explicit

Every unresolved case should communicate what happens next.

This prevents records from remaining open without movement.

Separating customer outcome from employee action

An employee may complete every expected follow-up and still not receive payment.

The system should distinguish:

• Was the internal action completed?
• Did the customer pay?

This creates fairer accountability and more useful management reporting.

Treating promises as structured records

A payment commitment is more important than ordinary email text.

Making it structured enables reminders, tracking and escalation.

Designing the customer context panel as persistent

Users should not need to leave the conversation to understand the financial situation.

The side panel keeps essential customer and invoice information visible while the user reads or prepares a reply.

Accounting integrations

Invoice status, balances and payments may originate from systems such as QuickBooks or other accounting platforms.

Data synchronisation must account for:

• Delayed updates
• Partial payments
• Credit notes
• Duplicate customers
• Currency differences
• Manually edited invoices
• Deleted or voided records

Email threading

Customer communications may use different subjects, recipients and forwarding patterns.

Correctly connecting messages to customers and invoices is not trivial.

Multi-invoice conversations

A customer may discuss several invoices in one email, or one invoice across several threads.

The data model must support ambiguity rather than forcing a perfect one-to-one relationship.

AI context and reliability

Drafts must use the correct:

• Customer
• Invoice
• Amount
• Due date
• Conversation history
• Promise
• Dispute status

Incorrect context could create a damaging customer interaction.

Permissions

Different users may need different access levels:

• Collector
• Finance manager
• Founder
• Account manager
• Administrator

Sensitive financial and communication data must not be universally visible.

Auditability

The business may need to know:

• Who changed the status
• Who created a promise
• Who approved a message
• When the message was sent
• What the previous value was

Workflow edge cases

Collections involve many exceptions:

• Partial payment
• Payment made but not reconciled
• Multiple legal entities
• Wrong recipient
• Customer bankruptcy
• Duplicate invoice
• Internal write-off
• Credit adjustment
• Disputed tax
• Promise covering several invoices

The frontend must remain usable even as these states are progressively implemented.

The completed frontend currently establishes the product experience for:

• Collection inbox
• Customer conversation view
• Customer context panels
• Invoice details
• Multiple invoices per customer
• Aging visibility
• Customer profiles
• Risk-oriented dashboards
• Follow-up workflows
• Payment-promise tracking
• Dispute states
• Next-action ownership
• AI-assisted draft experiences
• Executive AR visibility
• Reusable design components and frontend architecture

The product interface and interaction model have been built, but it should not yet be presented as a fully operational collections system.

The following areas require continued implementation and real-world validation:

• Accounting integrations
• Email synchronisation
• Payment reconciliation
• Automated monitoring
• AI draft generation using live context
• Escalation workflows
• Notifications
• Permissions
• Audit history
• Real customer and invoice data
• Collection-impact measurement

RevCollect initially appears to be an overdue-invoice product. The deeper design problem is coordination.

Money remains unpaid while financial data, customer communication and internal responsibility live in separate systems.

The strongest product direction is therefore not to send more reminders. It is to create a shared operational memory for every receivable.

The frontend has allowed the team to define how this system should feel and how its primary objects should relate. It also exposed the complexity hidden behind apparently simple features.

A payment promise is not just a date. It is connected to a message, amount, customer, invoice and owner. A dispute is not just a status. It can suspend automation and create an internal task. A follow-up is not merely an email. It is one action inside a longer relationship.

The next phase must prove that the interface model holds up when connected to real accounting and communication data.

The critical measure will not be the number of automated emails sent. It will be whether teams understand outstanding revenue more clearly, act on it consistently, and recover payments without damaging customer relationships.