Case study
This case is our own operations: tasks, emails, calls and night checks run without anyone writing notes.
Since 1998 we have looked after websites, portals and interfaces for mid-sized companies and corporations, today dozens of client systems at the same time. Tasks came in by email, by phone and out of work sessions, and we bill by time spent. Every task had to be recorded, named and assigned to the right client, and too often that happened in the evening, from memory.
Entry 1
Starting point
A service provider like us depends on two things that get in each other's way: work on client systems and proof of that work. A client calls because a form is not coming through. An email reports that an interface to Salesforce is stuck. A work session produces three follow-up tasks for two other clients. In the end, all of this has to appear on an invoice, clearly worded and correctly assigned.
Proof came from timesheets. They were written after the fact, in the evening or on Friday, and had gaps to match. At month end, billing was pieced together from timesheets, emails and the calendar. Clients asked what a line item meant, because it had been named briefly and after the event.
Then there was the support work itself. Whether a website was reachable, whether error pages appeared, whether interfaces were running and backups complete was checked when there was a reason to. Too often we heard from the client that something was stuck. When language models became usable in 2023, we used them here first, for ourselves, before recommending them to clients.
Entry 2
Figures before
| Client systems supported | dozens |
|---|---|
| Channels for incoming tasks | email, phone, work sessions |
| Time recording | timesheets, filled in by hand after the fact |
| Billing at month end | pieced together from timesheets, emails and calendar |
| Questions about invoices | regular, because of terse line items |
| Checks of client systems | when there was a reason, by spot check |
| Who knew about errors first | often the client |
We do not publish hour figures for ourselves. The situation speaks for itself.
Entry 3
The path
Built alongside day-to-day business, one workflow after another. The week figures are rounded.
- Weeks 1 to 2
Taking stock
Where does the work actually happen, where is information lost, what causes the most frustration. The decision was to start with task recording, because a forgotten task means a missing invoice line.
- Weeks 3 to 6
Tasks recorded automatically
Every work session is recorded as a task, named, estimated and prepared for billing. For four weeks, the timesheet continued in parallel so that we could compare what the workflow finds and what it misses.
- Weeks 7 to 10
Email read and prepared
Incoming emails are read, assigned to the client and the case, and presented with a draft reply. Nothing is sent without approval from a person.
- Weeks 11 to 12
Calls turned into cases
Calls are recorded and turned into cases, with client, request and next step. Whatever was promised on the phone then sits in the same task list as everything else.
- Weeks 13 to 16
Nightly checks
Every night, workflows check the client systems: reachability, error pages, interfaces, backups. Only deviations are reported, in the morning, with where they occurred.
- Ongoing
More workflows
Text projects for clients run in weekly rollouts with checks and rollback. Every new workflow starts in parallel operation. The tools are connected through their own interfaces, not through notes.
Entry 4
Result
Today, dozens of workflows work for us every day. There are no timesheets any more. At month end, billing is ready and sorted, per client, with line items the client understands without asking. A person reviews and approves it. Emails no longer wait for someone to assign them; they are ready with a draft. As a rule, we know about deviations in client systems before the client notices them.
We bought none of these tools. They are built for our workflow, just as we build them for clients.
| Area | before | after |
|---|---|---|
| Time recording | timesheets, after the fact | automatically from the work session |
| Billing | pieced together at month end | ready and sorted at month end, approved by a person |
| Invoice line items | terse, named after the event | in the client's language, from the task |
| read and assigned by hand | assigned, with a draft reply | |
| Calls | sticky notes | a case with the next step |
| Checks of client systems | when there was a reason | every night, only deviations reported |
Operating mode: the tools run on our own infrastructure in Germany. Client data stays in the client systems. AI components run via cloud models under contract, and the data trains no third-party models.
Entry 5
What went wrong
- Task titles only a technician understood. The automatic naming wrote down what had happened technically: "Adjusted cron hook for sitemap regeneration". On an invoice, that tells the client nothing. The naming got a rule of its own: "invoice titles in the client's language". The title says what the client gets out of it, for example "Sitemap updates itself automatically again". The lesson: every output a third party reads needs its own language rule.
- An alert that came every night. At one hosting provider, a nightly check reported the same error every night, a known condition we could not change. After a week, nobody read the message any more, and a real deviation would have been lost in it. We switched the check to changes instead of states: it reports what has changed since last night. The lesson: an alert that comes every day is not an alert.
Entry 6
What we would do differently today
For every workflow, we would first ask who reads the output. The task titles were written for us and ended up with the client. Since then, every workflow states who it writes for, and the language rule is part of the first version, not the third.
We would design checks for changes from the start. A condition is reported once and then tracked as known until it changes.
And we would write the rules down earlier. For a long time, they lived in people's heads rather than in the configuration of the workflows. Today, every rule is a line that can be read, changed and checked. We bring this experience to client projects: we made the mistakes ourselves, not at the client's expense.
Entry 7
Key facts
| Industry | Service provider, support for websites, portals and interfaces since 1998 |
|---|---|
| Employees | a team of specialists |
| Systems | Email, telephony, calendar, our own tools for tasks and billing; client systems with WordPress, Salesforce, NetSuite and others |
| Services | Tools that fit you, Texts and content at scale, system integration |
| Operating mode | Tools on our own infrastructure in Germany; client data stays in the client systems; AI components via cloud models under contract with no use of the data for training |
| Duration | built step by step since 2023, continuously extended |
Read more
Further reading
Handover
The first step is a 30-minute call.
You tell us about the workflow that costs you the most time. We tell you honestly whether AI pays off there and what the next step would be. Whether a workflow analysis follows is up to you.