Clarify who owns what
Assign customers, sites, services, queues, assets, actions, and approvals to the right internal or MSP role.
For co-managed IT
Share the work while keeping responsibility clear.
Define what the MSP and internal IT team can see, approve and change. Evaluate a shared workflow with explicit client scope and a record both sides can understand.
Start with the decision
What needs to work better?
Collaborate on one record
Share permitted tickets, alerts, changes, documents, reports, and decisions without duplicating the work.
Preserve customer control
Use customer-visible approvals and audit history for changes that affect their users, systems, data, or spend.
Follow the work
A practical agenda for your walkthrough.
Use your own operating problem to review each decision and the record it should leave.
- Define
Agree the responsibility model
Map services, actions, escalation paths, approvals, and visibility before onboarding.
- Operate
Route work to the accountable team
Use shared queues and ownership rules while keeping internal and restricted notes separate.
- Review
Measure the shared outcome
Report service commitments, exceptions, changes, and customer decisions from the same record.
Co-managed IT
Shared work, explicit boundariesCo-managed responsibility matrixIllustrative RACI
01Responsible
NamedTeam that performs the agreed work
02Accountable
RequiredOne owner for the final decision
03Consulted
ScopedMSP and customer reviewers in scope
04Informed
DefinedAudience and evidence route defined
Try one useful scenario
A removed permission must deny access
Fictional example: a customer removes a contractor’s write role. The contractor then attempts an action on the former client scope. The expected result is denial with no change. Example access rows: client owner—read its client, approve its policy; MSP technician—read that client, write only approved actions; removed contractor—no access. The signed responsibility agreement identifies the accountable party, customer policy constrains the action, and the role grants execution scope; none alone overrides the others. Repeat the denied test after delegation expiry and removal.
Illustrative evaluation scenario, not a recorded product result.What a useful result must show
Check session revocation, delegation removal, approval expiry and the denied-action record from both parties’ permitted views.
Get the evaluation worksheet →Check the support boundaries
- Contractual responsibility and customer policy
- Tenant/client/resource role boundaries
- SSO and SCIM release support
- Support access and approval expiration
Contracts assign responsibility; policy and roles constrain execution. Do not assume a contract overrides a technical denial or that removing one role revokes every offline token.
Check public evidence and availability →The supporting work.
Role-based customer portal
Expose approved service records, reports, requests, and decisions to customer participants.
Shared approvals
Route customer-impacting technical, commercial, and access decisions to named reviewers.
Delegated operations
Scope actions by tenant, customer, site, module, role, and policy without creating a separate platform instance.
Scope, availability and evaluation details
Questions, answered
Questions for this evaluation.
Can customer staff work directly in Dayrook?
Yes, when invited to a permitted portal or role with access limited to the relevant customer scope.
Can the MSP keep internal notes private?
Target design: Internal and customer-visible information can be separated by record visibility and permission.
Who approves a high-risk change?
The configured policy can require the MSP, the customer, or both, based on action type and agreed responsibility.