AI and process automation — delivery and development

What situation is it for?: Manual re-typing, going back for data, excessive corrections or an existing AI that needs development.
What do you get?: The result of the agreed delivery stage: an analysis, a pilot result or an implemented solution — with its basis, limitations and the outcome of the check.
How will you use it?: For a decision on funding and the scope of the change, or for the day-to-day running of the process.
What does the result depend on?: On the data, the process owner, the use of the result, control and the capacity of the subsequent stages of work.

We deliver projects from the analysis of value and data, through model selection and integrations, to implementation, monitoring and maintenance. You can start at the stage that matches your situation. At implementation we agree the documentation and the rules of operation; corrections and further maintenance have a defined scope.

Responsibility and acceptance

Before the work we write down the goal, scope, materials, result and delivery conditions. The lead person on the HumGu side is responsible for checking before handover. On the client side we identify the person who confirms the requirements and accepts the result.

We set the acceptance conditions before the trial: e.g. respecting permissions, no unauthorised commitments and flagging significant conflicts in the agreed cases. Only among the results that meet these conditions do we compare time, cost and corrections. A lower price or a better average does not compensate for an error that blocks acceptance. We also keep the work and spending of failed trials in the calculation.

If the criteria are not met, we describe the discrepancy and agree a correction with a re-check within the scope of the order, a change of approach, or the end of the stage. Such a result does not go into the agreed use. We assess new requirements together with their impact on cost, deadline and acceptance.

When to change the scope or postpone delivery?

When the data or the conditions for using it do not allow the task to be performed, the quality does not meet the criteria, or control consumes the benefit. The right step may be to tidy up the rules or to use the current tool.

See the sample business calculation

See an example

Conflicting requirements in the inquiry and the attachment → both versions with sources → questions for the client and a draft for the sales representative's approval.
Illustration on fictional data; without integrations or measurement of return on investment (ROI).

See the inquiry-handling example

Start from your stage

You have a defined task: let's agree the scope of delivery or a pilot.
You have a prototype: let's discuss testing, integrations and the conditions for implementation.
You have a working AI: let's talk about optimisation, maintenance or further development.

Describe what you want to automate or improve

More detail

What do we agree before delivery?

The process and the expected change

Who performs the task, what result they should get and what makes the current work difficult. We define the boundaries of automation and the human role.

Economics and criteria

We set the reference point, the acceptance requirements and the measures of improvement. We count people's work including control, corrections and exceptions, as well as delivery, data, models, integrations and maintenance. Working time, lead time, throughput and cost per completed case are assessed separately. ROI depends on the goal and on a confirmed mechanism of benefit.

Choosing the way to solve IT

We compare the current process, tidying up the rules and using the tools you already have, rule-based automation and AI. These methods can be combined. Stable data and conditions may favour rules; varied documents favour a trial with AI. The choice follows from quality, the full cost of operation, the scale of the problem and the integration conditions.

How do we deliver the technical part?

Data and context

We check the origin, quality, currency and terms of use of the sources. We prepare the data and context, taking the recipient's permissions into account. More documents require an assessment of their usefulness and compliance; volume alone does not confirm quality.

Selecting, testing and optimising models

We compare models on cases relevant to the process. We optimise the instructions, context and flow of use. We assess quality, people's working time, the solution's running time and the cost of a result that meets the criteria: a cheaper call may require more expensive control and corrections. A shorter answer must still be complete. Critical quality requirements remain a condition of acceptance.

Integrations and exceptions

We connect the solution to your systems and define what happens with gaps, contradictions or a result that requires checking. When extending automation, we reassess the data, exceptions and permissions. Before an action that could create a commitment or a change in a system, we establish appropriate control.

Governance — governance rules

We agree responsibility, access, rules for data use, automatic actions and human approvals.

Implementation, monitoring and maintenance

We implement and maintain the solution within the agreed scope. We define the monitoring of quality, costs and operation, and the responsibility for changes. After a change to the data, model or instructions, we re-check the relevant cases against the criteria.

Sample result: scope and criteria of the first trial

Illustration on a fictional inquiry-analysis task:

Input: the message, the attachment and the agreed rules.
Result: requirements with sources, conflicts, questions and a draft for approval.
Boundaries: no independent approval of a discount, price or deadline; in this sample, no sending and no integration with e-mail/CRM.
Check: consistent data, a contradictory attachment, missing decisive information, a threshold exceeded and an attempt to change the rules in the document.

In this illustration an unauthorised commitment blocks acceptance of the result. The absence of errors on a small sample does not prove reliability. We set the format of the trial to suit the task.

From trial to lasting value

Preparation: the task, sources, reference point, acceptance requirements and effort.
Trial: quality and the full work on the agreed cases, including corrections and exceptions.
Putting into operation: integrations, access, responsibility and preparing users.
Reaching the effect: checking the use of the solution and its impact on the work of the whole process.
Maintenance: monitoring and reassessment after changes to data, models or rules.

These are areas to plan according to the order, not a mandatory sequence of paid services. A correct trial result justifies further assessment, but does not prove a lasting benefit. Less re-analysis may free up work; a shorter wait for the client and higher throughput also require efficient subsequent stages. Saving cash requires a specific avoided expense.