Client-facing processes — like onboarding, implementation checklists, or approval workflows — are a frequent source of friction. You want predictable outcomes and a great client experience, but handing over internal checklists or juggling spreadsheets and email creates delays, miscommunication, and gaps in responsibility.
Publishing your client-facing processes as runs compartibles y auditables gives you three outcomes at once: clarity for the client, reliable execution for your team, and a verifiable traza de auditoría if something goes wrong. The sections below show how to design, secure, and measure client-facing runs using the features operations teams need.
Why shareable runs improve client-facing processes
Treating a client-facing checklist like an internal document is the fastest way to create confusion. Clients need a clear sense of progress and an action surface; your team needs approvals, controls, and traceability.
A run compartible makes the process itself the single source of truth. A public or controlled link gives external stakeholders a tailored view of progress without making them members of your org. That reduces email threads, eliminates version drift, and keeps sensitive details behind your access controls.
Well-designed shared runs also reduce hand-off friction between teams. Instead of sending an email and asking internal teams to update a separate system, you run the process once and let both parties follow the same live state.
What to expose and how to protect it
Not every SOP should be published. Start with a sharing policy that categorizes processes into three buckets:
Publicly shareable: high-level progress tracking and milestone visibility (e.g., kickoff, milestone completion). These can be exposed via a enlace público del run with optional password protection.
Controlled external access: runs where the client needs to provide input or approve stages (e.g., contract sign-off, acceptance testing). Use password-protected links or guest access with limited permissions.
Internal-only: sensitive operational steps, credentials, or diagnostics (keep these inside your org and surface only necessary checkpoints to clients).
Apply team-based access rules and split a process into a client-facing surface and an internal execution path. That lets you show progress and request approvals without sharing private instructions or credentials.
Governance and legal guardrails
Define data residency and storage policies for attachments and recordings.
Put retention and export policies in place for audit logs.
Include SLAs and escalation paths in the overview card.
Maintain naming conventions, template versioning, and review ownership to prevent outdated instructions from being shared.
Designing the shared run
Structure client-facing runs so clients can act quickly and your team executes reliably.
Key elements to include
Overview card: outcome, expected duration, and primary contact so clients understand the goal and next step within seconds.
Árboles de decisión: collect client choices and route the run dynamically to avoid manual branching.
Approval steps: explicit accept/reject checkpoints create signed timestamps and reduce rework.
Embedded assets: short walkthrough videos or screen recordings for client-side actions to lower support queries.
Attachments and templates: pre-filled forms or CSV templates for data you need from the client.
Smart Labels: store metadata like client ID, contract number, and expected Go‑Live date to filter runs and build reports.
Launch checklist: 8 steps to publish a client-facing run
Identify the outcome and split the process into a client-facing surface and internal execution path.
Create a concise overview card with goals, owner, expected time, and SLAs.
Embed a árbol de decisión for client choices or intake information.
Add approval steps where the client's explicit sign-off is required.
Attach onboarding assets (videos, templates, forms) and mark which attachments clients can download.
Generate a public run link; add a password and expiry if needed.
Wire webhooks to your CRM and set up inbox notifications for the responsible PM.
Monitor completion, collect client feedback, and capture the audit trail.
Security, auditability, and integrations
Sharing a run doesn't mean losing control. Secure client-facing workflows with these features:
Public run links: revocable links that show progress in real time; expire or disable them at any time.
Password protection and expiry windows: require a password or set a time window for link validity.
Role-based visibility: hide internal steps while exposing only high-level progress or specific steps to external viewers.
Approvals and audit trail: record every approval, manual completion, and comment with user, timestamp, and optional evidence. This is invaluable for reconciling disputes or proving compliance.
Webhooks and API integrations: post status changes to your CRM or ticketing system so account and project managers get notified when a client completes a milestone.
If you need guidance on designing processes that meet compliance needs, see our post on SOPs listos para auditoría: Build Compliant, Traceable Processes.
Operate, measure, and iterate
Start small, measure impact, and iterate on what works. Tracking a focused set of metrics shows where to add automation or clearer instructions.
Client onboarding: a step-by-step example
Kickoff (public-facing)
Overview card with expected timeline and main contacts.
Public run link shared with client; password-protected join.
Client completes a árbol de decisión to choose package and preferred kickoff date.
Data collection (client input)
Client uploads brand assets and CSV user list to a secure attachment field.
Form validation blocks progression on missing required fields.
Internal setup (internal-only)
Internal team follows a System (visual workflow) that provisions accounts and configures integrations in parallel.
Automated agent runs scripts (on PRO/BUSINESS plans) and returns logs to the run.
Client review & approval (shared)
Client reviews a demo and clicks an approval step; approval creates a signed timestamp in the audit trail.
If rejected, a decision branch routes the run back to the internal setup step with comments and attachments.
Go‑Live & retrospective (public-facing summary)
Final milestone marked complete; the public run link shows the checklist and selected artifacts.
Export the run's audit log and attach it to the client record in your CRM via API.
Metrics to track
Time to first client action (how long until the client interacts with the run)
Time to completion (end-to-end onboarding time)
Number of approval rejections or rework cycles
Client satisfaction score after go‑live
Support tickets opened during the run
Use these metrics to refine process design, decide where to add automation or video walkthroughs, and identify the steps that most benefit from decision logic or clearer instructions.
A well-designed client-facing run reduces friction, shortens onboarding, and gives you a verifiable record of what happened and when. Start with a single high-value onboarding process, test it with one client, and iterate based on real feedback. If you want help designing the first run, reach out and we’ll walk you through a template or a live demo tailored to your workflow.
