Missed calls: auto-SMS with the real ship date instead of a canned reply

The key finding: the order has no ship date

The central question of the whole pipeline is where to get a date you're not ashamed to send a customer. It turned out that a calendar ship date does not exist anywhere on the Shopify order. Four other candidate sources were checked and rejected — none of them carries the date the customer was actually promised.

The only carrier of that promise is the name of the shipping tier chosen at checkout: that's where the buyer saw a timeframe and agreed to it. The date is derived from that string. This is the kind of project where two weeks of work hinge on one design decision — and you have to find it before writing code.

The reply ladder: from useful to fallback

The reply is assembled in steps, from maximally specific down to neutral, and no step is allowed to lie:

• customer and order found, promised date still in the future → state the date
• promised date already passed → do NOT repeat it; say plainly that we're checking with the warehouse
• order exists but no date can be derived → reference the order without inventing a promise
• no customer matched the number → neutral reply, the call goes into the human queue

The "never repeat an overdue date" rule was validated against the historical export (over 11k orders): not a single old, stuck order gets handed a future date.

Safety rails on sending

An auto-SMS goes out under the business's name with no human in the loop. That makes the limiters more important than the generation itself:

• quiet hours: sending only inside an 11:00–21:00 New York window — safe across all continental US time zones; Alaska and Hawaii are handled separately
• per-number cooldown — a repeat call doesn't turn into a stream of messages
• rate limiting for the pipeline as a whole
• draft mode: everything is computed and logged but nothing leaves the system — plus a separate explicit flag for live sending

The "Missed calls" page in the CRM

The auto-reply covers first contact, but a human still has to work the calls. Instead of a notification feed there is one page: who called and when, the number as a tel: link, the matched customer, their orders with state ("unfulfilled · 82 days"), a ready-to-send reply, and a "handled" checkbox.

Degradation instead of failure is built in: a malformed queue line does not take the page down, and a read failure renders "queue could not be read". Had it said "no calls", the operator would calmly close the tab and walk away.

Five breakages fixed along the way — three of them kept the pipeline dead

• customer lookup crashed on a signature mismatch — every call was treated as "customer not found"
• event parsing read the wrong nesting level and silently discarded every missed call
• the caller's number was being read from a field the webhook does not contain
• the auto-reply card took the whole calls page down — the page two operators start their morning on: the code was written against guessed field names, and the test stub was invented to match, so it confirmed the author's guess
• the missed-call aggregates were written and covered by tests, and nothing ever called them: the manager's question "how much are we losing on missed calls" stayed open while the answer already sat in the code

The first three were invisible from the outside: the service ran, logs were written, no SMS went out. The fourth was obvious to everyone at once — the calls page stopped opening. The fifth stayed quiet: the number was computed and shown to nobody.

How we prove the webhook door is open

Silence in the pipeline reads two ways: there really were no calls, or events stopped arriving. While those two states look identical, any report about a quiet night is worth nothing. So the door itself gets its own checks:

• The receiver spent 18 days running code almost three weeks old with a restart counter of zero, and a file hash on disk matching the repository did nothing to disprove it: the comparison that counts is process start time against file modification time. The consequence was exactly what this case is about — looking up the customer by phone number went out to another server, an empty response made the function silently return nothing, and the call turned into "customer not found". Before the restart the code was diffed byte for byte against the repository and 732 green tests were run across the pipeline
• The "were there any calls" sensor leaned on a verification endpoint that returns HTTP 400 with no data array: a naive parser prints "0 calls", and the failure is visually indistinguishable from proof that no calls came in. It surfaced through a control window where calls certainly existed: the same endpoint reported "0". A different endpoint is now the working sensor, and the webhook door is checked four independent ways, none of which leans on the queue
• The tripwire was written down in advance: "no events at all by 18:00 Monday — go into the webhook settings". Going there was never needed: the calendar hypothesis held exactly — Friday 4 events, Saturday 0, Sunday 3, Monday 6 — and 41 hours of silence was explained by the weekend
• The watcher on the provider's email reply read the very message it was waiting for, wrote it into state and woke nobody: the unsubscribe filter searched for its phrase across the whole body, and the ticket system appends the entire thread underneath. Fixed by parsing only the new part of the message. The same look turned up a second thing: the watcher's log held 50 lines and every one of them was an error, because a successful run printed nothing — "ran and stayed quiet" and "not running at all" looked the same

It is the same rule the queue page follows: "couldn't read" is never rendered as "empty".

When customers actually call

The pipeline had run long enough for the webhook journal to answer the question of which hours to keep the line staffed. The measurement runs off the journal on disk, with no call to anyone's API: dedup by call id, the last event carrying a final status wins, and the customer's time zone comes from a phone-number parsing library. That is 739 inbound calls over 90 days, with the time zone resolved for every one. Counting in our own time was off the table: eight in the morning on the East Coast is five in the morning on the West Coast, and the conclusion would have come out backwards.

• the peak sits at 11:00 in the customer's local time; the 09:00–12:00 window carries 38% of calls
• 82% of calls land in business hours; the evening carries 5% and the night 1% — the popular "they call in the evening" theory failed to hold
• Monday runs nearly twice as heavy as Friday
• 496 of the 739 calls arrived inside the advertised intake window, and 310 of those were missed
• in the daily report, 7 missed calls out of 9 fell inside the advertised intake hours

Hence the management number the whole exercise was for: moving closing two hours later, to 17:00, would have caught 133 calls over 90 days — about 44 a month. Holidays are computed by formula, because a table of dates is the kind of thing everyone forgets to extend.

Our own mistake here cost an extra round: the first version of the time-zone lookup leaned on a hand-built table of area codes and immediately put one of the cities in the wrong zone. A zone error silently shifts the entire peak and leaves no trace on the chart, so the table was thrown out and number parsing handed to a library — a libphonenumber port. The caveat that an area code can diverge from where a person lives is flagged in the report as unverified.

The "Yesterday" card on the calls page

A summary of the last 24 hours now sits next to the queue: how many auto-replies went out, how many did not, and for what reasons. The card is assembled from a complete set of sources, and the check rides on that: the full call renders "not sent 2" with two reasons, the trimmed one renders "not sent 0". The gap shows immediately that the sources have been stubbed.