Как НКО вести учет оказанной помощи и услуг

Возьмем простой пример.

В Космос CRM это не три записи Сергея и не одно поле, которое каждый раз переписывают. Это один клиент и три отдельные услуги.

У каждой услуги есть собственная запись и собственная связь с клиентом. Создание новой услуги не заменяет предыдущие.

Именно из таких записей постепенно складывается история помощи подопечному.

Если же хранить только «последнюю помощь», предыдущая история фактически исчезает из нормального учета.

Это различие особенно важно для НКО.

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

Это характеристика ситуации человека. Она говорит о том, что такая помощь ему нужна.

Но она не означает, что организация уже провела юридическую консультацию.

Факт оказанной помощи появляется только тогда, когда создается отдельная услуга.

У одного подопечного может быть потребность в юридической помощи и пока ни одной оказанной юридической услуги. А может быть наоборот: в процессе сопровождения ему провели три консультации в разные даты.

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

В Космос CRM каждая услуга обязательно относится к конкретному клиенту и к определенному типу услуги.

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

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

Это важная особенность системы: нет одной жесткой формы, одинаковой для всех НКО.

Например, в готовом пресете «Подопечный» для услуги предусмотрены поля «Тип услуги», «Дата оказания услуги», «Формат оказания», «Статус услуги», «Стоимость помощи», «Исполнитель», «Дата следующего контакта» и «Результат услуги».

Но это именно готовая стартовая конфигурация. Организация может настроить структуру под свои процессы.

Например, сумму помощи можно хранить как число, результат сопровождения — как длинный текст, формат оказания — как список, дату визита — как дату.

Здесь легко запутаться.

Допустим, сотрудник вносит услугу в CRM 20 мая, но сама консультация состоялась 17 мая.

В системе есть техническая дата создания записи — 20 мая. А фактическую дату оказания помощи можно сохранить отдельно в пользовательском поле «Дата оказания услуги» — 17 мая.

Обе даты правильные, просто описывают разные события.

В готовых пресетах Космос CRM «Дата оказания услуги» как раз создается отдельным полем типа «Дата».

Еще одна причина не хранить всю помощь в одном комментарии — разные виды работы требуют разного набора сведений.

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

В Космос CRM пользовательские поля относятся к типу услуги. Поэтому разные типы услуг могут иметь разную структуру.

При создании услуги сотрудник сначала выбирает клиента и тип услуги. После этого система показывает поля, настроенные для выбранного типа.

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

При этом в Космосе есть системные типы услуг, а внутри конкретного типа можно использовать дополнительные пользовательские поля.

Например, в быстром пресете «Подопечный» создается тип услуги «помощь подопечному», а более подробная классификация — консультация, психологическая помощь, юридическая помощь, продуктовая помощь и другие варианты — задается отдельным полем «Тип услуги».

Поэтому система не ограничивает НКО одной плоской классификацией.

Когда каждая помощь хранится отдельной записью, общий раздел «Услуги» становится журналом работы организации.

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

Например, если администратор сделал статус услуги доступным для фильтрации, сотрудники смогут отбирать услуги по статусу.

Для поля типа «Дата» используется фильтр по дате, для списков и чекбоксов — конкретные значения, для текстовых полей — текстовый поиск.

Отдельно можно фильтровать услуги по клиенту и типу услуги.

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

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

В карточке клиента в Космос CRM есть отдельный раздел услуг. Там отображаются последние пять услуг.

Если нужна полная история, можно нажать «Показать все услуги». Откроется общий раздел «Услуги» уже с фильтром по текущему клиенту.

Причем фильтрация идет по внутреннему ID клиента, а не только по его имени. Поэтому два человека с одинаковыми ФИО не объединятся в одну историю.

Иногда сотрудник создает услугу по ошибке. В Космос CRM такую запись можно удалить.

Удаление устроено как мягкое: услуга исчезает из пользовательского интерфейса, не участвует в отчетах и статистике, но факт удаления остается в журнале изменений.

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

Связь с историей сохраняется и в другом случае — если удален сам клиент.

Ранее оказанные ему услуги не должны превращаться в чужие или исчезать из учета. В интерфейсе такая запись отображается как относящаяся к удаленному клиенту с его внутренним ID.

Одна и та же модель подходит совершенно разным организациям именно потому, что поля настраиваются.

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

Поэтому слово «услуга» в Космос CRM нужно понимать широко.