Key outcomes
- Scope to solution: Two weeks
- Data foundation: Postgres-native and normalized
- Operating model: Shared technical and operational ownership
Context
A high-growth SaaS company depended on customer-health data to decide where the company’s customer-success team should focus, which accounts needed intervention, and how to coordinate the next action. But the system behind those signals had become harder to trust than the decisions the system was meant to support.
A legacy customer-success tool sat between the CRM, application, and Postgres. Records were remapped through an intermediary layer, source changes broke links, and health signals became stale or incorrect. Customer success had to validate the data before acting on the signals.
Dagny rebuilt customer health as a Postgres-native operating system: a trusted data foundation, a flexible interface, and a feedback loop that helps customer success investigate and act with more confidence.
Fragile health signals
- Source data
- Mapping layer
- Broken signals
- Manual checks
- Slower decisions
The legacy layer created recurring problems:
- Customer and product signals were remapped through a separate customer-health product.
- Source-schema and business-logic changes could break relationships between systems.
- Customer success encountered stale or incorrect account-health signals at the point of decision.
- Technical and operational ownership faded after the original implementation.
- End-user feedback was difficult to absorb without touching a fragile data layer.
The customer-health system
Dagny removed the brittle layer between source data and the customer-health experience. The new system sits directly on clean, normalized Postgres datasets, closer to the source of truth and easier to maintain as the business changes.
1. A Postgres-native foundation
Account, product, usage, and health signals were organized into normalized datasets instead of another remapped copy. This created a dependable foundation for health calculations and customer-success workflows.
2. A trusted operating interface
The customer-health UI brings together account health, the evidence behind each signal, and the next decision or action. The interface can evolve with end-user feedback without destabilizing the underlying data.
3. Shared ownership
The datasets and operating model were designed for both technical and operational stakeholders to maintain, creating clearer accountability after launch and reducing reliance on the original implementation team.
4. An upstream investigation loop
When a health issue appears, customer success and operations can move beyond the downstream symptom, trace the signal through the data flow, find the root cause, and improve the source logic or process.
- Trusted signal
- Investigate
- Trace upstream
- Improve
5. An agentic operating layer
Dagny connected trusted health signals to prioritization, investigation, and follow-up workflows. Customer health became an operating loop rather than a passive reporting view, with automation added where the team validates the loop’s value.
Connected systems
| System | Role in the system |
|---|---|
| CRM + application | Customer, commercial, product, usage, and behavioral context. |
| Postgres | Normalized system of record for customer-health data. |
| Customer-health OS | Account context, health evidence, prioritization, and feedback. |
| Customer success + operations | Human owners who interpret signals, investigate issues, and act. |
CRM + application, then Postgres, then Customer-health OS
- Customer action
- Feedback loop
Removing the unreliable mapping layer created a shared foundation that could improve without becoming fragile again.
Results
A trusted data foundation
Customer health now sits directly on normalized Postgres datasets rather than a separate mapping layer, making the logic easier to trace, maintain, and evolve as source systems change.
A working solution in two weeks
Dagny moved from initial scope to a solution that directly addressed the team's pain points in two weeks.
A maintainable ownership model
Technical and operational stakeholders have clear roles in maintaining the customer-health foundation and operating model after launch.
Faster learning from feedback
The flexible interface gives end users a way to shape the experience without destabilizing the core data foundation with every new workflow or question.
Before and after
Before: Health records depended on a fragile mapping layer
After: Customer-health data built on normalized Postgres datasets
Before: Broken links and stale records required manual checking
After: Traceable health signals with supporting evidence
Before: Ownership was unclear after implementation
After: Shared technical and operational ownership
Before: Teams saw issues only in the downstream health view
After: An upstream path to the root cause
Before: Feedback was difficult to incorporate safely
After: A flexible UI that can evolve independently
Before: Customer success validated data before acting
After: More time for interpretation and customer action
Customer voice
“Our team struggled with a legacy product that was more work to audit than the intended benefits. Dagny's solution is more flexible and addressed our pain points directly, all in the matter of weeks from our initial scoping.”
Director of Customer Success, High-Growth SaaS Company
Takeaway
Dagny turned customer health from a fragile reporting dependency into operating infrastructure: direct enough to trust, flexible enough to improve, and shared enough to remain maintainable as the business grows.
QBR Media
Riemer Insurance Group