Loading
Because a draft with no context needs rewriting. It reads well, gets the customer's situation wrong, and correcting it takes longer than starting fresh.
The useful part of most replies is the specific detail — what they bought, what is overdue, what was promised — which is exactly what a general model does not know.
Drafts are written from the customer's own record: what they bought in Flow, what is being delivered in Loop, what is outstanding in Books, what they last raised in Desk.
Every specific claim is linked, so checking is reading rather than verifying. The draft goes to a person, who edits and sends.
The five-minute reply becomes a thirty-second one, and the follow-up nobody had time for actually goes out.
Follow-ups get suggested from the record rather than remembered: a quote unanswered for two weeks, a ticket resolved without a check-in, a renewal approaching.
Nothing sends itself. There is no schedule that sends unreviewed and no setting to create one, on the rule that where a customer would find the error, somebody should see it first.
It also will not commit to anything. Prices, dates and exceptions are left for the person, because those are decisions rather than text.
Nothing here is an integration. Each line is two products reading the same record from different sides.
Drafts are written from the customer's own record: what they bought in Flow, what is being delivered in Loop, what is outstanding in Books, what they last raised in Desk.
The five-minute reply becomes a thirty-second one, and the follow-up nobody had time for actually goes out.
Nothing sends itself. There is no schedule that sends unreviewed and no setting to create one, on the rule that where a customer would find the error, somebody should see it first.
Fourteen days, every module, no card. Or half an hour with someone who will run it on your own records and tell you where it does not help.