- Home
- Platform
The BetterWrk platform
Different specialised applications. One operating environment.
Each BetterWrk product is good at its own job. What makes it a platform is everything underneath: one identity model, one set of records, one permission system, one event stream and one release pipeline that governs how any of it changes.
The four planes of the environment
What people use
Finished products, not a toolkit. Your team logs in and does the work.
What they share
One customer, one employee, one agreement, one permission model, one event stream.
ProcessScout
Sees where the work becomes difficult, gathers feedback in context and turns it into a defined requirement.
How it is allowed to change
Every material change is linked to a requirement, tested, approved, gated and reversible.
The application layer
The applications are finished products.
Nothing here is a template you complete. Each product ships with the screens, permissions, approvals, reports and integrations its function needs, and a team at BetterWrk who is accountable for it working.
BetterWrk CRM
Pipeline, accounts and the promises made during the sale, kept where delivery can see them.
AgreeBetterWrk Sign
Draft, approve, sign and activate. The signature starts the next step rather than ending the conversation.
PeopleBetterWrk People
One employee record from offer to leaving date, with the approvals managers actually use.
PayBetterWrk Payroll
Run payroll in the country where the work happens. Tax, filings and bank files included.
AccountBetterWrk Finance
Invoice, collect and account against the delivery that actually happened.
OperateBetterWrk Automate
Cross-functional sequences with named owners, exceptions and escalation.
The operating model
Shared identity, data, permissions and events.
This is the part that competitors cannot bolt on afterwards. Integration between separate SaaS products is a set of copies that drift. Inside BetterWrk there is one record, and every application is reading the same one.
When a person changes role, the change is not published to five systems and hoped for. It happens once, and the systems that depend on it respond to the event.
- Identity
- One account per person across every application, with single sign-on to your existing identity provider.
- Records
- A canonical customer, employee, agreement, invoice and organisation. Products hold their own detail, not their own copy of the truth.
- Permissions
- One model covering roles, entities, data scopes and approval authority. Payroll visibility is not a separate universe from CRM visibility.
- Events
- Meaningful things that happen — agreement signed, employee started, invoice issued — are published once and consumed by whatever needs them.
- Audit
- Who changed what, when, under which approval. The same trail covers user actions and BetterWrk releases.
- Support
- One place to raise a problem, whichever application it appeared in.
The intelligence layer
ProcessScout is where the environment learns.
The applications tell you what happened. ProcessScout tells you where the design of the work is costing you, connects it to the people doing the work and turns that into something BetterWrk can act on.
Observe
Interaction patterns and application events: repeated clicks, re-entry, errors, delays, abandoned workflows.
Understand
Ask the user what happened, in context, and link the answer to the process and the affected records.
Improve
Choose the honest intervention: training, configuration, integration or a new capability.
Verify
Test, approve, release, then measure against the problem that started it.
Change and release control
A change is not a favour. It is a controlled release.
Continuous improvement only works if it is boring. Every material change follows the same path, whether it is a field, a rule or a new capability.
Linked to a requirement
No change exists without an agreed statement of what it is supposed to fix and how you will know it did.
Tested before it is offered
Automated tests plus human review. Where possible, changes are validated against your own historical cases.
Approved by the right owner
Payroll, finance, permissions and contract logic require the named customer approver, not just a BetterWrk sign-off.
Released behind a gate
Customer-private first, then wider only if it is genuinely general and you agree to it.
Monitored after release
The measure that justified the change is watched afterwards. A change that did not work is reported as such.
Reversible
Feature gates mean withdrawing a change is a switch, not a project.
What BetterWrk owns
Owned software, and open source we are accountable for.
BetterWrk owns most core applications outright. Where a mature open-source component does the job better than anything we would write, we use it — and we take responsibility for the version you run.
- Core applications are BetterWrk-owned, so a fix is never blocked by another vendor’s roadmap.
- Open-source components are distributed as BetterWrk-certified builds, pinned, patched and supported by us.
- Governed source access covers the remainder, so customer-specific work is possible without forking the world.
- A software bill of materials and open-source notices are available to your procurement and security teams.
Data and integration
Your other systems do not have to leave.
Replacing everything at once is how transformation programmes fail. BetterWrk is designed to sit alongside what you keep.
- Documented APIs and events for every canonical record.
- Connectors to the systems you are keeping, built and maintained as part of the environment.
- Migration of the history you need, with reconciliation you can check.
- Export of your data and configuration on request, in a documented format, for as long as you are a customer.
Deployment and continuity
Where it runs, and what happens if we part company.
Enterprise buyers are right to ask what dependency they are taking on. These are the answers before you ask for them.
- Managed runtime
- The default. BetterWrk operates the environment, applies updates and holds the availability commitment.
- Customer cloud
- Available for customers with a specific residency, network or regulatory requirement. Support boundaries are defined in writing.
- Self-hosting
- Available under Buy + Assure for qualifying customers. Some regulated modules carry limits, and we state them rather than discovering them later.
- Data residency
- Selected at the environment level and documented, including subprocessors.
- Exit
- Your data and configuration are exportable throughout. Buy + Assure adds a qualifying fallback operating right so the software does not stop being usable when the relationship does.
- Escrow
- Source-code escrow options are available where a customer’s risk position requires them.
Start where the evidence is.
A Trail Map documents how the work moves through your business today, what the friction costs and which parts of this environment you would actually use first.