Portfolio / Automation + data + AI
Five systems talking. One reading.
WeAnswer's customer success team read the state of an account by jumping between a CRM, spreadsheets, usage records and a ticket queue. We built the platform that pulls all of it together once a day: an n8n pipeline that reads, normalizes, joins, computes and — before publishing anything — adds the rows back up to check its own totals. On top of it, a private dashboard that goes from portfolio health down to the evidence behind a single account.
01The brief
The data existed. The reading did not.
A support team works with information spread thin: the CRM holds the commercial relationship, spreadsheets hold usage and billing, the ticket queue holds the complaints, and the team's memory holds the rest. None of those sources is wrong; the problem is that nobody reads them together.
With the sources apart, a risk signal shows up late and gets interpreted by feel, the weekly report is assembled by hand, and — most expensive of all — a missing number looks a lot like a healthy one. The brief was not “build a dashboard”. It was to build one shared reading of the portfolio that can be audited.
Sources coming in
- 01CRM · relationship and commercial state
- 02Spreadsheets · usage and billing
- 03Tickets · complaints and incidents
- 04Manual records kept by the team
- 05History from previous periods
Our role
Product design, n8n automation, the data and validation layer, endpoints and frontend. One team from source to screen — which is exactly what lets the screen explain where each figure came from.
02Architecture of the decision
Three readings, one truth.
The same information answers three different questions, and blending them is what makes a dashboard useless. The platform separates them and keeps the path between them open.
How is the portfolio today?
Portfolio and recurring revenue indicators, distribution by health state, volume trend, and the day's briefing with the team's priorities.
What needs attention now?
Actionable segments: high risk, open incidents, failed payments, insufficient activity, accounts with no recent contact, and accounts that are growing.
What holds that signal up?
History, usage against previous periods, associated complaints, billing state, a suggested next action, and the source of every field on screen.
03The principle
The rule the product answers to.
A blank is not a zero.
When a source does not answer, or a record cannot be tied to an account with confidence, the platform says so: unknown, unavailable, not enough signal to evaluate. It never turns that into a zero, and it never lets missing data read as a healthy account.
Everything else follows from there: numbers are computed with reproducible rules, the model writes and interprets but never fills gaps, and no total is published until the pipeline has recalculated it from the rows it came from.
ConsolidateValidatePrioritize
04The automation
From five systems to one portfolio.
The pipeline runs on its own, once a day, and every step leaves a trace of what it did. These are the systems it touches and what happens to the data between them.
Google Sheets
Usage and billingCRM
Commercial relationshipn8n
OrchestrationDeepSeek
Extraction and writingVercel
Endpoints and hostingWePro
The team's dashboard
- 01
Scheduled trigger
The run starts on the cadence the operation defines, and is logged with its timestamp and status.
- 02
Read the sources
Spreadsheet rows, CRM records, and the period's open and closed tickets are pulled in.
- 03
Normalize
Column names, dates, numbers, states and booleans move to one common shape — while keeping which source each field came from.
- 04
AI extraction
Tickets are processed in batches to pull type, severity, status, dissatisfaction signals and cancellation reasons out of free text. A failed batch is logged and partially recovered instead of taking down the run.
- 05
Join
Records are matched by identifier. When a match is ambiguous it is not forced: it is flagged for review, because attaching someone's complaint to the wrong account is worse than not attaching it.
- 06
Compute
Health, priority state, volume change, activity, coverage and aggregates. All deterministic and outside the model: the AI never quietly decides a total.
- 07
Validate
Before publishing, the pipeline recalculates the totals from the individual rows and compares them against the aggregates — sums, counts, duplicates, join rate and coverage. If something does not reconcile, it reports it instead of hiding it.
- 08
Briefing
With the validation report as controlled context, the model writes the day's executive summary and a data-quality note for whoever is operating.
- 09
Publish
Prepared data and the report are stored behind serverless endpoints and the dashboard asks for them fresh. Nothing is baked into the HTML or cached when the user needs the latest run.
- 10
Write back to the CRM
Computed fields can be written back to the CRM. It sits apart and stays switchable on purpose: an analysis run should never modify external records by accident.
Daily run · step 10 is switched on by hand
05AI with rules
The model reads and writes. It does not count.
AI goes where semantic reading and speed pay off, and stays out of anywhere a hallucination would cost a decision. That boundary is written into the pipeline, not into good intentions.
Free text into fields.
A complaint typed by hand becomes type, severity, status, intent to leave and competitor mentioned — fields that can then be filtered and read on the dashboard.
Briefing and data quality.
It writes where risk is concentrated, which accounts to prioritize, and what data limitations may be distorting today's reading.
Never patches a gap.
It does not estimate a missing value, does not average so a panel looks complete, and does not touch the totals. It gets the validation report as context and works inside it.
06The system
What runs every day.
The numbers that matter here are not traffic numbers, they are control numbers: how many sources come in, how many steps check them, and how long a session with access to the portfolio lasts.
- 5
- Connected systems
- 10
- Pipeline steps, one manual
- 1×
- Scheduled run per day
- 12 h
- Session lifetime
07Access and data
A client portfolio is not a public URL.
Authorized staff only.
The dashboard sits behind a team login, with sessions that expire after 12 hours. No session, no screen — and no data either: the information is requested after authentication rather than seeded into the HTML.
Keys never reach the browser.
Source credentials live in the automation environment. The endpoints publish prepared results and never expose access to the CRM or the spreadsheets.
Every run leaves a record.
Timestamp, status, validation verdict, ambiguous matches and per-field coverage are all logged. When someone disputes a figure, the conversation starts at the source instead of at an opinion.
08Visual system
Dark enough to watch all day. Color only where it means something.
Base surface
- HEX
- #0B1220
- RGB
- 11 · 18 · 32
Modules and tables
- HEX
- #121D30
- RGB
- 18 · 29 · 48
Action · Links
- HEX
- #2E7FE5
- RGB
- 46 · 127 · 229
Green · Yellow · Orange · Red
- HEX
- #22C55E
- RGB
- 34 · 197 · 94
Not enough signal
- HEX
- #64748B
- RGB
- 100 · 116 · 139
09Typography
One interface sans and one monospace.
Inter
Aa Bb Cc — 0123456789
SemiBold 600 · Bold 700
Inter
Aa Bb Cc — 0123456789
Regular 400 · Medium 500
Monospace
Aa Bb Cc — 0123456789
Regular 400 · Medium 500
Portfolio today.
clamp(34–56) · -3% · 700128 accounts · 92% coverage
40 / 40 · -2% · 700 · tabularAccounts at high risk
20 / 26 · -1% · 600Not enough data to evaluate this account: the usage source did not answer on the last run.
15 / 24 · 0 · 400Source · usage sheet · row 412
11 / 14 · 12% · 500 UP10The product
The door and the workbench.
The product's only public screen. Everything else requires a session, and the session expires after 12 hours.
| Account | Health | Recurring | Signal |
|---|---|---|---|
| Northwind Clinics | High risk | $— | Open complaint · competitor mentioned |
| Delta Field Services | Watch | $— | Volume −38% vs. last month |
| Harbor Legal | Follow up | $— | Failed payment · retry pending |
| Grove Dental | Healthy | $— | Usage rising · upgrade candidate |
| Unmatched record | Unevaluated | — | Ambiguous match · manual review |
Risk is concentrated in accounts with an open complaint and a volume drop at the same time. Six accounts went unevaluated because the usage sheet arrived incomplete — do not read them as healthy.
The dashboard's structure rebuilt with fictitious accounts: indicators, the portfolio sorted by signal, health state with its color, and the day's briefing. The client's real portfolio is not published.
11Engineering honesty
Automation cannot invent the data that is not there.
The platform is only as good as its sources, and it is better to say that out loud than to let a strange dashboard say it on a Monday morning. If a spreadsheet does not carry the CRM identifier, the join falls back to names and ambiguity appears; if a billing field is empty at the origin, no calculation can resurrect it.
So the system measures its own coverage and shows it. The improvement path is written and prioritized: stable identifiers across systems, complete operational fields at the source, a business rule for duplicates — one company can legitimately hold two relationships — and a quality history, so the team sees the trend rather than only today's snapshot.
Next on the path
- 01CRM id in every source
- 02Role-based permissions
- 03Data-quality history
- 04Exports for meetings
- 05Team feedback on each priority
How it is operated
Check the validation verdict, look at the ambiguous matches and the low-coverage fields, confirm the briefing is using today's run, and only then publish. The CRM write-back is approved separately, with the payload in view.
The work continues
A dashboard you cannot audit is an opinion with charts on it.
If your team works across a CRM, spreadsheets and tickets, and every meeting opens by arguing where a number came from, this is exactly what we build: the chain that joins them, checks itself, and shows its sources.
Tell us about your project