Business Systems
Redesign business systems around the growth bottleneck
Growth can turn a manageable workaround into a daily bottleneck. More jobs create a longer review queue. More employees create uncertainty about ownership. Another location makes the coordinator's memory harder to share.
- Published
- Author
- Demari Miller
- Series
- Cass & York
- Reading time
- 3 min read
Share this article
Growth can turn a manageable workaround into a daily bottleneck. More jobs create a longer review queue. More employees create uncertainty about ownership. Another location makes the coordinator's memory harder to share.
Start by finding where work waits or returns to the same person. Cass & York connects business systems and develops tools for those handoffs, so redesign can address the dependency that is slowing the team.
Find the work that still needs one person's memory
Ask employees to trace a recent delay. Who knew the correct customer? Who could explain the approval? Who had to check two schedules before anyone could assign a crew?
The answer determines the redesign. A volume problem may need a review queue and clearer priorities. A larger team may need assignment rules. Additional locations may need a common transfer process. Replacing the business's systems is not the starting point for any of those decisions.
A transfer between two locations
Consider this fictional business adding a second location. The locations share customers and some crews, but keep separate schedules.
A regional manager proposes moving a job. Today, an email leaves it on two lists, and the local scheduler cannot tell whether the receiving location has accepted responsibility.
The proposed shared queue shows the originating location, proposed destination, crew, due date, and transfer status. The receiving manager accepts or declines. Until acceptance, the original location remains responsible.
Some customers require approval before reassignment. That requirement stays attached to the job when it crosses locations. If the transfer is declined, the job returns to the originating team's queue. If it is canceled after acceptance, both locations need to see the cancellation and the recorded ownership change.
Change the dependencies in order
First, agree what proposed, accepted, declined, and canceled mean, and who can make each decision. Connecting the schedules before settling those rules would spread their differences.
Next, link the customer, service location, and job records the transfer needs. Build the shared queue and let both managers complete a transfer, decline one, and handle a cancellation.
Reminders and escalation can follow once that sequence works.
The group needs common identifiers and transfer rules. Local teams may still keep their crew routines and scheduling practices. A regional manager can review both locations; local staff receive access to the shared jobs required for their role.
What a redesign proposal should resolve
For this example, the proposal should include the current handoff, the revised ownership rules, the connected records, and the screens both managers use. It should also identify who will test the rejected and canceled transfers and how employees will move into the new process.
Before rollout, sample the coordinator's time spent reconstructing transfers and approvals. Count unresolved items and how long they wait. Repeat those measurements over comparable workloads after delivery.
Our Vintel work connected a customer portal, provisioning, integrations, and administrative controls. It provides a separate published example of an operation spanning applications.
The starting point for your company is the delay employees keep working around. Describe the bottleneck growth has created.
Share this article