Receive and assign
Identify the event or request that starts the work, attach its source record, and define the person or team responsible for the next step.
Operations automation
Relay Ops
An operations workspace for requests, approvals, and exceptions that move between business systems and the people responsible for them.
Discuss Relay Ops
PRODUCT FOCUS
One place for the work between business systems.
For service, sales operations, procurement, and internal operations teams coordinating requests across spreadsheets, inboxes, CRMs, or other business applications. Relay Ops focuses on ownership, progress, and the cases that need a person to step in.
- 01Requests and workflow ownership
- 02Approvals and exception queues
- 03Connected business records
A request keeps its owner and its history.
Coordinate and review
Move the request through agreed stages. Route approvals, missing information, and failed connections into a queue with an owner and a reason for review.
Close with a record
Confirm the completion criteria and keep the updates, decisions, and resulting records together. Define how an operator can retry, reopen, or escalate an unfinished case.
Sources and connections.
System APIs, event volumes, ownership rules, approval requirements, duplicate handling, and recovery procedures are reviewed during the enquiry. Connections are scoped around the workflow and the systems your team uses.
Requests and source records
Choose the CRM, service tool, form, or structured import that starts the workflow. Agree required fields, record ownership, and how duplicate requests are recognised.
Business applications
Map the ERP, customer, order, or internal application records involved in each step. Provider APIs, access rules, and failure conditions shape the integration.
Team notifications
Define who needs an assignment, approval request, or escalation message. Keep notification content and channels aligned with the team’s working process.
What the workflow
needs to deliver.
- A request queue with an owner, stage, and next action
- Approval and exception views tied to the source record
- Connection history with defined recovery and duplicate handling
- A record of who changed the work and how it finished
Follow one recurring request from start to finish.
Show us a routine case and a case that went wrong, including the systems and manual checks involved. We can map the stages, connection scope, and first workflow to discuss.
- Who owns the request at every stage?
- What makes a case complete?
- How are missing information and failed connections handled?
- Can an operator retry work without creating a duplicate?
Discuss Relay Ops.
Do we have to replace our existing business tools?
The enquiry begins with the tools already in use. We review their interfaces and decide which system remains responsible for each record, then scope the workflow around those boundaries.
What makes a useful first workflow?
Choose a recurring request with a clear starting event, an owner, repeatable stages, and a recognisable completion state. Include the unusual cases that currently create manual follow-up.
What happens when a connection fails?
The workflow needs a visible failure state, recovery instructions, and a record of attempted changes. Retry limits, escalation, and duplicate protection are agreed for each connection.
Can managers approve work before it moves on?
Approval stages can be included in the workflow scope. We define the approver, the information they need to see, the decision they can make, and how the result is recorded.
Does every step need AI?
Many workflow stages can use ordinary rules and integration code. AI can be discussed for language or document tasks where it helps, with evaluation and review requirements defined for that task.