Custom workflow software for small agencies.

A custom build is not always the useful next step. Clearer ownership, fewer approval steps or better configuration of an existing tool may solve the problem.

Custom workflow software becomes worth considering when the work needs rules, permissions or a shared view that the current setup cannot reasonably provide. Start with the bottleneck and what a better outcome would look like, rather than a list of features.

This is a fictional example to explain scope, not a client project or a standard feature package.

1. A team member sends a request with the required details. It enters the Submitted state and appears in the team's work list.
2. An assigned owner checks the request. Missing information moves it to Needs details, with a reason the requester can see.
3. Once the details are complete, the owner sends it for review. Only the nominated reviewer can approve it or return it for changes.
4. The decision and who made it are recorded. The operator view shows requests still waiting for details, ownership or review.

In this example, a requester can see their own requests and the team can see the work it is responsible for. Reopening an approved item needs an agreed permission and reason. Those access and status rules belong in the scope, alongside the screens.

Before building, work through the decisions that shape the tool:

• Who uses it, and what must each person be able to do?
• What information is required, and who owns that data?
• Which states and decisions move an item forward?
• What can each role see, change, approve or reopen?
• What should happen when information is missing or a step fails?
• What does an operator need to see to keep the work moving?

Include existing records, any import or export needs and who can manage access. A first release should have a clear boundary; later workflows and extra reports can be discussed separately.

If the workflow needs information from a CRM or another business tool, the integration work is scoped alongside it. Moving data between systems and deciding what people can do with that data are related parts of the project.

Agree the scope and acceptance checks in writing, then review the working tool. Check a normal request, missing details, an attempted action without permission and a failed step, using agreed test data. A screen looking right does not establish that its rules work.

Handover covers the source, setup notes, access arrangements and how to check or recover the agreed workflow. Ongoing monitoring, maintenance and support are scoped separately.

See how the project process works, or use the development brief to set out the wider project.

Send the process, tools and roles involved, one bottleneck and any relevant deadline. A clear written outline is enough to start. Please do not send passwords, access tokens or confidential customer records.

Opens the contact form on Tally in a new tab.