What Opero is

Do czego służy Opero, czym różni się od arkusza i skrzynki pocztowej, z czego składa się system i dlaczego u każdej firmy wygląda trochę inaczej.

A system that runs the company's work

Opero is the place where a company runs its matters: contracts, tickets, projects, documents, clients. Instead of keeping them in spreadsheets, folders, and mailboxes, they are kept in one place, in a fixed form, and with a recorded course.

This is not a single-purpose program. Opero adapts to how a company works, which is why it looks a little different at every client. The way it works is shared; the areas and names differ.

A matter instead of a file

The unit of work in Opero is the record: one contract, one ticket, one invoice. A record has its fields, attachments, comments, and a recorded change history, so everything about a matter is in one place instead of in several mailboxes.

A record run by a process additionally has a stage, that is, a place in the flow. Thanks to this, the question about progress is answered by looking at the matter, not by asking one person after another.

What the system is made of

Opero can be described in four layers. Each of them has its own part of this documentation.

Data. Records, that is, individual matters, things, and documents, grouped into objects.
Processes. Fixed paths along which matters move from start to finish, together with approvals and tasks for specific people.
Automation. Rules that carry out repetitive actions without the user's involvement: they compute values, remind about deadlines, notify the right people.
Presentation. What you see: lists, forms, printable documents, and reports.

These four layers recur in every area of the system. Contracts, invoices, and tickets differ in content but work according to the same pattern.

Opero does not replace an accounting program. It runs the document flow, watches deadlines, and passes data on, but the accounting itself and tax settlements stay on the accounting side. This is a deliberate boundary, not a gap.

Differences between instances

This documentation describes the system's capabilities, while an instance is built for the organization's needs. Three things make the screens differ.

Enabled areas. Not every company uses everything.
Names. Objects and fields are named in the client's industry vocabulary.
Permissions. Everyone sees what belongs to their work.

So while reading the documentation, treat names as examples. The principle is the same, even if an object carries a different name.

Uses of the recorded history

Every change in the system leaves a trace: who made it and when. This sounds like control, but in practice it resolves disputes instead of creating them. The question "who changed the amount on this contract" stops being something to establish and becomes a matter of checking the history.

The same principle applies to automation: if something was changed by a rule or an integration, the history will show it.

Getting started

If you are starting out with the system, read the three topics from the First steps section in order: first steps, getting oriented in the system, and basic concepts. They take fifteen minutes and save most of the questions of the first week.

The scope and layout of the documentation describes the layout of these pages. First steps describes the first day of work. Basic concepts explains the vocabulary. Getting oriented in the system describes the screen layout.