Що перевіряють на сайті перед тендером

Перед тендерним запрошенням або великим замовленням ваш сайт відкривають кілька різних людей, і жоден із них не читає його як маркетинговий матеріал. Відділ закупівель шукає підтвердження, що компанія існує і підходить під категорію. Технічна команда шукає межі компетенції. Юристи й служба безпеки шукають документи, політики й канал для запиту.

Сайт не замінює тендерний пакет. Він має не викликати сумнівів до першого контакту й швидко дати докази, які можна перевірити. Розмиті формулювання, суперечливі назви й форма без контексту зупиняють маршрут ще до того, як у вас щось запитають.

Хто саме дивиться сайт

Складіть карту ролей. Для кожної визначте питання, публічний доказ, закритий доказ і наступну дію. Один відвідувач може поєднувати кілька ролей, але сторінки мають дозволити знайти потрібне без читання всього сайту.

Закупівлі

Ця роль не оцінює якість вашої роботи. Вона відповідає на інше питання: чи можна взагалі вести з вами формальний процес і в яку категорію вас віднести. Якщо відповідь не вдається знайти швидко, маршрут часто на цьому й закінчується.

• Дані постачальника. Точна назва, реквізити, географія роботи й здатність укласти договір.
• Відповідність категорії. Зрозумілий опис послуг замість гасла. Гарна фраза без переліку компетенцій не дозволяє зіставити вас із вимогою.
• Спосіб почати процес. Окремий контакт для тендерів або вибір у формі скорочує пересилання між відділами.
• Перелік доступних матеріалів. Не публікуйте чутливі документи відкрито заради зручності: покажіть, що вони існують, і опишіть порядок отримання.

Технічна команда

Технічний фахівець читає сайт скептично й шукає підстави вас відсіяти. Він бачив достатньо сторінок, де перелічено двадцять технологій і не сказано жодного слова про те, що команда з ними робила. Точна межа працює на вас краще за широкий список.

• Межі компетенції. Загальний список технологій без контексту нічого не доводить.
• Докази схожих завдань. Кейс або сторінка послуги мають показувати, яку проблему команда вирішувала й за що відповідала.
• Спосіб інтеграції. З чим ви працюєте штатно, а що потребує попереднього дослідження.
• Чесна межа. Обіцянка підтримати будь-яку систему знижує довіру, бо технічний покупець розуміє ризик універсальних обіцянок.

Юристи й безпека

Ці люди приходять останніми й мають право зупинити процес одноосібно. Їм потрібен не обсяг інформації, а її актуальність і зрозумілий порядок отримання решти. Політика з датою трирічної давності викликає питання. Оновіть її зміст і дату, але не прибирайте документ.

• Публічні політики. Обробка даних, субпідряд, власність результату.
• Актуальна версія документа. Сторінка веде на чинний файл із датою.
• Канал для перевірки. Контрольований шлях, яким можна запросити додаткові матеріали.
• Без зайвих подробиць. Детальна внутрішня схема захисту на публічній сторінці створює нову вразливість.

Базові докази компанії

Люди, які перевіряють сайт, звіряють його дані з документами й профілями в реєстрах. Різні написання назви й застарілі адреси створюють зайву ручну роботу, і кожна така розбіжність працює проти вас.

• Юридична назва там, де доречно. Бренд пояснюється окремо, а не підмінює її.
• Контакти й строки відповіді. Канали, години роботи й спосіб ескалації для формального запиту.
• Не особиста пошта працівника. І не тільки соцмережа: обидва канали зникають разом із людиною.
• Чіткий предмет послуги. Тип клієнта й межі. Підрядник, інтегратор і постачальник готового продукту потрапляють у різні закупівельні категорії.
• Дати й версії документів. Сторінка показує чинний файл, дату оновлення та власника. Архів може існувати, але навігація не повинна вести на нього як на актуальну версію.

Про те, які розділи взагалі потрібні корпоративному сайту, є окремий розбір структури корпоративного сайту.

Компетенції та кейси

На цьому місці більшість сайтів не проходить перевірку. Не тому, що робіт мало, а тому, що з опису неможливо зрозуміти, що саме робила команда. Замовник бачить логотип відомої компанії і не бачить жодного способу перевірити внесок.

Кейс відповідає на чотири питання: який був контекст, яка у вас була роль, яке рішення ви запропонували й який результат перевірено. Логотип без опису внеску не доводить нічого.

• Роль, а не участь. «Робили разом із партнером» без розподілу зон читається як спроба приписати собі чуже.
• Галузь у межах дозволеного. Якщо назву клієнта закриває NDA, тип завдання і складність усе одно можна показати.
• Критерій приймання. Що саме вважали успіхом і хто це підтвердив.
• Групування за завданнями, а не технологіями. Замовник шукає міграцію, інтеграцію, багатомовність або підтримку, а не перелік мов програмування.

Не вигадуйте деталі, щоб заповнити прогалини. Великий замовник усе одно уточнить склад команди на наступному кроці, і розбіжність тут коштує дорожче за скромніший кейс.

Процес, відповідальність і підтримка

Покупець великого проєкту оцінює не тільки здатність зробити результат, а й керованість роботи. Публікувати внутрішній регламент не треба, достатньо показати, хто відповідає за кожен етап і що замовник отримує після нього.

• Основні етапи й точки погодження. Що відбувається між стартом і здачею та коли замовник ухвалює рішення.
• Ролі, а не імена. Керування, аналіз, дизайн, розробка, перевірка, підтримка. Склад змінюється, функції залишаються.
• Механізм зміни обсягу. Слово «гнучкість» без журналу рішень і критеріїв звучить як відсутність плану.
• Межі підтримки після запуску. Канал звернення, критичність, передача знань і власність доступів.

Не публікуйте обіцянок, які не підтримуються договором. Достатньо описати модель і сказати, що конкретні показники погоджуються під систему й ризик.

Документи без витоку даних

Другий за частотою провал після кейсів виглядає протилежно: компанія викладає все підряд у відкритий доступ, вважаючи це відкритістю. Насправді це створює дві проблеми одразу. Перевіряльник не розуміє, яка версія чинна, а конкурент отримує ваш пакет без жодного запиту.

Розділіть матеріали на три групи: публічні, доступні після перевірки запиту й доступні тільки в активному процесі.

• Каталог замість архіву. Назва, опис, дата й порядок запиту. Одержувач бачить, що документ існує, а команда перевіряє контекст.
• Посилання зі строком. Для чутливих матеріалів воно має термін дії та журнал видач.
• Перевірка перед передачею. Приховані аркуші, коментарі й попередні версії всередині файлу. Видалення рядка з готового документа не очищає його історію.
• Затверджена копія, а не робочий файл. Експортована версія без внутрішніх правок і слідів узгоджень.
• Власник і дата перегляду. Сертифікат, строк дії якого минув, не повинен далі жити в презентаціях і листах.

Безпека сайту під час тендеру

Тендерна активність підвищує увагу до сайту, і не тільки з боку замовника.

• Доступи й оновлення. Перевірте адміністраторські облікові записи, оновлення і резервні копії до початку кампанії.
• Захист форми. Вона стане основним каналом і водночас основною мішенню.
• Файли з власного домену. Зовнішній диск із випадковими правами доступу виглядає як недбалість.
• Без реєстрації заради документа. Кожен новий обліковий запис зі слабким паролем додає ще одну точку входу для зламу.
• Сторонні скрипти не блокують головне. Контакти й документи мають залишатися доступними, навіть якщо віджет не завантажився.

Форма для тендерного звернення

Форма має відрізняти тендерний запит від загальної консультації та передавати його відповідальній команді, а не в спільну скриньку.

• Мінімум на першому кроці. Компанія, контакт, категорія, орієнтовний етап і безпечний опис.
• Файл не обов’язковий одразу. Повний пакет до підтвердження каналу просити не варто.
• Номер звернення. Показується після збереження на сервері, а не після відправлення листа.
• Заявка живе в базі, а лист лише сповіщає про неї. Заявка має власний ідентифікатор і журнал доставки.
• Повторне натискання не створює дубль. І не змушує заповнювати форму заново.
• Резервний канал. Якщо кінцева система недоступна, форма приймає дані або чесно називає альтернативу без утрати введеного.

Не обіцяйте угоду про нерозголошення автоматично через прапорець у формі. Сайт фіксує запит, а документ і канал погоджує відповідальна команда до обміну чутливою інформацією.

Маршрут перевірки

Сайт може містити всі потрібні докази й однаково провалити перевірку, якщо до них неможливо дійти. Людина з боку замовника не знає вашої внутрішньої структури й не буде вивчати меню: вона відкриє дві-три сторінки й ухвалить рішення.

Побудуйте кілька коротких маршрутів і пройдіть кожен від початку до кінця чужими очима.

• Закупівлі. Послуга, компанія, докази, документи, форма.
• Технічна роль. Кейс, процес, компетенції, контакт.
• Безпека. Політика, канал перевірки, відповідальний.

У навігації мають стояти знайомі назви. Внутрішній маркетинговий термін закупівельна команда не розшифрує і піде шукати конкурента, у якого написано простіше.

• Сторінка помилки допомагає. Старе посилання з тендерної бази живе роками, і воно має вести до актуального документа або до каналу запиту.
• Мобільний маршрут теж. Людина відкриває посилання з листа під час зустрічі: таблиця, документ і форма мають читатися без масштабування.
• Великі файли з коротким описом. Тоді людині не доведеться завантажувати файл лише для того, щоб зрозуміти, що це не те.

Як керувати доказами

Створіть реєстр публічних тверджень: текст, сторінка, джерело, власник, дата перевірки й строк наступного перегляду. Це головна річ, яка рятує від застарілої цифри на видному місці.

• Кількість проєктів і географія. Найчастіше застарівають саме вони.
• Сертифікати й партнерські статуси. Мають строк дії, про який пам’ятає календар, а не людина.
• Доказ і пояснення розділені. Сертифікат підтверджує статус, але не здатність виконати будь-який проєкт. Кейс підтверджує досвід у контексті, а не універсальну експертизу.
• Основний і резервний власник. Якщо строк дії документа спливає під час відпустки однієї людини, сайт не повинен лишитися зі старою версією.
• Єдине джерело файлу. Не завантажуйте той самий документ у кілька місць під різними назвами: рано чи пізно вони розійдуться.

Не пишіть «усі документи надамо», якщо частину готує третя сторона або потрібне погодження. Краще перелічити готові категорії та назвати контакт, який підтвердить решту.

Підготовка команди

Найприкріше, коли ламається остання ланка. Заявка дійшла, сайт спрацював, а відповідь пішла через три дні від людини, яка не знала контексту й попросила повторити те, що вже було у формі.

Сайт може правильно передати запит, але далі його має розпізнати людина.

• Відповідальний і резерв. З іменами, а не «хтось із менеджерів».
• Час первинного підтвердження. Відповідь не мусить містити всі документи, але має підтвердити отримання і назвати наступний крок.
• Внутрішній бриф. Які сторінки відвідувач уже бачив, що можна надсилати без погодження, а що потребує захищеного каналу.
• Розбір після циклу. Питання, що повторювалися, стають публічними сторінками з власником і джерелом, якщо відповідь безпечна.

Чек-лист перед кампанією

• Назва й реквізити збігаються з реєстрами. У всіх написаннях на сайті.
• Опис послуг відповідає закупівельній категорії. Без змішування різних моделей роботи в одному абзаці.
• Кейси мають роль і критерій приймання. А не тільки логотип.
• Документи актуальні. З датою, власником і чинним посиланням.
• Форма розрізняє тендерний запит. І доходить до відповідальної команди.
• Маршрути пройшли люди в трьох ролях. Кожен без використання пошуку по сайту.
• Контрольна заявка знайдена за номером. У робочій системі, а не тільки в пошті.

Висновки

Перед великим замовленням сайт стає першим етапом перевірки. Його читають, щоб знайти підстави продовжити або привід не продовжувати, і друге дається значно легше.

Найдорожчі помилки не в дизайні. Це різні написання назви, кейс без ролі, документ без дати, форма, що не відрізняє тендерний запит від питання про ціну, і твердження, яке нікому не належить і тому застаріло непомітно.

Якщо ви готуєтеся до участі в закупівлях, надішліть нам адресу сайту й назвіть категорію, у якій плануєте брати участь. Ми подивимося сайт і скажемо, що саме на ньому заважає пройти перевірку. Частину таких місць видно одразу, і тоді вистачить правок тексту. Якщо ж під вимоги потрібна інша структура сайту, зберемо її в межах розробки корпоративних сайтів.

Корпоративний сайт з унікальним дизайном і структурою під ваші послуги коштує від $2 000 до $3 000. Тендерну форму з власною базою заявок і каталог документів із тимчасовими посиланнями та журналом видач оцінюємо окремо, як кастомні модулі, від $500 до $2 000.