Industry
Professional services
Professional services firms sell time and judgement. The operational questions are always the same: who is available, what is this engagement actually costing, and where is the knowledge from the last similar piece of work.
Workflows
The work that actually happens here
Named the way practitioners in this sector name them, because that is the vocabulary a delivery team has to learn before it can be useful.
- Opportunity and engagement setup
- Converting a pursuit into a scoped engagement with a budget, a team and a commercial model.
- Resource planning
- Matching people to engagements against skills, availability and development goals, with utilisation visibility.
- Time and expense
- Capture that people will actually complete, with approval and client-rechargeability rules applied.
- Engagement financials
- Budget against actuals, margin, work in progress and revenue recognition per engagement.
- Knowledge management
- Making prior work findable and reusable, with permissions that respect client confidentiality.
Constraints
What changes the architecture
These are the reasons a design that works elsewhere would be wrong here.
Client confidentiality constrains knowledge sharing
Reuse of prior work is limited by confidentiality obligations. Knowledge systems need permission models and redaction rather than open search.
Conflicts of interest must be checked
Taking on work requires conflict checking against existing clients and matters before engagement.
Time capture is the weakest link
Every downstream financial number depends on data people enter reluctantly. Capture design determines the reliability of the entire financial picture.
Revenue recognition rules are specific
Fixed-fee, milestone and time-based engagements recognise revenue differently, and the system must reflect that rather than approximate it.
Integrations
Systems we would expect to meet
- Microsoft 365 or Google Workspace for calendar and identity
- Accounting and ERP systems
- CRM systems
- Document management with client-matter structure
- Business intelligence for utilisation and margin reporting
Trust considerations
What users and regulators need here
- Client-matter separation must be enforced in the data layer, particularly where conflicts exist.
- Knowledge reuse requires explicit permission and, frequently, redaction.
- Individual utilisation data is employee data with its own handling obligations.
- Client-facing reporting should show the same numbers the internal team sees.
Architecture
A shape we would actually propose
A starting sketch, not a template. Discovery is what turns this into a specific design with recorded trade-offs.
- Core model
- Client, matter, engagement and assignment as first-class entities with explicit membership.
- Access
- Row-level security by client and matter, with conflict-check enforcement at engagement creation.
- Capture
- Low-friction time capture on mobile and desktop with calendar-derived suggestions.
- Financials
- Engagement ledger supporting fixed-fee, milestone and time-based recognition.
- Knowledge
- Permission-aware search where results are filtered by entitlement at query time, not at index time.
Outcomes
What good looks like
- Reliable utilisation and margin reporting derived from capture people will actually complete
- Conflict checking enforced at engagement creation rather than discovered later
- Prior work findable within confidentiality constraints
- Engagement financials visible early enough to act on
Next step
A professional services project starts with the constraints
The Project Architect asks sector-specific questions about data, regulation and integration before it asks about features.