WEBVTT

00:00:00.100 --> 00:00:01.930
You know that moment when a ticket gets closed, but

00:00:01.940 --> 00:00:03.570
the customer says it's still broken?

00:00:04.480 --> 00:00:05.980
That's the gap Rectify handles.

00:00:06.620 --> 00:00:09.700
It connects the complaint to the engineering work, checks what

00:00:09.780 --> 00:00:12.250
actually works for that customer, and follows through.

00:00:13.080 --> 00:00:16.700
That means checking the customer's actual task, not just trusting

00:00:16.840 --> 00:00:18.820
a status update. Let me show you.

00:00:19.820 --> 00:00:20.920
Here's Maya at Northstar.

00:00:21.340 --> 00:00:22.740
Her CSV export is empty.

00:00:23.400 --> 00:00:27.160
We open her Gmail thread, and Rectify creates the case.

00:00:27.220 --> 00:00:29.420
These are clearly labelled local fixtures.

00:00:31.600 --> 00:00:33.040
Now we hit Investigate.

00:00:33.120 --> 00:00:35.880
A real model reads the complaint, checks the GitHub issues

00:00:35.900 --> 00:00:38.760
and Slack messages, then tries Northstar's export.

00:00:39.460 --> 00:00:42.380
And here's the catch: the issue is closed, but the

00:00:42.440 --> 00:00:47.810
export still fails. The server says the request worked.

00:00:48.470 --> 00:00:49.520
But the records aren't there.

00:00:50.120 --> 00:00:53.970
So Rectify saves the evidence, opens a customer-impact issue, and

00:00:54.060 --> 00:00:55.560
hands it to engineering in Slack.

00:00:56.380 --> 00:00:58.040
No resolution email goes out.

00:01:01.040 --> 00:01:04.739
Over in ReportDesk, a person enables the corrected export path.

00:01:05.300 --> 00:01:07.880
You can see the audit event and the new configuration

00:01:07.900 --> 00:01:11.800
revision. Back in Rectify, we recheck the same workflow.

00:01:12.460 --> 00:01:14.140
This time, it works.

00:01:15.720 --> 00:01:17.900
Now we can review the exact message Maya will get.

00:01:18.690 --> 00:01:22.000
Approval is tied to the recipient, the wording, and that

00:01:22.060 --> 00:01:25.980
passing check. Here, the local helper submits a signed Slack

00:01:26.020 --> 00:01:28.260
approval. Nothing is sent before approval.

00:01:28.900 --> 00:01:30.540
The worker confirms one send.

00:01:32.420 --> 00:01:34.690
But sending an email isn't the finish line.

00:01:35.350 --> 00:01:37.940
Maya opens ReportDesk and tries the export herself.

00:01:38.570 --> 00:01:39.860
There's the expected row.

00:01:40.540 --> 00:01:43.660
That real customer action creates the signed recovery event.

00:01:46.140 --> 00:01:48.890
And now she's recovered, with the follow-up updates confirmed.

00:01:49.330 --> 00:01:52.860
That's Rectify: not just a closed ticket, but a working

00:01:52.940 --> 00:01:55.500
customer workflow, with the evidence to back it up.