Автоматизация бизнеса — удалённая работа в Москве

Сфера деятельности: автосалон. У нас автоцентр, продаём машины дорогого сегмента, плюс свой сервис и склад запчастей. Обращения идут с Авито, из WhatsApp и телеграма, сидят на них два-три менеджера. Вечером и в выходные не отвечает никто, и половину этих людей мы больше не видим. Нужен бот на первую линию. Сразу главное, потому что тут обычно понимают неправильно. Нам не нужен бот, который отвечает на вопросы. Нужен бот, который втягивает человека в разговор. За два-три своих сообщения он должен либо вытащить контакт, либо получить согласие на звонок, либо довести до «хочу». Дальше подключается менеджер. Экспертиза от бота не требуется — он всё равно не скажет, сколько доплатить при обмене. Его дело в том, чтобы разговор не оборвался. Пример, как убивают обращение. Клиент: «оцените на обмен, сколько доплатить». Менеджер: «извините, не имею возможности, я в другом городе». Всё, человек ушёл. Надо было: «а вы в каком городе? доплата примерно от миллиона до трёх, зависит от комплектации, пришлите фото — скажу точнее». Правила, по которым он должен работать: — никогда не отвечать «нет»: нет в наличии — привезём, назвать срок; — не звать на осмотр раньше, чем человек услышал хоть какую-то цену; — не говорить «мы не можем оценить», вместо этого задать уточняющий вопрос; — точной цифры нет — дать вилку и сказать, от чего она зависит; — слово «хочу» это стоп, дальше человек; — не кидать заготовленные фразы невпопад, не отрабатывать возражение, которого не было. Пишет от имени нашего менеджера, у каждого своё имя в переписке. Не нужно: считать стоимость обмена, подбирать комплектации, консультировать по технике, интеграция с 1С, голос. Напишите, пожалуйста, сколько стоит и сколько займёт. Если можно начать с урезанного варианта на одном канале — скажите, во сколько встанет он. Работаем удалённо.

Сфера деятельности: Магазин цветов. У нас небольшой цветочный магазин. Раз в две-три недели считаем остатки, и это отнимает целый вечер. Как сейчас: сотрудник идёт к холодильнику и наговаривает голосовыми всё, что там стоит, по сообщению на позицию, обычными словами — «лилии жёлтые 70 штук Голландия». Выходит 60–100 голосовых. Плюс фотографии распечаток: составы собранных букетов и брони клиентов, ещё 20–30 кадров. Потом человек три часа сводит это руками в одну таблицу. Нужна система, которая делает эту таблицу сама из голосовых и фотографий. Главное требование, и оно важнее всего остального: разные позиции не должны попадать в одну строку. Расшифровка слышит названия криво, и система, подбирая похожее по буквам, может отправить две разные позиции в одну строку. В таблице тогда один цветок с большим количеством, а два других исчезли. У нас так и было: в одну строку собралось пять разных позиций, больше сотни штук уехали не туда, и нашли мы это только пересчитав всё заново. Поэтому правило такое: не распознать лучше, чем распознать неправильно. Не уверена — пусть отложит отдельно и скажет. Разобрать десять отложенных строк я готов, искать пропавшую сотню в правильной с виду таблице — нет. Сложность в названиях: около 300 наименований, половина — сорта роз, латиница, произносимая вслух по-русски у шумящего холодильника. Размер входит в название: Explorer 50-70, Explorer 100 и Explorer гигант 110 — три разные позиции. Ещё нужно, чтобы от любой цифры в итоге можно было доехать до конкретного голосового или фото, из которого она взялась. Не нужно: связи с кассой и 1С, мобильного приложения, прогнозов закупки. Напишите, пожалуйста, сколько это стоит и сколько займёт. Работаем удалённо.

Сфера деятельности: Пищеводе производство. Необходимо перенести данные из другой crm и настроить интеграции, все подробности будут указаны в ТЗ.

Сфера деятельности: Консалтинг, учебный центр. Компания БАРС Консалт, Казань. Помогаем строительным компаниям получать допуски: СРО, лицензии, обучение, аттестация. Отдел делопроизводства всё делает руками - хотим это убрать. Что сейчас вручную: - документы от клиента (паспорт, диплом, трудовая) приходят фото в Телеграм; - данные из сканов переносятся в заявки глазами и руками; - стаж по трудовой книжке считается вручную; - заявления в учебный центр заполняются вручную; - программа обучения подбирается вручную; - калькуляции ведутся в самодельных таблицах отдельно от Битрикс24 и 1С. Системы: Битрикс24, 1С, Телеграм, самодельные таблицы. Как отбираем: анкета - короткий разбор одной операции - созвон на час с директором и руководителем отдела - ваша проработка и предложение по проекту с вашей ценой - выбор исполнителя. В проработке ждём разбор процессов, а не презентацию: по каждой операции вход, шаги, системы, время, частота, узкое место, цена ошибки. Плюс маршрут автоматизации и оценка эффекта в часах. Удалённо, регион не важен. Самозанятый, ИП или ООО. Цену называете вы. Ответьте, пожалуйста, по пунктам: 1. Кто вы и сколько человек в команде. 2. Два-три кейса по документообороту или распознаванию документов, с пруфом. 3. Чем работаете: Claude, GPT, n8n, Make, Python, RPA. 4. Как разбираете процессы: сколько интервью, что меряете. 5. Что войдёт в проработку - списком. 6. Сколько времени займёт и когда готовы созвониться. 7. Опыт с системами без API - заполнение форм в чужом портале. 8. Как работаете с персональными данными. 9. Готовы разобрать одну нашу операцию как пример.

Автоматизировать бизнес. Сфера деятельности: Финансы. # Разработка высокоскоростной серверной API-интеграции с банком Ищем **сильного backend-разработчика / специалиста по высокопроизводительным API-интеграциям** для разработки и оптимизации серверного решения по массовой передаче заявок через API банка. У нас есть: * действующий партнерский доступ к API; * подробная документация API; * реальные данные для отправки; * существующий процесс передачи заявок; * несколько партнерских аккаунтов; * возможность предоставить документацию и тестовые данные исполнителю. **Главный критерий проекта — скорость отправки заявок.** Заявки передаются через API отдельными запросами. Необходимо построить серверное решение, которое сможет максимально быстро передавать большой массив заявок, используя допустимую параллельность и соблюдая технические ограничения API банка. Для нас особенно критична скорость непосредственно после **00:00:00**, так как в это время начинается массовая отправка заявок. ## Основная задача Необходимо разработать систему, в которой все тяжелые операции по возможности выполняются **до наступления 00:00**. До начала отправки должны быть заранее выполнены: * получение исходных данных; * проверка обязательных полей; * валидация данных; * нормализация телефонных номеров; * проверка ИНН, КПП, ОГРН и других параметров; * определение необходимых кодов и справочников; * преобразование исходных данных; * формирование JSON; * подготовка финальной очереди заявок. К моменту запуска массив должен быть полностью готов к отправке. После наступления заданного времени сервер должен практически сразу начать передачу запросов в API. ## 1. Максимально быстрая отправка заявок Это главная часть проекта. Необходимо изучить документацию API банка и определить оптимальную архитектуру передачи большого количества отдельных запросов. Рассматриваем использование: * asynchronous I/O; * connection pooling; * HTTP keep-alive; * нескольких workers; * очередей; * эффективной JSON-сериализации; * предварительной подготовки payload; * оптимизации DNS / TLS / network latency; * других технических способов уменьшения времени отправки. Количество параллельных запросов нельзя выбирать произвольно. Разработчик должен: 1. изучить документацию API; 2. определить технические ограничения метода отправки заявок; 3. определить ограничения партнерских аккаунтов; 4. провести допустимые тесты производительности; 5. определить оптимальный уровень concurrency; 6. определить максимально достижимый реальный RPS; 7. настроить систему так, чтобы максимальная скорость не приводила к росту количества ошибок. Нам нужен не просто разработчик, который поставит большое количество потоков, а специалист, который сможет технически определить **оптимальную архитектуру массовой отправки HTTP-запросов**. ## 2. Работа с несколькими партнерскими аккаунтами Система должна поддерживать работу сразу с несколькими нашими партнерскими аккаунтами/API-ключами. Для каждого аккаунта необходимо отдельно учитывать: * API-ключ; * авторизацию; * очередь заявок; * ограничения; * статистику; * ошибки; * результаты отправки. Необходимо предусмотреть удобное добавление новых партнерских аккаунтов без существенной переработки системы. Если правила API позволяют одновременную работу нескольких наших партнерских аккаунтов, система должна эффективно использовать эту возможность. При этом архитектура должна соблюдать ограничения API и условия партнерской работы банка. ## 3. Предварительная подготовка данных Все операции, которые можно выполнить заранее, должны выполняться **до начала массовой отправки**. В частности: * проверка структуры данных; * проверка обязательных полей; * приведение телефонов к необходимому формату; * проверка ИНН; * проверка КПП; * проверка ОГРН; * подготовка cityCode; * подготовка кодов продуктов; * получение и локальное хранение необходимых справочников; * формирование готовых JSON payload; * подготовка очереди. Цель — чтобы непосредственно после 00:00 сервер занимался практически только отправкой заранее подготовленных HTTP-запросов. Необходимо максимально убрать из критического участка: * тяжелые вычисления; * обращения к базе данных; * преобразование данных; * получение справочников; * лишние сетевые запросы. ## 4. Точный запуск около 00:00:00 Необходимо обеспечить максимально точный старт массовой отправки. Предусмотреть: * синхронизацию системного времени сервера; * NTP; * постоянно работающий процесс; * заранее сформированную очередь; * отсутствие запуска тяжелой подготовки непосредственно в 00:00; * минимальный scheduler jitter; * готовность сетевых компонентов к моменту запуска. Для нас важен не просто запуск программы по расписанию. Нас интересует минимальное время: **от 00:00:00 до фактической отправки первого запроса в API банка.** И далее — максимально быстрое прохождение всей очереди. ## 5. Надежность и обработка ошибок Высокая скорость не должна приводить к потере заявок или бесконтрольному появлению дублей. Необходимо реализовать грамотную обработку: * HTTP 400; * HTTP 401; * HTTP 403; * HTTP 500; * HTTP 503; * timeout; * connection reset; * временной недоступности API; * невалидных данных; * технических дублей; * ограничений по количеству заявок. Особенно важна ситуация: **запрос отправлен ? соединение оборвалось / произошел timeout ? неизвестно, была ли заявка фактически принята банком.** В такой ситуации нельзя просто бесконтрольно повторять POST-запрос. Необходимо разработать безопасную retry-логику, которая минимизирует риск: * потери заявки; * повторного создания заявки; * ненужной задержки всей очереди. Ошибка одной заявки не должна блокировать отправку остальных заявок. ## 6. Сохранение результата каждой отправки При успешном создании заявки API возвращает уникальный идентификатор заявки. Этот ID необходимо обязательно сохранять. Нужно хранить связь: `наша запись ? партнерский аккаунт ? время начала запроса ? время ответа ? HTTP-код ? ID заявки банка ? результат` Это необходимо для: * контроля фактической доставки; * последующей проверки; * исключения дублей; * разбора ошибок; * оценки производительности; * сравнения результатов разных партнерских аккаунтов. ## 7. Логирование Необходимо подробное техническое логирование. Для каждого запроса желательно сохранять: * внутренний ID записи; * партнерский аккаунт; * время постановки в очередь; * время начала отправки; * время получения ответа; * latency; * HTTP status; * результат; * ID заявки; * текст/код ошибки; * количество повторных попыток. При этом логирование само по себе не должно становиться узким местом и снижать скорость массовой отправки. ## 8. Мониторинг производительности Необходимо реализовать понятную статистику по каждому запуску. Хотим видеть: * общее количество заявок; * время запуска процесса; * время первого отправленного запроса; * время первого успешного ответа; * количество отправленных заявок по секундам; * RPS; * concurrency; * среднюю latency; * p50 latency; * p95 latency; * p99 latency; * количество успешных запросов; * количество ошибок; * количество retry; * время завершения всей партии. Отдельно должна быть статистика по каждому партнерскому аккаунту. Например: **Размер партии:** 10 000 заявок **Запуск:** 00:00:00.000 **Первый запрос:** 00:00:00.030 **Первый успешный ответ:** 00:00:00.120 **100 заявок принято:** 00:00:XX **1 000 заявок принято:** 00:00:XX **5 000 заявок принято:** 00:00:XX **10 000 заявок обработано:** 00:00:XX **Средний RPS:** XXX **p50:** XX ms **p95:** XXX ms **p99:** XXX ms **Ошибки:** XX Нам важно иметь возможность объективно сравнить существующее решение с новым. ## 9. Тестирование производительности После разработки необходимо провести тесты с разным уровнем параллельности. Например: * небольшой уровень concurrency; * средний; * повышенный; * максимально допустимый API. Конкретные значения необходимо определить после изучения документации и поведения API. Задача — найти точку, при которой увеличение параллельности перестает давать прирост полезной производительности либо начинает приводить к: * росту latency; * увеличению количества ошибок; * timeout; * HTTP 500/503; * ограничениям со стороны API; * падению количества успешно созданных заявок в секунду. Именно оптимальный режим необходимо использовать в production. ## 10. Возможность настройки без изменения кода Желательно вынести основные параметры в конфигурацию: * время запуска; * количество workers; * concurrency; * timeout; * параметры retry; * количество партнерских аккаунтов; * распределение заявок между аккаунтами; * пути к исходным данным; * параметры логирования. Это позволит дальше оптимизировать систему без постоянной переработки исходного кода. ## Что должно получиться на выходе Нам необходимо получить полноценное серверное решение: 1. Высокоскоростной модуль отправки заявок. 2. Предварительную подготовку данных. 3. Работу с несколькими партнерскими аккаунтами. 4. Очередь заявок. 5. Точный планировщик запуска. 6. Управление concurrency. 7. Надежную retry-механику. 8. Защиту от повторной отправки. 9. Сохранение ID созданных заявок. 10. Подробное логирование. 11. Метрики производительности. 12. Возможность настройки параметров без изменения кода. 13. Docker / удобное развертывание. 14. Исходный код проекта. 15. Инструкцию по установке и эксплуатации. 16. Помощь при первоначальном запуске и тестировании. ## Кто нам нужен Ищем человека с реальным опытом разработки **высокопроизводительных backend/API-систем**. Нужен опыт в: * Python / Go / Java / Node.js или другом подходящем backend-стеке; * REST API; * asynchronous programming; * HTTP connection pooling; * keep-alive; * concurrency; * multithreading / multiprocessing; * очередях; * Docker; * Linux; * PostgreSQL / Redis при необходимости; * профилировании; * нагрузочном тестировании; * оптимизации network latency; * обработке большого количества HTTP-запросов. Большим плюсом будет опыт: * банковских API; * fintech; * платежных систем; * рекламных API; * биржевых API; * высоконагруженных интеграций; * систем, где критична скорость обработки и отправки запросов. ## Важно **Нас не интересует обычная последовательная API-интеграция:** `взяли запись ? отправили запрос ? дождались ответа ? взяли следующую запись`. Основная задача проекта — определить и реализовать архитектуру, которая позволит **максимально быстро передавать большой объем заявок в API банка**, сохраняя надежность и соблюдая технические ограничения API. ## Что написать в отклике Просьба не писать просто «готов выполнить». Ответьте, пожалуйста, на следующие вопросы: 1. Был ли у вас опыт массовой параллельной отправки HTTP/API-запросов? 2. С какими объемами данных вы работали? 3. Какой максимальный реальный RPS был в ваших проектах? 4. Какой стек предложили бы для нашей задачи и почему? 5. Как будете определять оптимальный уровень concurrency? 6. Как организуете connection pooling и keep-alive? 7. Как будете обрабатывать timeout, если неизвестно, была ли заявка фактически создана? 8. Как защититесь от двойной отправки при retry? 9. Как будете измерять реальную производительность? 10. Как будете организовывать работу нескольких API-аккаунтов? 11. Есть ли опыт проектов, где критична скорость первых запросов после определенного времени? После первичного отбора предоставим **документацию API банка** для более предметной оценки архитектуры, сроков и стоимости. **Стоимость обсуждается. Приоритет — подтвержденный опыт высокопроизводительных API-интеграций и техническое качество решения, а не минимальная цена.**.

Сфера деятельности: Покупка ключа Орион про. Пожелания и особенности: Покупка ключа Орион про 1.20+.