How I built a customer satisfaction platform in 1 week

I had no prior experience with this type of product, so I had to research several things. Among others:

1. Existing solutions. Competitive benchmarking to understand their products, feature sets, pricing models and target customers.
2. Industry terminology. CSAT, NPS, CES — standard concepts that form the foundation of this space and that I needed to understand.
3. User opinions about existing solutions. Reading what current or former users said on forums, Trustpilot and similar platforms was useful for understanding what they liked and what they did not.
4. Contact with agency clients. To find out whether they understood the value of running surveys, whether they had ever done any, and what their reasons were for doing or not doing them.
5. Conversations with the agency CEO and director. Once I had enough context, it was time to align and agree on the project scope.
6. Interviews with project managers and the head of sales. To identify the exact points in their existing workflows where triggering a survey would make the most sense.

• Many local business managers and owners understand the value of these systems, but cost and technical complexity stop them from implementing and actively using them.
• Most existing solutions have so many features that many users feel:
  • They are paying for more than they need
  • They are hard to use for their actual jobs
  • They are too technical in terms of setup, terminology, metrics, interpretation and automation
  • They require a marketing agency to manage them, which most of these businesses do not have

I started from four product hypotheses:

1. Multi-tenancy from day one The client, the entity and the end user could all be different profiles. If permissions and role hierarchies were not built into the MVP, the product would be much harder to sell to agencies, clinic groups or multi-location businesses.
2. Simplicity by default Most users did not want to configure surveys from scratch. They needed presets for common use cases, with advanced options hidden or progressively disclosed.
3. Non-technical language The product had to avoid concepts like triggers, webhooks or tokens in the main interface. Users needed to understand the system through their daily operations, not through its internal technical logic.
4. Automated delivery The value was not just in collecting responses, but in sending the survey at the right moment. If sending always depended on a manual action, the product would lose scalability and recurring usage.
5. NPS, CES and CSAT alone are not enough
   Limiting the product to those three standard survey types would waste the real opportunity. We were building a system that could handle any question-and-response scenario. Not allowing more use cases in the interface would be a missed opportunity.

Because speed was the priority, I relied only on these two frameworks:

1. User Journey Map (to understand the process and friction points)
2. Jobs To Be Done (to shape solution directions)

There were several perspectives to cover, but I focused on the 3 most fundamental ones, which encompass the rest:

1. The person creating surveys
2. The person responding to surveys
3. The person reviewing and interpreting results

From those conclusions, I identified the most specific set of required features.

The most significant architectural challenge was designing the multi-tenant model, where different types of potential clients and users had to coexist, each with their own roles and permissions.

The account and user structure that best fit the requirements looked like this:

Organization A
- Entity A1
- Entity A2
- Entity A3
- ...
Organization B
- Entity B1
- Entity B2
- ...

That way, a single Organization can cover a variety of use cases:

• A marketing agency that needs to run its own surveys and those of its clients.
• A company with multiple locations that needs both segmented and aggregated reporting.
• A company with only one location today but that may grow and need data separation later.

Two levels of access were supported:

• Access to all entities within an organization
• Access to one or several entities within an organization

Within those, individual roles and permissions made it possible to restrict access at nearly the feature level.

The first version was sketched on paper. Those iterations focused mainly on the survey creation experience and on how results would be consumed in the dashboard.

Statistics were without doubt the area with the most friction. We iterated with the team several times to find the clearest way to make survey results understandable for almost anyone.

Some edge cases we needed to address from the start were:

• What should happen if survey delivery fails?
  We implemented a retry and fallback system that lets each organization and/or entity configure which delivery channels to use, in priority order. If WhatsApp is priority 0 and it fails, the system retries a few minutes later. If it fails again, it falls back to priority 1. And so on until delivery succeeds.
• What should happen when a survey invitation expires?
  We observed that the time between the triggering event and the survey itself had to stay as short as possible, since both motivation to respond and the objectivity of answers decay quickly with each passing hour. For that reason, surveys expire after 24 hours, and users are informed if they open the link after that period.
• What should happen if a survey is left partially answered, without being submitted?
  • The person can still complete it by reopening the link within the 24-hour window.
    • It is stored under the metric category "Pending completion".
  • After 24 hours, if the user opens the link, they receive a survey-closed message.
    • It is saved as a "Partial response" and contributes to the "Abandonment" metric as an indicator for improving surveys.