Delivery method

"Managed" is the whole claim. So here is the mechanism.

Every provider says they handle it for you. The difference is whether the handling has a shape you can inspect before you commit. This is the method Gridex is designing for both service lines, including the intended artifacts, client decisions, and failure path. Managed Workflow is in validation; Managed Voice is still being built and has no customer deployment.

Method rule: acceptance before launch Method rule: authorisation before connection Managed model: no administration dashboard

Nine stages, and three of them are gates.

Stages 3, 5 and 6 cannot be passed by Gridex alone. That is what makes them gates rather than steps.

  1. 01

    1 — Discover

    The method starts with a conversation and, where it exists, whatever you already have written down: an SOP, a script, a spreadsheet somebody maintains, or a page on your site. Gridex would extract the facts and identify the business decisions that still need an owner before build work begins.

  2. 02

    2 — Draft the operating brief

    Gridex would draft the operating model: why people call or what the workflow does, what each case needs, what actions are permitted, what must never happen, who gets escalated to, and what the output looks like. You would not maintain prompts or implementation details, but you remain responsible for correcting and keeping source facts, policy decisions, and human contacts current.

  3. 03

    3 — You approve the decisions

    Only the decisions, not the implementation. What counts as urgent, who gets woken, what gets declined, what may never be said, where the result goes. These are business judgements Gridex cannot safely invent, and the approval is recorded against a version so "we never agreed to that" is a checkable statement rather than an argument.

  4. 04

    4 — Build and test

    The method calls for Gridex to build the operation and run it against an agreed acceptance set: the normal case, the urgent one, the ambiguous one, the one that fails, and the one that asks for something unsupported. Each scenario needs a defined expected outcome, and the client reviews the results before authorising a live connection.

  5. 05

    5 — Connect

    When an engagement needs a live connection, it may involve phone forwarding, a calendar, a delivery destination, or another system the workflow touches. The exact method depends on what that vendor and account support. Access, permissions, revocation, and the fallback need to be agreed and tested before launch.

  6. 06

    6 — Launch on your authorisation

    Under this method, nothing would point at real callers or real records until the client authorises it and the agreed acceptance set passes. A production connection is an explicit gate, not an assumption.

  7. 07

    7 — Operate and sample

    Once an engagement is operating, the intended practice is to sample real calls or runs against the approved brief, record exceptions, and update rules through change control. The reporting cadence and incident responsibilities must be agreed for the engagement rather than implied by this page.

  8. 08

    8 — Change control

    The intended change path is draft, approval, testing, versioning, then release. Emergency authority and rollback rules still need to be agreed for each engagement; this page does not grant Gridex unilateral authority to change a live operation.

  9. 09

    9 — Offboard cleanly

    Offboarding terms should be agreed before launch: which client-owned artifacts are returned, how access is revoked, how forwarding or other connections are changed, and which data is deleted or retained and when. Those terms belong in the engagement, not in an unstated site-wide guarantee.

Six working artifacts in the method.

Exact ownership, handoff, access, and retention terms are agreed for each engagement rather than promised by this page.

The decision list
What has to be decided that nobody has decided yet. Produced early enough to shape scope, rules, and acceptance tests.
The operating brief
The versioned description of what runs: triggers, questions, actions, policies, escalations and outputs. Written by Gridex, approved by you.
The acceptance set
Named scenarios with expected outcomes, including the failures. This is what "tested" means concretely, rather than as an adjective.
The connection record
What is connected to what, with which permissions, and how to revoke it. Written so somebody who was not in the room can act on it.
The change log
Every version, what changed, who approved it, and what was re-tested as a result.
The exception queue
What the operation could not handle, what happened instead, and whether the rule got fixed or the case got accepted.

The line that does not move.

Gridex never decides
Whether to accept a matter, a client or a job · Legal, medical or financial advice of any kind · Final conflict clearance · Anything that would form an attorney-client relationship · Any commitment on price, scope or timing the client has not pre-approved · Any approval the client's professional judgment or signature governs
Gridex operating responsibility
The managed model is designed for Gridex to handle prompts, call flows, integrations, monitoring, and upkeep. The client still provides approvals, current source facts, scoped access, and named human contacts.
Accountability model
The method calls for one Gridex owner accountable for the operation and one client owner authorised to approve changes. The named people and backup path are agreed per engagement.
Disclosure standard
The intended practice is to report material failures, their impact, and the corrective action under the incident terms agreed for the engagement.

Giving you a console would be the easy way out.

It is genuinely simpler to build a settings screen and let the customer configure their own hours, their own escalation rules, their own question set. It also quietly converts a managed service back into software with a support contract, and hands the ongoing work to whoever at your business has the least time for it.

So the managed model is designed for Gridex to hold the configuration and operating burden. Your team would still supply and maintain source facts, approve business decisions, control system access, and name the people who receive escalations. The approval mechanism and exact responsibility split would be agreed during setup. If you want to own and administer the system yourself, a managed service is probably the wrong model.

The questions buyers actually ask.

How long does all this take?

Gridex has not run enough launches to quote a reliable range. No site-wide duration is promised; the schedule, acceptance set, and launch gates need to be agreed per engagement once the scope and dependencies are understood.

What if I already have documentation?

Send it in whatever format it is in — a document, a spreadsheet, screenshots, a recording of somebody explaining it. Gridex organises it. Being asked to restructure your own material into somebody else's template before they will start is a bad sign about who is doing the work.

Do I get access to a system?

The managed model does not require a customer dashboard for prompt or call-flow administration. A client would still control source-system access and provide approvals, current business facts, and human escalation contacts. Any approval interface or account requirement would be disclosed for the specific engagement.

What happens when something goes wrong?

The intended method is to report material failures with what happened, what was affected, and the corrective action. The exact notification, response, and retention terms need to be agreed for the engagement; this page does not substitute for them.

Can I see the operating brief?

The method calls for the client to review and approve the operating brief. Which test materials, implementation details, and records are shared or retained should be stated in the engagement rather than assumed from this page.

Has this method been run end to end yet?

Managed Voice is in build as of August 2026 and has no published customer deployment. Managed Workflow is in validation. This page describes the method both lines are intended to follow; it is not evidence that every stage has already been run for both lines.

Ask about the part of this you do not believe. That question is more useful than a demo.

Ask a question