Portal dopasowany do Waszego procesu, nie odwrotnie.

Kupić, gdy proces jest standardowy, a liczba użytkowników zewnętrznych ograniczona — gotowy produkt będzie szybszy i tańszy. Budować, gdy portal ma odwzorować Wasz konkretny proces, dopiąć się do Waszych systemów i obsłużyć dowolną liczbę klientów lub dostawców. Na pierwszej rozmowie powiemy, po której stronie jesteście — nawet jeśli to znaczy, że nic u nas nie kupicie.

Konta powstają przez zaproszenie. Logowanie działa linkiem w e-mailu albo hasłem, a dla firmowych kontrahentów przez single sign-on z Microsoftem lub Google'em. Role pilnują, żeby każde konto widziało tylko własne sprawy. Użytkownicy zewnętrzni niczego nie instalują — wystarczy przeglądarka.

Hosting jest w UE, a Being Labs to firma z Czech, więc cała współpraca podlega prawu europejskiemu. Portal zwykle nie tworzy zresztą nowej kopii danych — czyta je z systemów, w których już są. Umowa powierzenia przetwarzania to standard, a log audytowy dokumentuje, kto do czego sięgnął.

Tak — to zwykle główny powód, żeby w ogóle budować portal na zamówienie. Tam, gdzie jest API, korzystamy z niego; tam, gdzie go nie ma, pomagają eksporty albo bezpośredni odczyt z bazy. Portal pokazuje wtedy dane na żywo, a zgłoszenia — na przykład fakturę od dostawcy — zapisuje z powrotem do Waszego systemu.

Portal na zamówienie to jednorazowy projekt plus niskie koszty utrzymania — bez opłaty za każde konto zewnętrzne. Przy rozliczeniu za użytkownika rachunek rośnie z każdym klientem; punkt przecięcia wypada często już przy kilkudziesięciu użytkownikach zewnętrznych. Wyceniamy za projekt po pierwszej rozmowie.

Pierwsza wersja z jednym zadaniem to kwestia tygodni, nie miesięcy — bo nie zaczynamy od całej wizji, tylko od funkcji, która oszczędzi najwięcej e-maili. Reszta portalu rośnie razem z faktycznym użyciem.