Product
What Consonas does
Everything on these pages is built and running. We describe the product that exists rather than the one we intend to build, because the second kind of page produces signups that leave within a fortnight.
The thirteen
Every part, and what each one is for
Relationships
People and organisations as one family of records, the connections between them, the timeline, files and consent.
About relationshipsLeads
Capture, qualification, conversion into a customer and a piece of work, and reporting on which sources produce which.
About leadsSales
Pipelines with your own stages, opportunities, stage history and a weighted forecast.
About salesWork and calendar
Tasks against any record, a daily view of what needs doing, and appointments with clash reporting.
About work and calendarEmail and conversations
Messages held against the relationship they concern, so a thread is part of the record rather than in someone's inbox.
About email and conversationsFollow ups and booking
Sequences that stop the moment somebody replies, and a booking page that writes into the same calendar.
About follow ups and bookingMarketing and automation
Audiences that keep themselves current, campaigns that check consent for every person at the moment of sending, and rules that cannot run away.
About marketingService and the portal
Matters with targets counted in working hours, and a portal where customers see their own enquiries and nothing else.
About service and the portalProjects and invoices
Work planned and delivered, invoices numbered without gaps and settled by recorded payments, contracts with a second pair of eyes when you ask for one.
About projects and invoicesConnecting other systems
Calendars both ways, mailboxes, forms and the public sources. Accounting is named and not built, so today it is an export rather than a connection.
About connecting other systemsReporting
A dashboard of the measures a small organisation actually looks at, scoped to what each person is allowed to see.
About reportingImport, export and search
Bring a spreadsheet in with a preview you approve, search everything you are allowed to see, and take it all back out whenever you like.
About import, export and searchPermissions and the audit trail
Roles, record ownership, sensitivity, sharing, and a record of who changed what and when.
About permissions and the audit trailSeventeen trades have a page of their own, written one trade at a time and going further than a tile can: professional services, recruitment agencies, maintenance and facilities, construction and charities among them, with the whole list in one place.
The actual interface
Not a rendering of it
Two photographs of the running product with real records in it. No mock ups, no rearranged panels, nothing painted in afterwards.
How it fits together
One record, and everything hanging off it
The thirteen pages above describe parts of one product rather than thirteen products sold together. This is the shape they share.
Everything attaches to a relationship
A lead converts into one. An opportunity belongs to one. A task, an appointment, a message, a matter, an invoice and a file all sit against one. That is not an architectural detail, it is the reason the timeline works: reading a customer record means reading what actually happened, in order, across every part of the product, rather than reading one module's account of it.
Permission is decided once
Roles, ownership and record sensitivity are defined in one place and respected everywhere: in search, in reports, in the export and in the customer portal, each checked independently rather than through a single gate.
Consent is held on the person
Not on a list, not in the marketing module, and not per campaign. It is a fact about a person, held per channel with a date and a source, and every part of the product that sends anything checks it again at the moment of sending.
The rights somebody exercises over what you hold about them come from the Data Protection Act 2018, and retention rules are kept separate from consent: what kind of record, how long after what, and whether to remove it or to strip the person out of it.
Time is counted in working hours
Targets, durations and sequence steps all use the same clock, defined per organisation. A four hour target on a Friday afternoon is due on Monday morning throughout, rather than in the service module only.
The ideas underneath
Three decisions that explain most of the rest
Almost everything that looks unusual about Consonas follows from one of these, and each of them is checkable on the pages above.
- Refuse rather than guess
- Where a mistake is expensive the product refuses and explains. It will not issue an invoice number out of sequence, will not accept a credit note larger than what remains uncredited, will not let one person approve their own contract, and will not create an organisation in a region it cannot honour.
- Obligations are not a tier
- The audit trail, consent records, subject access tooling, two factor sign in and complete export are on every plan including the free one, permanently. The evidence you need when something goes wrong does not arrive with an invoice.
- Limits are enforced, not described
- Eight of the ten published limits refuse at the boundary with an explanation instead of failing silently or producing a surprise charge. Two warn instead and keep working: file storage and monthly API calls. That is deliberate, because the cost of stopping is worse than the cost of overshooting on both, and the same reasoning exempts an import from the relationship limit: a migration must not stop halfway. Every limit warns before it refuses, at eight parts in ten, on the plan panel. A limit that only exists on a pricing page is one that gets discovered by accident.
Someone picking up a relationship for the first time should be able to read down it and know where things stand, without asking the colleague who is on holiday.
Which is the test every part of the product is built to pass.
Eight absences
What the whole product does not do
Collected in one place, so you can decide quickly whether to keep reading.
No accounting. No ledger, no bank reconciliation, no VAT return, no payroll, no submission to HMRC, no payment collection. Decided against rather than not yet built.
No billing from recorded time. Time can be recorded against a project, in minutes, on a day, with a note, on the delivery module, and there is a view of what each person has recorded against their capacity. What there is not is billing from it: no rates, no job costing, and no invoice raised from recorded time. If you bill by recorded time, an agency or practice management product is the right purchase.
No stock, no point of sale and no ecommerce. The catalogue that exists is a price list for building quotations, and treating it as inventory would be a mistake.
No clinical, legal or property specific systems. Consonas is not a clinical records system, not practice management, not a property management system and not construction project management. Each of those sector pages says so directly.
No chat, no SMS and no telephone integration. Email and the record of conversations.
No cold outbound tooling. No contact database, no address finding, no automated multichannel prospecting. A position instead of a gap.
No marketplace and few connections. The list of systems that connect is short and deliberately so, which is a real advantage the established competitors have.
No offline mode and no native mobile application. It works on a phone as a web application, and if your people work without signal that is a genuine limitation.
The roadmap separates the things that are being built from the things decided against, because a boundary is more useful to you than a promise. The customers page is equally plain about the other absence, which is that there are no customer stories to read yet.
The decisions behind the whole thing
Three choices made at the level of the product, and what each one costs
The thirteen pages above each carry their own reasoning. These are the decisions that sit above all of them, including the one we would reverse if the platform allowed it.
Your organisation gets its own database, not a share of one
The ordinary arrangement in this category is one large database with an organisation column on every table, and a great deal of care taken that no query ever forgets it. Consonas instead gives every organisation its own SQLite database inside its own isolated compute object, so the entire class of fault where somebody sees another organisation's data through a query that forgot a condition does not have a shape here. The costs are real: we know far less about aggregate usage than a competitor does, a schema change runs once per organisation rather than once, and an organisation with an enormous amount of data cannot be spread across machines the way a shared table can. Which half of the arrangement is Cloudflare's and which half is ours is on the security page, their platform documentation covers the half that is theirs, and one post works through what the choice costs us.
There is no United Kingdom region, and we would like there to be
The platform pins data to the European Union or the United States. It offers no United Kingdom option and there is no way to make one. This product once listed the United Kingdom in its region picker anyway, and organisations that chose it were given no residency guarantee at all, silently, with the marketing site repeating the claim. That was a promise the software could not keep, which is worse than a missing feature. The list now lives in one place, nothing accepts a value outside it, and the European Union is the default because it is the closest region and carries the data protection posture UK law expects. If you require data in the United Kingdom, buy something else, and be sceptical of anyone who tells you the region question is simple.
Thirteen pages describe one product, not thirteen products
Each part of the product declares which records it owns, which permissions it defines, and what an organisation must be paying for. That declaration is checked by the build, so a permission belonging to no part and a part claiming a permission that does not exist are both failures at the moment of writing rather than discoveries at the moment of using. What we rejected was the suite arrangement: separate applications, separately priced, each with its own idea of who a customer is. That is how organisations of this size end up entering the same person three times and reconciling the results by hand.
Before you sign up
Asked about the product as a whole
Do I have to use all thirteen parts?
No, and almost nobody does. Most organisations use relationships, work and one of sales or service, and never open the rest. Nothing is hidden or nagging you to turn it on, and an unused part costs you nothing.
Why is there a photograph on a site with no photographs?
Because a buyer who has read thirteen tiles is entitled to see the running product before signing up, and an illustration of an interface would be a drawing of a claim. Everything else on this site is illustration precisely so that these two are unambiguous.
Does everything really appear on the timeline?
Nearly. Relationships created, enquiries converted, opportunities created and moved, quotations, contracts, appointments booked and cancelled, messages, campaigns, sequence steps, matters, invoices, payments, tasks, projects and files all write to the relationship's history. Custom records keep their own history on the record itself rather than on a person, because most of them are not about one. Policies are the exception that stays an audit entry: they have no party to attach to.
What is the shortest way to understand the whole thing?
Read the relationships page, then the section above on how the parts fit together, then whichever of sales or service matches your trade. Three pages is enough to know whether the shape is right for you.
Or find out in an afternoon
The core of everything above is on the free plan, with no card and no time limit.
Three people, a thousand relationships, no card and no time limit.