Signing up
Registration starts with one field: your email address. A letter arrives with a link, and the password is chosen only after you follow it. Until then the account exists in exactly one state — unusable — so nobody ever picks a password for a mailbox they cannot open.
The link expires after a while. If no letter arrives, check spam and register again: when the address is already taken, the product answers with a letter saying so rather than with a message on screen, so the registration form reveals nothing about who is here.
Throwaway mailboxes are refused. Register with an address you will still have next month — invitations, password recovery and letters about your company's state all land there.
Creating a company
A company is created once and gets two permanent properties:
- A subdomain — 3 to 30 characters: latin letters, digits and hyphens. This is the company's address:
yourcompany.quevell.com. - A name — up to 200 characters, shown to people in the interface.
A new company starts a 30-day trial with everything the product has. One mailbox can begin at most three free trials, ever — what counts is trials begun, not companies currently existing, and name+tag@domain addresses count as one mailbox. The owner of a company that already pays is not subject to this cap.
Inviting people
People are added by a company administrator, or by anyone granted the right to manage people: a name, an email address and a role. The invited person gets a letter with a link and chooses a password through it, by the same mechanism as registration. Until the first sign-in the person is listed as added; after it, as active.
A person is in one of four states: added, active, deactivated, deleted.
Deactivation closes the way in. Everything they did stays in history under their name, and the reason is kept on the record. Access can be opened again, and they carry on where they left off.
Deletion is a second, separate step: only a deactivated person can be deleted. First everything they hold moves to a successor — see offboarding. While any of it is not zero, deletion is refused.
The deletion itself erases the personal data — the address, the photo, the city, the timezone, the profile fields — and replaces the name with an impersonal signature, one for the whole company. The records stay where they are: issues, comments, attachments, lines of the trail. What changes is what the signature beside them says. It cannot be undone: the product keeps no copy to restore a name from. The action is confirmed by writing the person's address.
An invitation nobody has signed in under is revoked in one step: the link stops working and the address is free again. The same person can always be invited back, and their earlier history comes with them.
Roles
A company has three roles:
| Role | What it means |
|---|---|
| Member | Works in the projects they were let into. No say over company settings. |
| Trusted user | Grants nothing by itself. It is the right to request administrator rights for a limited time, and every such request is recorded. |
| Administrator | Configures the company: people, rights, projects, automation, system settings. |
Each project has its own roles, assigned separately to a person or a group:
| Project role | What it allows |
|---|---|
| Viewer | See the project. |
| Contributor | Create and edit issues, change statuses, comment, attach files, log time, write the project's knowledge base. |
| Project administrator | All of the above, plus access management, boards and issue security. |
Individual rights on top of roles are granted point by point — reading the company-wide automation journal, or viewing the organization chart.
The first project and the first issue
A project is created by whoever holds the right to create projects; the creator becomes its administrator. A project has two required properties:
- A key — 2 to 10 uppercase latin letters and digits, starting with a letter. Issue numbers are built from it:
OFFICE-13. - A name.
A new project arrives with a standard set of issue types, fields and a workflow, all adjustable later. An issue requires two things: a summary and a description. The description is always required, imports included — an issue without one is an issue whose meaning only the author remembers, and not for long.
Seats and service accounts
The plan counts seats: how many people may change data. The trial includes 10. One invitation beyond the limit still goes through, with a warning on screen — a team outgrowing its plan mid-onboarding should hear about it once, not be stopped halfway. The next invitation beyond that is refused.
Service accounts — the identities integrations and automation rules act as — are counted separately and take no seat from a person: 5 on the trial, 1 on the free plan. Their requests are rate-limited.
The end of the trial, and the free plan
Five days before the trial ends, the owner and the administrators get a letter. On the day itself nothing switches off: every feature stays, and the company moves to the free plan with 5 seats instead of 10.
Who holds the seats is the owner's decision, made on the people screen. Once, on the day of the fall, the product applies a default — the owner plus four others — and never rearranges the seats behind your back again.
People outside the seats read everything: every screen they could open before, search, history, journals within their rights, and they can export data until the company's last day. What they cannot do is write — not an issue, not a comment, not a status change, not a file, not a worklog.
Silence and the archive
A company nobody has entered for three months gets a warning letter, then is archived. An archived company is closed for work, but exporting data remains possible. Thirty days after archival the data is deleted for good. A single sign-in restarts the silence clock.