Our approach

A clear problem.
A considered process.

Move from a recurring frustration to something useful, with clear scope, visible progress, and a handover people can understand.

Read the pilot planning guide

From question to handover

Know what comes next.
Know what good looks like.

The details vary with the project. These are the decisions and outputs that give the work structure.

  1. Understand the work.

    Walk through one recurring workflow with the people who know it. Identify the tools, handoffs, exceptions, and effort involved. Establish a baseline before defining an improvement.

    Working toward: A shared problem statement and a useful starting measure.

    What you bring: A workflow owner, a walkthrough, and suitable examples.

  2. Define a focused pilot.

    Agree on what is included, what is excluded, and how the result will be reviewed. Clarify access, dependencies, responsibilities, and any decisions that require human approval.

    Working toward: A written scope with acceptance criteria and review points.

    What you bring: A decision-maker, operational constraints, and an agreed budget.

  3. Build, review, and refine.

    Use short demonstrations and agreed test examples to make progress visible. Review ordinary cases and exceptions. If a new requirement changes the scope, agree on the change before adding it.

    Working toward: A working solution assessed against the agreed criteria.

    What you bring: Timely feedback and someone available to review the work.

  4. Hand over with clarity.

    Explain how the system operates, document routine tasks, and identify who owns access and maintenance. Include known limitations and a practical response when something goes wrong.

    Working toward: A documented handover and clear operational ownership.

    What you bring: The people who will use, own, or support the system.

  5. Agree on care where it helps.

    Some systems need ongoing attention. Where support is useful, define the work, included hours, response expectations, and exclusions in a separate agreement.

    Working toward: A bounded support arrangement, when one is needed.

    What you bring: A view of likely changes and the level of support required.

Working together

Make progress easy to review.

Calls, written decisions, and demonstrations each serve a purpose. Agree on a practical rhythm around the people responsible for the work.

Keep decisions in one place

Use a shared record for scope, open questions, review notes, and the next decision. Choose the communication tools and meeting format together. Set availability and feedback expectations in the project plan so that a missed decision does not become an invisible dependency.

Review the work people will use

A demonstration should follow the actual task: where information starts, what happens next, and what someone does when an exception appears. Use agreed examples and record what passes, what needs adjustment, and what belongs in a later phase.

Prepare for discovery

A recent example is a strong starting point.

Walk through one ordinary task and one that went wrong. Identify the people, handoffs, and decisions involved. You can describe them in the brief without sending private records or granting system access.

Prepare the first conversationFind the workflow to discuss

Before work begins

Put the important choices in writing.

A proposal should make the project easy to understand and review. Before implementation, agree on:

  • The workflow, people, and systems in scope.
  • The examples and criteria used to accept the result.
  • Required access, data handling, and review responsibilities.
  • Timing, fees, dependencies, and how changes are approved.
  • Handover materials and any ongoing support boundaries.

Do not include passwords or confidential customer records in an initial project brief. Data access belongs in a deliberate, separately agreed part of the work.

Scope and investment

Understand the cost of building and running it.

The number of systems involved is only part of an estimate. Data quality, exception handling, permissions, testing, and the amount of handover required also affect the work. Discovery helps expose these factors before a pilot is quoted.

  • Separate the agreed project fee from recurring software, hosting, usage, and support costs.
  • Define payment milestones and the review needed at each stage in the proposal.
  • Explain a requested change, its cost and timing, and obtain agreement before expanding the work.

For example, a pilot might prepare a draft weekly report from one source for a person to review. Adding another source or sending reports automatically changes that scope. Treat each as a separate decision with its own access, testing, and operating requirements.

Beyond the first release

Plan for the people who will run it.

Handover is a working conversation about everyday operation. The proposal defines which materials and walkthroughs are included; this checklist helps identify what your team will need.

Know how to operate it

  • The ordinary task, from its starting point to its result.
  • The checks that show whether the workflow completed.
  • Known limitations and the person who reviews exceptions.
  • Steps to pause, retry, or seek help when something changes.

Know who is responsible

  • The owner of accounts, access, and provider billing.
  • The location of agreed documentation and source materials.
  • The person who approves changes to the business rules.
  • Any maintenance arrangement, its limits, and review dates.

Consider the full commitment

Build costs and operating costs belong in the same conversation.

Include the subscriptions, review effort, and maintenance the result may need. When budget is constrained, use that context to prioritize a smaller first release with a clear purpose.

Explore the pricing approachShare your project constraints

Make room for what matters

A better project starts
with a clearer brief.

Describe the workflow, the friction, and what a useful first improvement would look like.

Outline your first project