Спасибо, приятно что прочитали мое повествование!

Дело в том, что я больше 10 лет работаю с екоммерсом и предоставляю услуги доставки для интернет-магазинов (от 1 до 10000 заказов в сутки) - смотрю на многие процессы "изнутри".

По вопросам:

"2. Нигде — ни в корзине, ни на следующих страницах — нет информации о сроках поставки" - отправлять сообщения о сроке доставки после оформления заказа не очень хорошая затея.

Сроки должны быть видны на этапе оформления заказа. Если срок плавающий (поставка под заказ и т.п.) - лучше писать "от 1 до 3 дней" чем не писать вовсе.

У вас собственная доставка, думаю - спрогнозировать матрицу сроков задача решаемая. Если используются подрядчики вроде Почты, СДЭКа и т.п. - у всех в API-интеграции есть предполагаемые сроки доставки.

"8. Отсутствие письма или иного контакта от магазина после выполнения заказа" - тут важно иметь триггер события (а лучше - череды событий: заказ принят; собран; отгружен курьеру; доставлен).

Мы в своей работе с заказами настроили всё таким образом, чтобы дальнейшее "движение" заказа было невозможно без совершения какого-то действия (обычно - скан штрихкода). Дальше централизованное хранилище состояний и событий - куда смотрят в том числе системы информирования.

Звучит страшно, но в реальности это крайне простое it-решение, гораздо сложнее правильно выстроить процесс движения заказа.

Лучше всего при простановке статусов работает принцип передачи материальной ответсвенности: если склад не отсканировал выдачу заказа курьеру - склад продолжает отвечать за заказ своими деньгами.
Если курьер не отметил вывод заказа на маршрут доставки до дедлайна - автоматически создается инцидент. Т.е. сотрудникам выгоднее вести себя правильно и отмечать все последовательные действия с заказом (например, путем сканирования штрихкода). Если курьер своевременно не отметил вручение заказа - он не может "закрыть" маршрут.

И на все эти сообщения о изменении статуса заказа легко накладываются разные информирования (sms, email, webhook и т.д.)