Изменить текст письма: нейросеть не должна менять срок
Изменить текст нейросеть поможет, если заранее назвать, что трогать нельзя. Разбираю письмо о переносе срока: тон, точные условия, проверка версии перед отправкой.
М
Марина
Контент-маркетолог LibraChat
7 мин чтения
Как написать клиенту, что согласование макета сдвигается на два дня, и не превратить письмо в извинение на полстраницы? Когда мне понадобилось изменить текст, нейросеть выглядела удобным редактором. Но она не знает, какую дату мы уже обещали и кто отвечает за следующий шаг. Я оставила себе факты и решение, а ей отдала формулировки. Ниже вопросы, по которым я проверяю такую правку перед отправкой.
Что значит «изменить текст нейросеть» для рабочего письма?
Сначала нужно назвать вид изменения. В моём письме было три разных задачи: сократить вступление, смягчить резкую фразу и сделать следующий шаг понятным. Попросить «перепиши красиво» означало бы передать модели право переставлять и условия проекта. Это плохая сделка: гладкая речь не компенсирует неправильную дату.
Я формулирую задачу как редакторскую операцию. Например: «Сократи письмо на треть, сохрани прежнюю и новую дату, причину переноса и просьбу подтвердить новый срок». Если проблема только в тоне, не разрешаю менять объём и содержание. Если проблема в порядке, прошу переставить абзацы, а не сочинять новый повод задержки.
При разметке исходника я делю фразы на три группы:
Неприкосновенно: даты, сумма, название проекта, уже согласованные условия, конкретная просьба.
Можно редактировать: приветствие, порядок абзацев, длинные связки и повторные извинения.
Нужно уточнить: кто присылает финальную версию, нужна ли встреча, когда ждать ответа клиента.
Третья группа особенно опасна. Я могу поручить чату заметить пустое место, но не могу поручить ему выбрать ответ вместо команды. В письме о переносе это граница между редактурой и самовольным обещанием.
Почему короткая команда меняет больше, чем нужно?
Однажды я подготовила рабочий черновик из 216 слов. Там дважды объяснялась задержка, зато было точно написано: макет придёт во вторник до 18:00, а клиенту нужен день на замечания. Команда «сделай дружелюбнее и короче» не содержала запрета на замену срока. В ответе такого типа я ожидала бы увидеть приятный тон; проверять пришлось бы совсем другое: не исчез ли день на замечания.
С тех пор я пишу разрешения и ограничения отдельно. Такая таблица помогает не прятать критическое условие в середине длинного запроса.
Что нужно в новой версии · Что запрещаю менять · Как проверю
Убрать второе извинение — Вторник, 18:00 — Сверю с планом проекта
Сделать просьбу короче — День для замечаний — Найду его в итоговом письме
Смягчить резкую строку — Ответственного за макет — Проверю имя и роль вручную
Я не оцениваю редактуру по числу удалённых слов: можно сократить половину и вырезать единственное полезное условие. Для клиента важнее понять, что произойдёт дальше. Хорошее письмо после правки может быть длиннее исходника, если прежде в нём отсутствовала новая дата.
Какой шаблон запроса удержит смысл письма?
У меня лучше работает запрос с исходником, задачей и способом проверки. Текст письма подставляй только после того, как уберёшь из него сведения, которые не собираешься раскрывать сервису: личные контакты, закрытые условия договора, имена третьих лиц. Для учебного черновика можно заменить их метками.
Отредактируй письмо о переносе даты согласования макета. Сохрани факты без изменений: [старая дата], [новая дата и время], [причина, подтверждённая командой], [срок для замечаний], [имя ответственного]. Оставь одно извинение, а в финале назови конкретное действие адресата. Не добавляй компенсацию, скидку, новую встречу или обещание «точно без задержек». Сначала покажи новую версию, затем коротким списком перечисли все изменения смысла, если они возникли. Пробелы в исходных данных выпиши как вопросы ко мне.
Я не прошу сразу «идеальное письмо». Сначала хочу увидеть возможные отклонения. Список изменений смысла полезен как сигнал, но я всё равно сравниваю строки сама. Модель может не заметить собственную подмену, особенно если два близких срока стоят в соседних абзацах.
Если исходное письмо длинное, делю работу на два этапа. Сначала прошу отметить повторы и непонятные места без переписывания. Затем выбираю, какие фрагменты действительно меняю. Это замедляет отправку на пару минут, зато оставляет решение у автора письма. Для небольшого сообщения достаточно одной операции за раз.
Можно ли доверять правке тона?
Одни и те же слова для клиента и коллеги звучат по-разному. Клиент, который ждёт макет для запуска, прочтёт «у нас возникли небольшие технические сложности» иначе, чем коллега внутри команды. Такой оборот скрывает ответственность и не сообщает новую дату. Поэтому я проверяю тон по двум вопросам: понятно ли, что изменилось, и не звучит ли письмо так, будто адресат должен догадаться о последствиях сам.
Смягчить фразу можно без ухода от ответственности. «Вы прислали замечания поздно» превращаю в «Мы получили замечания после согласованного окна и обновили график». Но такую замену использую только если график действительно обновлён. В других обстоятельствах она будет удобным самооправданием.
У меня есть короткий список тревожных слов: «в ближайшее время», «оперативно», «при первой возможности». В обычном разговоре они могут быть уместны. В письме о конкретном переносе они заслоняют время. Я предпочитаю написать дату, час и действие, которое ждём от клиента. Если команда ещё не определила час, не подставляю произвольный. Пишу «время уточню до [дата]» лишь тогда, когда это новое обязательство согласовано.
Для разных адресатов порядок может отличаться:
Клиенту, которого касается перенос, сначала называю новую дату и влияние на его работу.
Внутренней команде сначала фиксирую причину и ответственного за устранение задержки.
Руководителю добавляю решение: что уже предприняли и какой срок теперь реалистичен.
Это три разных письма из одних фактов, а не три варианта «вежливого стиля». Не стоит отправлять клиенту внутренний разбор, даже если он звучит убедительно.
Чек-лист перед отправкой: что сравнить?
На одном экране держу исходное письмо, на другом его правку. Сравниваю даты посимвольно, затем читаю предложение с просьбой. Может ли клиент ответить одним понятным действием? Если нет, редактирую сама. Потом убираю фразы, которые говорят о нашей занятости вместо плана для него.
Для переноса макета я отдельно записываю маленькую карточку договорённости: прежняя дата, новая дата, время передачи, сколько клиенту оставлено на замечания, кто отвечает за отправку файла. Карточка остаётся рядом с двумя версиями письма. Если новая версия красива, но один пункт из карточки пропал, я не обсуждаю стиль. Сначала возвращаю условие. В переписке после этого меньше споров о том, кто «имел в виду» пятницу, а кто вторник.
Проверка адресата тоже важна. Внутренний черновик иногда содержит имя коллеги и подробности задержки, которые клиенту не нужны. Я не копирую его целиком в финальное письмо. Прочитываю как человек, впервые увидевший проект: ясно ли, какой макет задержан? Нужно ли ему отвечать или мы только уведомляем? Есть ли контакт, по которому он сможет спросить о последствиях? Каждая из этих деталей зависит от реальной договорённости, а не от красноречия редактора.
Последний шаг у меня технический, но очень человеческий: проверяю тему письма и список вложений. Можно старательно исправлять абзацы и отправить обещанный макет без файла. Никакая удачная формулировка это не компенсирует. Если вложение будет позже, так и пишу, после подтверждения команды. Если файл уже готов, прикрепляю его до чтения текста вслух. Я поймала себя на этой ошибке однажды и теперь держу пункт в конце списка.
Тема письма должна работать и вне всей переписки. «По нашему разговору» ничего не скажет человеку, который увидит цепочку через неделю. «Согласование макета: новая дата 12 ноября» уже помогает найти нужное сообщение. Но дату в заголовке ставлю лишь после той же сверки, что и в теле: ошибку в теме адресат может запомнить даже раньше, чем откроет письмо. По этой причине я не поручаю нейросети придумывать тему без списка подтверждённых фактов.
Наконец, задаю себе проверочный вопрос: «Если адресат перешлёт только это письмо коллеге, поймёт ли коллега новую договорённость?» Это жёсткий, но полезный тест. Он обнаруживает местоимения без опоры, неопределённые сроки и пропущенные вложения. Отдельный разбор более широкой задачи есть в статье о нейросети как редакторе текста.
Если тебе нужно поправить собственное письмо, открой чат LibraChat, вставь обезличенный исходник и перечисли три факта, которые нельзя менять. Попроси сначала отметить возможные смысловые сдвиги. Затем сравни черновики строка за строкой; способ доступа и режим работы выбирай по действующим условиям. Что в твоём письме останется верным, даже если убрать половину вводных слов?
