Replacing Delighted With an Owned, Multi-Product NPS Infrastructure

Executive summary

Scratch needed to replace Delighted with an owned NPS infrastructure before the vendor path became a bigger operational risk.

The work was not a survey migration. It was a feedback data system tied to borrowers, loans, practices, products, customer states, automated follow-up, reporting, and Customer Success visibility.

I designed and built the owned NPS infrastructure across three survey systems:

• Borrower NPS in Salesforce Marketing Cloud.
• Practice relational NPS in HubSpot.
• Scratch Checkout NPS in HubSpot.

Each system served a different audience, but the architecture had one shared goal: connect feedback to the actual customer experience that produced it.

The limitations of the Delighted system

The existing Delighted setup worked like an external survey layer. It could collect scores, but it did not give the business enough lifecycle context.

The issues were practical:

• Surveys were sent in batches instead of triggered by meaningful customer events.
• Responses did not carry enough borrower, loan, practice, and product metadata.
• Reporting could not reliably reach loan-level detail.
• The business could not always connect a score to the exact borrower experience behind it.
• Detractor feedback did not automatically create a customer-recovery path.
• Promoters were not automatically routed into a public-review prompt.
• Survey frequency was hard to control across borrowers with multiple loans.
• Feedback could not easily inform lifecycle messaging, product decisions, or Customer Success follow-up.
• The company also had to plan around a June 2026 vendor sunset deadline.

The system Scratch needed looked more like this:

Customer experience
  |
  v
Survey eligibility
  |
  v
Survey delivery
  |
  v
Contextual response data
  |
  v
Score classification
  |
  v
Automated follow-up
  |
  v
Reporting and insight
  |
  v
Lifecycle and product decisions

That is the difference between collecting survey answers and owning the feedback loop.

Defining the owned NPS architecture

The architecture split NPS by audience and product context.

Borrowers
  |
  v
SFMC Borrower NPS
  |
  v
Loan-level and borrower-level reporting

Lending practices
  |
  v
HubSpot Practice Relational NPS
  |
  v
Practice response records

Checkout practices
  |
  v
HubSpot Scratch Checkout NPS
  |
  v
Shared response object with product segmentation

The point was not to force every audience into one survey.

Borrowers experience the financing journey as consumers. Practices experience Scratch as an operational and business partner. Checkout practices have a different product relationship from lending practices.

The system had to keep those contexts separate while still giving the company a common reporting model.

Designing Borrower NPS in Salesforce Marketing Cloud

Borrower NPS was tied to the loan lifecycle.

Instead of sending a survey through an arbitrary batch, the system started with a loan event and checked whether the borrower was eligible.

The timing model used an 80/20 split:

• 80% of eligible borrowers were surveyed 14 days after loan origination.
• 20% of eligible borrowers were surveyed 45 days after the loan event.

That split gave Scratch a way to compare immediate sentiment with later sentiment.

A borrower may feel one way shortly after origination and another way after more of the loan experience has played out. The 14-day path captures early experience. The 45-day path gives the business a later read.

Those two cohorts should be compared carefully. A timing change can change the observed score without the product experience actually changing.

Suppression and survey timing

The biggest design constraint was survey fatigue.

A borrower could only receive one NPS survey within a 90-day window. That rule had to operate at the borrower level rather than the loan level alone.

Filtering only by loan_identifier would miss the real problem. A borrower can have more than one loan or more than one qualifying event. If suppression only checks the loan, the same person can still get surveyed too often.

The suppression logic needed to answer:

• Has this borrower recently received an NPS survey?
• Has this borrower recently completed an NPS survey?
• Is the current loan event eligible?
• Should the borrower enter the journey or exit?
• When can the borrower become eligible again?

A simplified model looked like this:

Loan finalized
  |
  v
Find borrower_id
  |
  v
Check survey_send_history and response_history
  |
  +-- survey inside last 90 days
  |     |
  |     v
  |   exit and update suppression audit
  |
  +-- no recent survey
        |
        v
      assign 14-day or 45-day path

The practical pieces were borrower identity, response history, survey-send history, and the next eligibility date.

That made suppression auditable. If a borrower did not receive a survey, the system could show why.

Borrower response data model

The primary response Data Extension included these fields:

loan_identifier
borrower_email
nps_score
response_date
loan_type
days_to_survey
loan_origination_date
borrower_id
practice_id
nps_category
open_text_feedback
survey_sent_date
last_suppression_date
routed_to_review_prompt
routed_to_feedback_form

Each field had a job.

loan_identifier connected feedback to a specific loan context.

borrower_email supported communication and matching, but it should not be treated as the strongest long-term identity field.

nps_score held the raw score.

response_date let the team analyze trends by time.

loan_type made it possible to compare sentiment across product or financing types.

days_to_survey separated the 14-day and 45-day timing cohorts.

loan_origination_date anchored the response to the actual loan lifecycle event.

borrower_id made borrower-level suppression and analysis possible.

practice_id let Scratch connect borrower feedback back to practice relationships.

nps_category stored promoter, passive, or detractor classification.

open_text_feedback preserved the verbatim customer explanation.

survey_sent_date supported send history and suppression.

last_suppression_date made exclusion decisions easier to audit.

routed_to_review_prompt showed whether a promoter entered the review path.

routed_to_feedback_form showed whether a detractor entered the follow-up path.

One schema consideration matters here. loan_identifier is useful, but it should not automatically become the only primary key if the system needs to retain multiple survey attempts, multiple response events, or historical retries. Long-term, a separate response or send ID is cleaner.

Borrower NPS journey architecture

The journey behaved like a customer-state workflow.

Loan finalized
  |
  v
Check borrower eligibility and 90-day suppression
  |
  v
Assign 14-day or 45-day survey timing
  |
  v
Wait
  |
  v
Send NPS survey email
  |
  v
Capture score and open-text feedback
  |
  v
Classify promoter, passive, or detractor
  |
  v
Route follow-up
  |
  v
Update survey and suppression history

The journey was valuable because it did more than ask for a score.

It decided when the customer was eligible, preserved the context around the response, routed the customer based on score, and updated history so the next journey run had memory.

Closing the borrower feedback loop

NPS became useful when the score changed what happened next.

Promoters, passives, and detractors needed different paths.

Promoters

Promoters scored 9 or 10.

They entered a Google review request path. The system tracked whether the borrower was routed to the review request and whether the borrower clicked the review link.

The goal was simple: when a customer reports a strong experience, give them a clean next step for public advocacy.

Passives

Passives scored 7 or 8.

They did not need an automatic recovery or review-advocacy action. Their feedback still mattered for trend reporting, product insight, and qualitative review.

Detractors

Detractors scored 0 through 6.

They entered a feedback and Customer Success path. The system supported:

• Additional feedback capture.
• Contact tagging.
• Customer Success visibility.
• A defined expectation for follow-up within 48 hours.

That last piece matters.

Collecting a low score without creating a recovery path is incomplete. The customer already told you something went wrong. The system should make that visible to the team that can respond.

Practice relational NPS in HubSpot

Practice relational NPS targeted active lending clinics quarterly.

A lending practice was considered active when it had at least one loan application in the trailing 90 days.

The workflow needed to:

1. Identify active practices.
2. Check the last survey date.
3. Exclude contacts surveyed within the prior 90 days.
4. Send the practice survey.
5. Capture the response.
6. Create a structured response record.
7. Update the contact's survey history.
8. Make the response available to Customer Success.

Practice feedback had a different interpretation problem from borrower feedback.

The respondent's job title matters. An owner, veterinarian, practice manager, and front-desk employee can all experience the same product differently.

The system captured:

• NPS score.
• Response date.
• Job title.
• Hospital or practice name.
• Product segment.
• Open-text feedback.
• Respondent email.
• Survey type.
• Contact association.

That made the response more useful than a score sitting on a contact property with no context.

Scratch Checkout NPS in HubSpot

Scratch Checkout NPS targeted active payment clinics.

A Checkout practice was considered active when it processed at least $10,000 in transaction volume during the trailing 90 days.

The Checkout survey reused the broader practice-response object while distinguishing responses through:

• Product segment.
• Survey type.
• Practice association.
• Contact association.

That shared model mattered.

Lending and Checkout needed separate reporting, but the response infrastructure did not need to be rebuilt from scratch for every product. One response object could support multiple product contexts as long as product segment and survey type were captured cleanly.

HubSpot response object and data model

The custom response object included:

hs_object_id
association_to_contact__c
nps_score
response_date
job_title
hospital_name
product_segment
open_text_feedback
respondent_email
survey_type

Responses should exist as separate records instead of constantly overwriting properties on a contact.

There are a few reasons.

First, NPS changes over time. If the system overwrites the contact's latest score every quarter, the historical trend gets weaker.

Second, one contact can submit multiple responses over time. Separate response records preserve that history.

Third, object associations make reporting more flexible. A response can be tied to a contact, and a stronger future model can also tie it directly to a practice.

Fourth, product segmentation becomes cleaner. A contact may touch multiple Scratch products. The response record can say which product context the feedback belongs to.

The contact tells you who responded. The response record tells you what they said, when they said it, and which product experience created it.

Reporting and qualitative insight

Borrower NPS reporting included:

• Overall NPS.
• Promoter, passive, and detractor distribution.
• Month-over-month trend.
• Loan-type breakdown.
• 14-day versus 45-day comparison.
• Practice-type breakdown.
• Verbatim feedback themes.
• Suppression-health monitoring.

Feedback themes could include price, terms, approval speed, customer service, and product experience.

Automated theme classification should be treated as an extension unless it is confirmed live. The immediate requirement is to store open-text feedback in a structure that makes later theme analysis possible.

Practice NPS reporting included:

• Overall NPS.
• Score distribution.
• Twelve-month trend.
• Lending versus Checkout comparison.
• Region.
• Practice size.
• Job-title distribution.
• Response rate by segment.
• Qualitative feedback themes.

The reporting had to show both the score and the operating context behind the score.

NPS calculation and interpretation

NPS is not the average survey score.

It is calculated as:

percentage of promoters - percentage of detractors

A customer who scores 8 is not counted as a promoter. They are passive. That means audience composition matters.

Response rate also matters. If only highly satisfied or highly frustrated customers respond, the score can move without representing the full customer base.

Timing matters too. A 14-day borrower score and a 45-day borrower score may answer different questions.

That is why NPS should be reviewed alongside:

• Open-text feedback.
• Operational metrics.
• Product context.
• Response rate.
• Survey timing.
• Audience mix.

The score is a signal. It is not the whole story.

Migration and validation considerations

Replacing Delighted created migration risk.

The owned system needed:

• Historical backfill where useful and available.
• Parallel validation before fully trusting the new workflow.
• Data-quality checks between old and new reporting.
• Suppression validation.
• Response deduplication.
• Customer Success routing checks.
• Dashboard QA.
• A clear retirement plan for external sends.

The risk was not only technical. If the new system sends surveys too often, loses metadata, or fails to route detractors, the company owns a worse feedback loop than the vendor it replaced.

Lessons learned

Customer feedback gets more valuable when it is tied to the experience that produced it.

A survey system needs eligibility, suppression, routing, storage, and reporting. The score itself is only one piece.

Low-score feedback needs an operational response. Otherwise, the company collects dissatisfaction without doing anything useful with it.

First-party feedback infrastructure gives lifecycle, product, and Customer Success teams more flexibility than a disconnected vendor export.

Separate response records are better than repeatedly overwriting one contact property.

Survey fatigue has to be handled across customer identities, not only transaction records.

Different customer groups need different eligibility definitions. A borrower, an active lending practice, and an active Checkout practice do not produce the same kind of feedback.

Opportunities to extend the platform

The next layer would make the Voice of Customer system even more useful:

• Practice-level associations beyond contact-only associations.
• Automated text-theme tagging after validation.
• Customer Success work queues for detractor recovery.
• Product dashboards by borrower journey stage.
• Review-prompt performance tracking.
• Timing experiments beyond 14 and 45 days.
• Executive reporting that connects score movement to actual operational changes.

The important part is that the foundation supports those extensions.

Scratch moved from an external batch-survey process toward an owned feedback infrastructure that could connect customer experience, lifecycle automation, product data, customer operations, and executive reporting.