← Notes from the field
Notes from the field · Podio

Reading 46 automations before quoting a single hour

Before quoting changes to a funding programme's Podio application workflow, we audited the live system and found the verified cause behind every reported problem, which made the offer simple to agree.

A Berlin community funding programme · 16 October 2026

Reported symptoms on the left, verified causes on the right, sorted into defects, changes and new work

A Berlin funding programme for community projects runs its application process in Podio. Organisations apply through web forms, the team reviews each application, asks for corrections where needed and finally sends a PDF for signature. Before the next funding round, the team sent us a list of more than twenty things that were not working the way they should.

The problem

A list like that mixes very different things. Some items are defects, where the system doesn't do what was agreed. Some are changes to agreed behaviour, and some are new wishes. Part of the workflow had been built by us in earlier years, so the difference mattered to both sides: defects are ours to fix, new work is the client's decision.

Guessing from the symptoms would have produced an offer full of ranges and assumptions. So before estimating anything, we looked at the live system.

How we audited it

  • The data layer, read-only. Apps, fields, calculations and web forms were captured as a structure snapshot. We recorded only IDs, counts and lengths, never applicant data.
  • The automations. Podio's workflow automations can't be read through the API, so the team exported all 46 flows across 5 apps and we decoded them step by step.
  • The comment stream as an event log. The automations leave a comment on every application when they send a mail or change a status. Read in order across all 52 applications of the year, those comments showed what had actually happened, and when.

What we found

  • The correction link was too long. Each correction mail carried a link with every previous answer packed into the address. 48 of 52 links were longer than 2,000 characters, and many were far longer. When we cut the long ones at 2,000 characters, they all kept exactly the same first nine fields, which were exactly the fields the team said were the only ones pre-filled. Special characters such as "&" in applicants' texts broke the link a second way.
  • The PDF sometimes arrived without the PDF. The signature mail was sent straight after the PDF was created, without waiting for it. In 4 of 54 sends the mail went out without its attachment, and in 2 no mail followed.
  • Empty contacts. A single condition in the contact automation was evaluated in the wrong order. As a result, an empty second signatory still created a contact named "null, null", and it was still happening in October.
  • Nothing was ever overwritten. Every correction is stored as a new version, but the screens and the PDF only showed the latest one. The history the team asked for already existed. It only had to be shown, which made it a small item instead of a large one.

The result

Every request on the team's list got a verified cause and a clear category: defect, change or new work. Instead of patching the long link, the offer replaces it with a short correction link and a separate correction form, which removes several of the defects at once. Each item in the offer points back to the request it solves. The team accepted it as proposed.

What we took away

An audit before the quote is not overhead. It turns "we think" into "we checked", it tells both sides which work is a defect and which is new, and the client can see exactly what they are paying for.

Working on something similar?

We help teams untangle data and workflows on Podio, Tape and Google Workspace.

Get in touch