Feedback Follow-Up

Feedback that piles up in one inbox and gets closed with a thank-you, while nobody can say how many promised follow-ups were actually kept, is the case for this journey. Ahead of launch, every piece of feedback must be classifiable by type, responsible teams and their service levels must be defined, a record field must confirm when a promised action is complete, and the person must be reachable by email or push. If the complaints are concrete problems with a delivered product or service, the remedy route belongs to the Post-Purchase Issue Resolution journey; this one does not replace it.

Promised-action completion rate

What this journey promises is that a promised follow-up actually happens; counting thank-yous or answers sent says nothing about that until the action is done.

How it is counted: No control group; the measurement runs on the records that entered: the denominator is every record where a follow-up or action was promised to the customer, the numerator those whose action is verified complete within the same follow-up window, including completions after the reminder, with SLA adherence read separately. A reply having been sent does not count as completion.

Also track

• Share of records with a promiseOf all entrants, the share that leave classification with a promised follow-up or action; if feedback that needs no action lands in this share, you are creating work. Read the type split alongside it.
• Reminder and escalation rateAmong promised records, the share that needed a team reminder, the share escalated to the manager and the share still open when automatic follow-up ended; a rise means the SLA does not match the team's capacity or is not being tracked.
• Repeat complaints and support contactsNew support contacts or complaints on the same topic after a closure notice went out; they show a sent reply being mistaken for a resolved issue.
• Positive feedback routed to an invitationPositive feedback found appropriate and routed to the review / referral opportunity, as a share of all positive feedback; positive feedback is not permission to publish a review, and the invitation's result is not counted here.

• Trigger and entryThe journey starts when feedback arrives and is split by type. There is no control group: the thank-you, answer and closure messages do not move the measured outcome, whether the team keeps its promise, and leaving a question unanswered is not worth testing. Measurement therefore runs against the entry population.
• Who must not enterA concrete, known problem with a delivered product or service belongs to the Post-Purchase Issue Resolution journey; do not reassess the remedy route here. Requests that have not produced an answer stay in the Feedback Request journey. One feedback record per instance; no second flow opens for the same record.
• Timing and channelsNo fixed wait. Positive feedback gets a thank-you, a suggestion an acknowledgement, an information request an answer or support route, other feedback an acknowledgement when warranted, all by email or push; complaints and bug reports become a team task with no message. After a promise, the SLA is awaited and completion triggers a closure notice.
• Exit and handoffWithout a promise, the record closes after the first message. A promised action completed within the SLA triggers the closure notice and closes the record; a missed SLA reminds the team once, and a missed renewed deadline escalates to the manager. Automatic follow-up ends there, but the record stays open until resolved; no handoff.
• Frequency and consentTwo messages at most reach the customer: the first answer or acknowledgement and the closure notice, each through the person's available email or push channel. The team receives the task, one reminder and, if needed, the manager escalation; feedback that needs no action creates no task.

1. 1Do not read the completion rate on its own: a record closed because a reply was sent does not count as complete and inflates the rate. The number of thank-you or acknowledgement messages sent says nothing about whether the journey works; the test is whether a given promise is actually fulfilled, and records that missed their SLA show up separately in the reminder and escalation rate.
2. 2This reading holds for this classification and the two-step escalation. The remedy for a concrete problem with a delivered product is credited to the Post-Purchase Issue Resolution journey; never track the same record in both flows. The Feedback Request journey ends once the request is sent, so an incoming answer enters here only.
3. 3To compare two teams, or the period before an SLA change with the period after, enter each arm's promised records as visitors and its completed records as conversions into the A/B test significance calculator; it only compares the two rates and knows nothing else that changed between the periods, so do not change the process on a difference seen across few records.
4. 4Promise only an actual decision and schedule in reply to a product suggestion; routing it to the backlog is not a development promise and should open no record. Never treat positive feedback as automatic permission to publish a review.