Pull to refresh

Comments 8

— ваша… не работает!!!
— вы инструкцию читали?
— конечно!
— а требования для подключения, указанные там выполнили?
— а что требования какие-то есть?
Хорошо, что просто не сказали "Не е** мне мозги. Не умничай!!! ". Пока не будет введена ответственность за непрочтение инструкции — бардак в ИТ будет присутствовать всегда.
У вас маленькая компания. 45 минут — вполне себе вменяемое время если у вас количество клиентов измеряется тысячами и миллионами. Просто научитесь организовывать такие очереди: обьяснить что происходит; информировать клиента сколько ТОЧНО ему осталось ждать; предложить перезвонить в другое время, когда, по статистике, очередь короче; предложите позвонить на номер клиента, когда освободится кто-то из поддержки.

Клиент не поймёт, если ему в первый раз сделают за полчаса и с высочайшим качеством, а в последующие приедет стажёр и прокопается сутки, ничего не завершив.

Если делали ОДНО И ТОЖЕ. Сервис, например.
У вас, похоже, оборудование не сложное. Бывают неисправности, которые сутками вылавливаются. И далеко не стажёрами. При том что внешние признаки, для клиета, могут совпадать с прошлым ремонтом, который за час сделали.
А посылать одного стажёра на обьект — это нормально?

«Оно пип, потом чавк-чавк, и огонёк мигает»

Замечательное описание, почаще бы так описывали. Спец, если в теме, однозначно поймет куда копать. А давайте я пожалуюсь что после сброса начинается перезапуск но запуска нет, но если сделать ресет то сброс не проходит. Причём что я имел ввиду под «сбросом», «перезапуском» «ресетом» и «запуском» я уточнять не буду — вы и так это знаете. Специальные термины в описании неспециалиста специалисту — это кошмар, потому что они имеют РАЗНЫЕ значения для неспециалиста и специалиста.

А давайте я пожалуюсь что после сброса начинается перезапуск но запуска нет, но если сделать ресет то сброс не проходит. Причём что я имел ввиду под «сбросом», «перезапуском» «ресетом» и «запуском» я уточнять не буду — вы и так это знаете.

Это реальную проблему так описывали?..

Некоторые вещи очевидны, просты (и, возможно, неправильны): чтоб не терялись путевые листы — оплачивать только заполненные листы, для уменьшения количества выездов «ой, оказывается, мы тут вилку из розетки вытащили» — в договор прописывать количество часов за период действия договора ( этим некоторые вендоры балуются: пишут контракт на пару лет и в нём — количество часов на сайте заказчика, а потом помогают с настройкой, мониторингом, обучением персонала, подпишите здесь, нет, мы не можем выехать — вы за 3 месяца использовали все 50 часов из договора на 2 года. Можем прислать доп.соглашение ещё на 50 часов и счёт) и введением разных уровней важности проблем с разным SLA.
А ещё при конфликтах и проблемах — не забывать сначала собрать внутренний круглый стол, а после выяснения корневых причин — с заказчиком, чтоб никогда впредь.
И не забывать прописывать конфликтные решения в доп. соглашениях.
будет лучше всего, если вы сможете продемонстрировать персонализацию на все 100%: обращение по имени (CRM), история отношений

Может я как то не такой, но всегда хочется убить, когда саппорт обращается по имени, потому что во первых это напрягает а во вторых чувствуется какая то фальшь.
КАк же это все знакомо!!! Посмеятся под бокал чего нибуть приятного на празнике, потом взгруснуть, что подобное происходит в реальности и с улыбкой за руботу. И ведь все тоже самое происходит и вне IT:
-Вы читали инструкцию на установку?
-Да!
— Там запрещена работа в подобном режиме!
— Не там такого!
(показываю целый раздел на нескольких страницах и запретах и как правильно)
Sign up to leave a comment.