Describe one recurring task
Choose a task that happens weekly or daily rather than an entire department. Explain the input, the expected output, the person currently responsible, and the point where it becomes slow, repetitive, or unreliable.
Let’s talk
Tell us what keeps getting copied, chased, forgotten, or done twice.
A real example is more useful than a perfect brief. Share the tools involved, recurring task, and what you would like to change.
Start with a free workflow audit. We focus on one process and work out the next useful step.
The short version
No. A short description of the process and tools is enough. We can arrange an appropriate access method if the work progresses.
Yes. Describe the recurring work, what triggers it, and where it breaks. We assess the fit before suggesting a scope.
No. It starts a conversation. Scope, pricing, permissions, and payment are agreed separately.
Preparing a useful project conversation
You do not need a technical brief to contact Bad Clause. A recent example of the work is more valuable: what started it, which tools were involved, who touched it, where it waited, and what happened next.
Do not send passwords, API keys, customer databases, medical records, financial records, or other sensitive material through the form. A short description is enough to decide whether a deeper conversation is appropriate.
Choose a task that happens weekly or daily rather than an entire department. Explain the input, the expected output, the person currently responsible, and the point where it becomes slow, repetitive, or unreliable.
List the form, inbox, spreadsheet, CRM, calendar, support desk, messaging account, database, or internal tool involved. It is fine if you do not know whether those systems have APIs; that is checked during discovery.
Useful context includes delayed response, incomplete records, duplicated work, avoidable support time, reporting delay, missed follow-up, or reliance on one person. Approximate frequency is more useful than an inflated claim about hours saved.
Tell us which steps follow clear rules and which require experience, approval, or professional judgment. This helps determine whether the first solution is a simple workflow, an AI-assisted step, or a process change without automation.
The workflow repeats, somebody owns it, examples are available, the business can provide legitimate access, and there is a measurable reason to improve it. Strong first projects usually have a visible handoff, a known source of truth, and enough volume for a change to be observed within a practical pilot period.
The goal is simply to add AI, the process changes every time, nobody can approve the rules, the required data cannot be used legitimately, or the expected benefit does not justify implementation and support.