Peak Code Consulting

Automate a business process

Pick one process. Two weeks after the kickoff workshop it runs without anyone touching it.

You name the process in the first hour of the workshop. We map it, count what it costs to run today, and build the automation. Two weeks from the kickoff workshop, guaranteed to cost at least 75% less to run.

  • Two weeks from the kickoff workshop. Not from the first email. Ten working days, counted from the workshop day itself.

  • The baseline is counted first. What the process costs to run today goes into the contract before anything is built.

  • The 75% Guarantee. Late, off the requirements, or short of a 75% cut, and you get your money back.

The process everyone works around

Somebody opens two systems every morning and moves numbers from one into the other. Somebody chases the same suppliers every Thursday. The weekly report is assembled by hand. None of it is hard. All of it is somebody’s week.

It survives because it works. The order goes out, the invoice gets raised, and whoever does it stopped complaining years ago. The cost shows only when volume grows, and the answer offered then is another pair of hands.

Fixing it properly comes back as a project. Months, a discovery phase, and a fee to justify against a task that takes four hours a week. So it gets deferred again.

Why two weeks is a real number

Nothing here is written from scratch. Connecting, retrying, logging and scheduling already exist on established automation platforms. What gets built is the part specific to this process, and that part is small.

The mapping is compressed into one session instead of six weeks of meetings. Two to three hours, with the people who actually run the process.

AI takes the judgement steps: reading a document that changes shape every month, classifying an email, pulling a figure out of a PDF. Everything else stays deterministic, because a process the business depends on should fail loudly rather than creatively.

What you get

One process, one fixed scope, agreed in writing before the build starts.

  • A process mapping workshop, two to three hours. We walk the process with the people who run it, and leave with the map, the requirements and today’s cost.

  • The build sprint. The automation itself, built against the signed requirements and tested on your real cases rather than a demo dataset.

  • A handover session, one to two hours. How it runs, what a failure looks like, and how the team finds out. Recorded once, for whoever comes next.

  • Platform access in your name. The accounts belong to you. Maintenance can go to somebody else without asking us for anything.

  • Written documentation. What it does, what it connects to, and what to do when a step breaks. Written so another supplier could take over.

What the two weeks look like

  1. Day 0

    The mapping workshop. Two to three hours. The process is mapped, the requirements written down, the cost counted. The clock starts here.

  2. Days 1 to 7

    The build. A working version is shown partway through, so the handover holds no surprises.

  3. Days 8 and 9

    Testing against your real cases, and the corrections that come out of it.

  4. Day 10

    Handover. The team runs it while we watch, and we answer the questions that only appear in real use.

Ten working days, two calendar weeks, counted from the workshop and not from the first email. If access we need is outstanding, the clock pauses until it is granted.

The 75% Guarantee

Handed over within two weeks of the kickoff workshop, matching the written requirements, and at least 75% cheaper to run than the baseline counted in that workshop. Miss one of the three and you get your money back.

  • A promise with a refund behind it. The 75% is a threshold we agree to be held to before anything is built. It is not a figure achieved for anyone else.

  • The baseline is counted before the build. In the workshop we count the hours the process takes and the errors it causes, at the rate you give us. The number goes into the contract.

  • Before and after are measured the same way. Time spent on the process plus the rework its errors cause. Same method, same rate, both times.

  • Defects are fixed at no cost. Nobody can guarantee software with no defects. Anything that fails to match the signed requirements is corrected at no charge.

  • How you claim. The after figure is taken thirty days after handover. Email info@peakcodeconsulting.ch within thirty days of that measurement, with the numbers agreed in the workshop. If the handover is late or misses the written requirements, the thirty days run from handover instead. An answer comes within ten working days.

These terms go into the contract before the build starts, in these words. One exception, named in the timeline above: if access we need is outstanding, the two weeks pause until it is granted.

Who this is for

This is for you if

  • One process is costing your people hours every week.
  • Somebody can describe how it runs, even if it is messy.
  • You can spare three hours for the workshop and grant the access.
  • You would rather remove the work than hire someone to absorb it.

This is not for you if

  • Nobody can say what the process does today. Messy is workable, undefined is not.
  • You want every process reviewed at once. This is one, on purpose.
  • The process depends on a system nobody will grant access to.
  • You want the automation without the written baseline. The guarantee is settled against it.

The questions we get asked

What does it cost?
It is quoted in writing after the first call, against the process you bring. There is no list price, because scoping a process without seeing it is guessing. The fee is fixed before the build starts.
Which process should we pick?
The one somebody in your company would call stupid. Bring three candidates to the call and we say which pays back fastest. That part costs nothing.
Do we have to replace our existing software?
No. Most of this sits between tools you already pay for and makes them pass information to each other.
What happens when it breaks?
Automations break when the systems around them change. The handover covers what failure looks like and how you are alerted. Ongoing maintenance is a separate care plan and is not obligatory.
What happens after the two weeks?
Either the next process, a care plan for the platform, or nothing. The accounts are in your name and the documentation is written for somebody else to pick up.

Tell us which process to look at

The first call is free.

Describe the process in a sentence or two. We come back within 48 hours on whether it fits two weeks, what the workshop would need to cover, and which parts we would leave alone.

If the honest answer is that automating it is the wrong move for what you are describing, the reply says so.

Or email info@peakcodeconsulting.ch