Using the product
How work actually moves through Harold: end-to-end journeys with roles, inputs, outputs, and exception paths - written for operators and reviewers, not reverse-engineers.
Operating model
Why workflows
Enterprise teams rarely fail because a single button is hard to find. They fail when hand-offs break: signal arrives, context fragments, approvals stall, and distribution happens without a defensible trail. Harold is documented around workflows so you can evaluate fit, onboard quickly, and train teams against how work actually moves - not against isolated feature lists.
End-to-end
Signal to distribution
A typical operating cycle connects pipeline signal to a deal record, attaches documents and inbox threads, moves through review and reporting, and finishes with controlled distribution. Each stage has clear owners, expected artefacts, and exception paths (rework, escalation, or pause) that mirror how institutional desks run.
What each stage should answer
- Ingest - what entered the workspace, from whom, and under which mandate?
- Organise - where does it live in the deal spine and who is accountable?
- Analyse - what decision or artefact is being prepared, and who approves it?
- Distribute - who receives what, under which template, and with what audit trail?
Playbooks
Common patterns
Patterns repeat across desks: triage inbound opportunity, attach diligence to a live deal, produce an IC-ready pack, issue a controlled teaser, or close the loop on tasks after a client meeting. The product modules are composed to support these patterns; the left navigation lists each module by business outcome.
Exceptions & escalation
When data is missing, permissions block an action, or an integration pauses, Harold should surface the next best step - without exposing internal retry logic. Operators escalate through tasks, comments, and support channels; administrators review audit history and integration health in the admin surfaces.
Was this page helpful?