Как жалобы заказчика станут источником ваших новых доходов

Жалобы клиента - это всегда важная информация для подрядчика, но часто еще и возможность дополнительно заработать. Я покопался в своем опыте топ-менеджера НОРБИТ за последние 20 лет и сформулировал восемь основных типов жалоб, которые можно и нужно превратить в деньги.

Жалоба №1. «Ваш уровень сервиса слишком мал для меня»

Клиент может считать, что уровень сервиса, который вы предлагаете, недостаточен. Здесь могут быть два варианта. 

Первый - когда у клиента завышенные ожидания по поводу вашего продукта. Например, заказчик ожидает, что заплатив вам 50 000 рублей в месяц за хостинг, он имеет право круглосуточно вам звонить и требовать у вас дополнительные услуги. Возможно, это сигнал о том, что это не ваш клиент и вам стоит честно ему про это сказать и отказаться от совместной работы, потому что вы от этого теряете деньги, а не зарабатываете, плюс тратите много нервных клеток на то, чтобы объяснить клиенту, что то, что вы планировали делать за эти деньги, меньше, чем то, что он ожидает. Это нормальная ситуация, когда на этапе продажи стороны не поняли друг друга.

Но может быть и другая ситуация. У клиента есть реальная потребность, ему объективно нужен больший уровень сервиса и он готов за это платить. Просто вы не объяснили заказчику, что в вашу стандартную услугу входит определенный объем. Заказчик не знает, что у вас есть это ограничение, или не может это понять, так как просто не разбирается в вашей области деятельности. Клиент, возможно, считает, что имеет право бесконечно требовать от вас. 

Здесь важно сказать клиенту, что стандартный пакет - это, например, две консультации в месяц, и вы всегда готовы их оказать, но если реально нужно VIP-обслуживание, когда можно чаще обращаться за помощью, это будет стоить не 50 000 рублей, а 80 000, и тогда вам будет рентабельно работать с таким заказчиком, а он гарантированно получит тот уровень сервиса, который соответствует запросам его бизнеса. А дальше пусть клиент принимает решение, устраивают ли его эти дополнительные 30 000 рублей или нет. 

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

Жалоба №2. «Да что тут делать! Все проще пареной репы»

Клиент может неправильно воспринимать уровень сложности той услуги, которую он купил.

Приведу пример немного из другой области. Если вы хотите устраивать соревнования по стрельбе из лука и чтобы люди ходили их смотреть, то попробуйте сначала сделать бесплатную постоянно действующую секцию. Дайте людям пострелять из лука. Только так они поймут, насколько сложно в реальности попасть в яблочко и как трудно стать профессиональным лучником, который делает это в разы лучше любителя. Т. е. надо понимать сложность деятельности, чтобы ее объективно оценивать.

Та же самая ситуация с клиентами, которые требуют передвинуть два поля в программе и поменять цвет интерфейса (вы же ИT-компания), но не до конца понимают, как это сложно: «Господи, ну цвет перекрасить! Ерунда». 

 Не то, чтобы с этим надо бороться. Нужно просто объяснить, что вы не против сделать эту дополнительную работу, но она занимает у нашего сотрудника три часа времени. 

Во-первых, потому что даже эти простые изменения нужно согласовать с заказчиком. Это условно 10 минут. Дальше изменения нужно аккуратно внести. Даже если это какая-нибудь простая low-code система типа BPMSoft, нужно все настроить, проверить, каким образом эта новая кнопочка будет влиять на весь процесс, протестировать его. Если не протестировать, то система может перестать работать, а клиента, естественно, это не удовлетворит. Поэтому тестировать нужно обязательно.

После того, как прошел тест, необходимо зафиксировать те изменения, которые внесены, потому что вдруг завтра другой сотрудник подрядчика будет эту систему дорабатывать, а ему нужно понимать, что это не случайность, зачем это изменение было внесено, кто в нем заинтересован и каким образом изменение отработали внутри. Дальше нужно предоставить эту систему клиенту, чтобы он проверил, что его исходное пожелание реализовано правильно.

Вот так по чуть-чуть получается три часа. Часть работы вашего сотрудника для клиента стоит 4 500 рублей, и за «простую» перекраску поля заказчику будет выставлен счет на 13 500 рублей. Логично? Логично. Если заказчик в следующий раз захочет попросить об изменении, понимая, сколько это времени займет, прекрасно - плюс 13 500 к бюджету проекта. Это я привел в пример простую задачу. Понятно, что более сложная задача будет стоить гораздо больше.

 Очень важно пояснять заранее, до старта проекта, сколько будут стоить дополнительные работы: «Это стоит 15 000 рублей, это - 40 000. Вот в почту мне окните, и тогда сделаем». 

Заказчики часто жалуются не потому, что с них взяли дополнительные деньги, а потому, что их заранее не предупредили, какие деньги возьмут, а  ответственному сотруднику от компании-клиента нужно не потерять лицо и найти где-то дополнительный бюджет, согласовать платеж. Заранее объяснив сложность задачи и то, как происходит ценообразование, можно сохранить лояльность заказчика и получить дополнительный доход.

Жалоба №3. «Я вас так делать не просил»

Клиент вам заявляет: «Я понимаю, что мы эту работу заказывали. Я думал, что она очень простая, а в реальности она оказалась в 100 раз сложнее. Так сложно делать я вас не просил». Вроде бы это продолжение предыдущей жалобы, но она выглядит по-другому. 

Например, заказчик говорит: «Слушайте, я хотел, чтобы вы мне интегрировали 1С с BPMSoft, и на момент интеграции я подразумевал, что вы будете просто выгружать данные из 1С в Excel, а мой сотрудник будет вручную их закачивать в BPMSoft. Я считал, что это примитивная работа, которую можно сделать очень быстро. Если делать так, как я предполагал, - это очень недорого реализовать. Но в какой-то момент мой разработчик поговорил с вашим разработчиком, и они решили сделать красивую онлайн-синхронизацию через какую-то внешнюю шину данных, которая работает сама и одновременно дает кучу полезной аналитической информации. Все круто, но решение стало примерно в 30 раз дороже. Да, безусловно, оно совершенно, но оно теперь стоит на 150 000 рублей дороже. Не, ребята. Я же вас это делать не просил и платить за это не буду. Кто просил, пусть тот и платит. Или подарите нам то, что вы сделали, а иначе какого лешего вся эта история должна существовать?»

Что в этой ситуации подрядчиком сделано неправильно? В самом начале пропущен этап двумя разработчиками, а в реальности, конечно, их руководителями, когда один согласовал работы своему сотруднику, но не согласовал с руководителем от заказчика, что эта задача нужна и должна быть оплачена в определенном размере. Если бы руководители заранее проговорили, что есть вариант посложнее, но реально надежнее и удобнее, и стоить он будет дополнительные 150 000 рублей, скорее всего в масштабах проекта эта сумма могла оказаться незначительной и не вызвала никаких проблем.

Жалоба №4. «Любая современная ИТ-система должна быть неуязвима для хакеров»

Этот вид жалоб, который мне очень нравится: «Разве не очевидно, что сейчас любая информационная система не должна иметь ни одной уязвимости, и если мы сейчас дополнительно закажем какой-нибудь внешний пентест, то, естественно, она должна ему соответствовать. Раз мы покупаем систему у крупной компании, то, конечно, даже если это нигде не прописано в договоре, она по умолчанию должна быть надежной. А раз она должна быть надежной, то мы как заказчик имеем по-любому полное право ее тестировать и ломать. Если вдруг система все-таки сломается, то платить за нее мы точно не должны. Вы нам бесплатно обязаны все исправить. Это ошибка системы».

Эту ситуацию нужно отрабатывать в самом начале, и здесь вопрос не к тем, кто внедряет систему, не к производственному подразделению, а к тому, кто проект продает.

Конечно, в стоимость договора часто не закладываются работы по обеспечению информационной безопасности конкретной системы. Почему? 

Потому что, во-первых, часть заказчиков это делает на своей стороне. ИБ-служба клиента формулирует общие требования ко всем системам, которые будут внедряться в компании, и когда подрядчик какую-то отдельную систему сдаёт, то заказчик забирает ее себе на обслуживание. Так делают, чтобы внешний мир не знал все нюансы, связанные с информационной безопасностью конкретной компании.

Часть заказчиков говорит: «Вы нам систему дайте, а мы сами ее разместим в защищенном месте, где все отследим. Плюс у нас своя служба тестирования». Поэтому не все заказчики по умолчанию вообще понимают, что у них будет задача по устранению уязвимостей.

Мир меняется. В моей практике были случай, когда заказчик, который выбирал продукт для внедрения без нашего участия, вдруг неожиданно заявлял:  «Мы новым искусственным интеллектом проверили вашу систему. У вас около  1000 уязвимостей. Давайте все исправляйте». 

Почему эта ситуация тоже приводит к дополнительным расходам? Потому что заранее подрядчик не проговорил тему инфобеза. Нужно было спросить клиента: «Вы сами будете решать эти вопросы или зовем наших специалистов, которые вам дополнительно к контракту сделают эти работы?» 

Если заказчик говорит прямо под запись, что все вопросы, связанные с уязвимостями, сканированием, пентестами и т.п., на его стороне, тогда прикладываем коммерческое предложение. В договор же нужно заранее вписать фразу, что все условия были указаны в КП, которое подавалось на тендер, чтобы потом, когда вопрос инфобеза возникнет, а сейчас он возникает очень часто, вы могли эту историю показать. Но после того, как вы это вписали в контракт и он подписан, нужно прийти к заказчику, у которого уже нет пути назад, и сказать; «Через четыре месяца мы сдадим тебе систему, и ты должен будешь подписать бумаги, что с ней все в порядке». 

Если клиент хочет сделать инфобез сам, ведите разговор в следующем русле: «Пожалуйста, делайте сами - есть вот такие подрядчики. Хотите, продадим вам софт, который эту историю делает. Хотите, продадим обучение вашим службам». 

Тема, которая не вошла в контракт (особенно ИБ), - потенциально прекрасна для дополнительных продаж. Но очень важно эти допродажи начинать не в момент, когда вам предъявят обвинение, что клиент подразумевал тему ИБ, а вы о ней забыли, а в тот момент, когда проект только начался, вы еще не понесли столько затрат, чтобы было жалко уходить из проекта без денег, но при этом стороны еще к друг другу хорошо относятся, и очень важно как раз сейчас на берегу понять, кто эту историю с инфобезом сделает.

Жалоба №5. «Мы передумали, и нам больше не нужна ваша система»

Зачастую источник этой проблемной ситуации с клиентом – очень неприятная история, когда, как правило, на полпути меняется человек, который исходно был интересантом внедряемой системы. 

У нас был проект с одной крупной корпорацией, где мы делали BI-систему для 1С ЗУП (Зарплата и управление персоналом). За время, пока мы выполняли этот проект, у заказчика поменялись четыре директора по персоналу, которые фактически были интересантами этой системы. Четвертый директор сказал нам: «Парни, все круто, но мне не нужна эта аналитика. Я другими методами решаю задачи анализа и отчетности». В итоге на заключительном этапе мы объективно пришли к ситуации, что никто не хочет на стороне клиента принимать систему, потому что она просто ему не нужна.

Я говорю: «Давайте придумывать, как расторгаться». Понятно, что в таких ситуациях главное понять, как уйти вовремя, но если чуть-чуть заранее продумывать эту историю (ведь всегда возможны изменения в команде топ-менеджеров клиента), то можно на этом и заработать. 

Здесь более сложная ситуация. Она выглядит примерно следующим образом. Вам нужно постоянно держать проект на операционном контроле, чтобы вы всегда могли показать заказчику, что все работы выполняются по его заветам и по его непосредственным распоряжениям.

Даже если у вас этап идет три месяца, а прошло уже два с половиной, у вас в идеале каждую неделю должны быть четкие протоколы о том, что сделано, что проверено, кто из сотрудников заказчика эту историю принял, посмотрел, протестировал, что она залита на сервер, что кто-то промежуточный (конечно, из уполномоченных лиц) эту историю принял. 

Почему это важно? Потому что в момент, когда вдруг неожиданно новый интересант проекта говорит, что ему все это не нужно, вы ему предлагаете два варианта: «Либо мы еще две недели эту систему доделываем, сдаем и у вас есть готовая работающая система. Либо оплатите нам 90% работ, которые уже сделаны. Любой суд подтвердит и признает, что мы реально эти работы выполняли, просто у вас изменилась потребность». 

Если у вас есть четкая аргументация, что вы в соответствии с контрактом добросовестно исполняли все требования по заданиям заказчика, согласованным с его представителями, вплоть до момента, когда вам поступил e-mail, что проект не нужен, то любой юрист клиента, посмотрев на эти документы, скажет, что глупо с вами судиться, что вы еще можете и упущенную выгоду отсудить, потому что объективно все сделали, как было в контракте. 

В этом случае вы заработаете деньги, даже не сдав проект и не понеся всевозможные проектные риски. Гарантийные обязательства на вас тоже не будут распространяться. Потому что даже если заказчик не захочет закончить проект, он вам все оплатит. Это хорошая история. 

А если четкой аргументации у вас нет, и заказчик скажет: «Мы какой последний этап актировали? Три месяца назад? Ну, наверное, на этом и все. Всем спасибо. Нам же все равно не нужно то, что вы дальше будете делать. Жизнь - сложная штука. Вы же крупная компания. Компенсируйте за свой счет», то вы тогда проиграли и ничего дополнительно не заработали. 

Какие бы ни были отношения с заказчиком, сколько бы лет вы с ним до этого не работали, сколько бы лет вы лично с ним не дружили, аккуратненько, каждую недельку, таймшитами, в джиру, на гитхаб, куда угодно, заливайте свежий код и информируйте клиента.

Поверьте мне, представители заказчика тоже будут вам благодарны, Потому что никто не хочет по большому счету кидать подрядчика и портить отношения. Но одно дело, если у заказчика будут возможность вам не платить и риск рассориться с вами. Другое - 100% аргументации при качественном оформлении работ, что платить нужно. 

Жалоба №6 имени почтальона Печкина «Посылку я вам не отдам, так как у вас документов нету»

Этот вид эскалации примерно такой: «Вы нам внедряли систему. Мы сейчас должны были у вас её принять, но так случилось, что никто не подумал (ни вы, ни мы), о том, что для запуска этой системы нужен новый сервер, новый маршрутизатор, новый закупленный антивирус (или что-то еще из смежных областей). В итоге мы при всем желании не можем подписать акт сдачи-приемки, так как вашу систему некуда установить. На нее не куплены новая операционка, работы по инсталляции и т.п.».

Это не очень сложный кейс с точки зрения, как здесь можно много заработать. «Ой, мы не подумали» – это потенциальный источник ваших новых контрактов, доходов или привлечения подрядчиков для этой работы, на которых вы тоже можете заработать. Просто нужно глубже вникать в ситуацию клиента. 

Если вы - руководитель компании-подрядчика, то скорее всего сами вы это сделать не сможете. Но это могут ваш руководитель проекта и ваши ответственные сотрудники на проекте. В идеале каждый сотрудник поставщика должен понимать, что если он видит какую-то дополнительную возможность расширить сотрудничество и получить какие-то новые контракты, то это позитивно оценивается вашей компанией. Здесь мы убиваем двух зайцев. Во-первых, мы получаем новый контракт, а во-вторых, - возможность завершить старый.

Жалоба №7. «Нам срочно нужны ваши таланты»

Эта ситуация прекрасна: «Как круто, что вы нам продали автомобиль, но у нас никто не умеет на нем ездить и ни у кого нет прав». 

Все компании, которые продают умные технологии, уверены, что все в мире такие же умные, как они, и, конечно, легко во всем разбираются. Часто заказчик тоже уверен, что вопрос - фигня: «Принесите нам систему - мы все поймем». Но нередко оказывается, что нет. 

Для использования сложных систем часто нужны не просто квалифицированные кадры, а кадры еще и с опытом эксплуатации таких систем. Представьте, что вы покупаете самолет. Да, вам его пригонят, пилот производителя вам его запаркует и даже покажет, как он летает, но дальше у вас должен быть свой пилот.

Я часто слышу: «Вы же понимали, когда внедряли нам эту систему, что для эксплуатации нужен хороший базисник и пара девопсов, потому что у нас тут 8 000 пользователей, постоянно ломающееся оборудование и все такое. Мы бы, конечно, сейчас систему в продакшн отправили, но вот только где мы таких специалистов за два-три месяца найдем? Нам еще нужен месяц на утверждение  штатных ставок, потом месяц - на поиск».

В итоге больше всех пострадает с одной стороны заказчик, но с другой - вы тоже косвенно пострадаете из-за того, что заранее не помогли ему сформировать команду, которая будет использовать то, что вы продаете, потому что уровень зрелости клиента не помог ему самому додуматься до этого.

Не ждите таких жалоб. Лучше заранее помогите заказчику сформировать центр компетенции сотрудников. Возможно, даже предложите ему взять на работу кого-то из ваших сотрудников, если вас это устраивает. В итоге вы получите заранее обученного заказчика и дополнительный заработок. 

Жалоба №8. «Пока шел проект, требования жизни изменились»

Вы что-то продавали-продавали (долгая была закупка), потом внедряли-внедряли (долгий был проект), но в итоге оказалось, что к моменту запуска что-то катастрофически устарело.

Например, вы внедряли систему, которую неожиданно объявили системой, в которой содержатся персональные данные, и она потребовала кучу дополнительных моментов. Виноваты ли вы в этом? Естественно, нет. Это форс-мажор. Прав ли будет заказчик, если скажет вам: «Вы же специалисты. Могли хотя бы предусмотреть»? 

Что делать в этой ситуации? Да то же, что и раньше. Понимая, что есть некие новые требования, которые не зависят ни от вас, ни от заказчика, заблаговременно и очень вежливо приходите к клиенту и говорите: «Мир несправедлив. Он меняется. Возникли новые требования. Мы знаем, как удовлетворить их на очень хороших и комфортных условиях. Давайте это каким-то образом законтрактуем».

Для вас это точно некая дополнительная возможность заработать и расширить объемы своего контракта. Вы абсолютно искренне помогаете заказчику снять проблему, потому что если вы просто выполните существующий контракт, то вполне возможно, что результат не сильно удовлетворит клиента. 

Ну и напоследок специально для блога ЛАНИТ мой любимый анекдот про правильную работу с потенциальными жалобами.

Звонок на фирму, которая занимается продажами, обслуживанием и ремонтом компьютерной техники:

- Здравствуйте, у меня плохо печатает принтер, который вы мне продали месяц назад.

- Скорее всего, нужно почистить картридж. Это будет стоить 1000 рублей плюс выезд нашего мастера 3000 рублей. Но вы также можете открыть инструкцию на странице 15 и там написано, как почистить картридж самостоятельно.

Удивленный клиент спрашивает:

- А ваше начальство в курсе, что так вы препятствуете своему бизнесу? Не боитесь, что кто-нибудь из клиентов пожалуется на вас?

- Нет. Если честно, это идея нашего директора. Мы зарабатываем в разы больше, когда разрешаем клиентам сначала самим что-то попробовать починить.