Why Does Setting Up a New Client Take So Much Typing?

A partner wins a new client on a Tuesday afternoon. The engagement is signed, the fee is agreed, and everyone is pleased.

Then the actual work of accepting that client begins, and almost none of it is accounting. Somebody creates the organisation record. Somebody links the individual people to it. Somebody applies the right template and adjusts the dates. Somebody builds the folder structure. Somebody creates the internal channel. Somebody writes the welcome email and types the client's name into it, because there is no field that fills it in for you. Somebody tells the team it is live.

In most firms that somebody is not an administrator. It is whoever is available, which during a busy period means a qualified person doing clerical work. New client setup without retyping is entirely achievable, and the reason it has not happened at your firm is not laziness. It is that the tools each hold one piece of the client and none of them hold the whole.

Here is what matters most:

• The administrative cost of accepting a client is paid every single time, and it scales with growth rather than shrinking.
• Karbon's own connector for general-purpose automation moves contacts only. It cannot create the job, so the part that matters still gets done by hand.
• If your proposals run through Ignition, a real path already exists and you should use it. It has limits worth knowing before you rely on it.
• Karbon's paid implementation explicitly excludes customising work items for your specific clients and internal processes. The setup you paid for stops short of your actual process.
• One firm reduced onboarding from a month to five days and added 20% more clients on 4% more staff. That is capacity, not cost saving.

The cost you are paying but not measuring

Most firms treat client setup as overhead too small to bother measuring. That is a reasonable instinct and, at ten new clients a year, a correct one. The arithmetic changes shape as the firm grows.

Consider what actually happens to the economics. The work per client is roughly fixed. It does not become cheaper as you get better at it, because it is not skill-limited, it is keystroke-limited. So the total cost rises in a straight line with the number of clients you win, and it rises fastest in exactly the periods when you are winning the most and have the least spare attention. Growth makes this worse, never better.

There is a second cost that does not appear in anyone's ledger. When acceptance depends on a person remembering a sequence, things get missed. A recurring engagement that was in the contract but never got a template. A stakeholder who was never linked to the organisation, so the wrong person receives the request three months later. A scope item nobody set up, which then gets performed anyway, for free, because by the time it is noticed the relationship matters more than the fee. In our experience these omissions cost considerably more than the administrative hours do, and they are invisible precisely because nobody logs the work they did not charge for.

A practical illustration. Consider a firm that wins forty new clients in a year. If accepting each one consumes half an hour of a qualified person's time across all the systems involved, that is twenty hours of professional capacity spent on data entry. The number itself is unremarkable. What matters is when it lands. It lands in your busiest weeks, taken from the people you can least afford to have typing.

Why connecting it yourself does not hold together

Most firms attempt this before they ask anyone for help, which is sensible. It usually produces something that works and then quietly stops working.

A firm owner described the situation precisely in a practitioner discussion: every new client meant manually setting up the organisation record, the internal channel, the folder and the introduction message. They wired it together with a general-purpose connector tool, and reported that the chain "breaks all the time."

There is a structural reason for that, and it is worth understanding before you spend a weekend on it. Karbon's general-purpose connector handles contacts. It can create and update a person or an organisation, and find one that already exists. That is the whole of it. It cannot create the job, apply the template, or set the dates. So the piece you most wanted automated, the actual work appearing correctly staffed and scheduled, remains manual no matter how carefully you assemble the rest.

The other structural problem is subtler. A connector executes a sequence and assumes each step succeeds. Client acceptance is full of small deviations: the entity name on the engagement differs slightly from the trading name, two people share a surname, the same client already exists from an enquiry two years ago. A sequence with no judgement in it either creates a duplicate or stops, and either way somebody has to work out what happened.

Where a real path already exists

Credit where it is due, because this matters more than a vendor's marketing does.

If your proposals run through Ignition, the integration with Karbon genuinely does what you would hope. Karbon describes it as creating clients and triggering and assigning work automatically from the moment a proposal is accepted. If that is your stack and you are not using it, that is the cheapest improvement available to you and you should stop reading and go turn it on.

Know the boundaries before you build a process on it. Ignition's own documentation is clear that client data flows one way, from Karbon into Ignition rather than the reverse, that budgets cannot be set from the proposal side, that recurring work still has to be managed inside Karbon, and that the integration requires their higher subscription tiers. None of that makes it less useful. It means the integration covers the handshake and leaves the rest of your firm's acceptance process untouched: the folder structure, the internal notification, the personalised letter, the CRM your marketing team actually uses, the checks you perform before accepting anyone at all.

It is also worth knowing what Karbon's own paid implementation does and does not include. Their published statement of work excludes migration or customisation of work items for specific clients and internal processes, and asks for a champion inside your firm for twenty to thirty hours. In other words, the setup fee configures the product. Your process remains your problem.

What changes when it is built properly

The outcome is easier to describe than the mechanism, and the mechanism is not your concern anyway.

An engagement gets signed. Before anybody opens a laptop, the client exists everywhere it needs to exist, spelled the same way in each place, with the individual people linked to the entity correctly. The work that was actually sold appears, with the right template for each service in the contract rather than the template somebody remembered, dated from your firm's rules and assigned by role. The folder structure exists. The welcome letter goes out with the client's actual name in it. The partner is told it is live, and the team sees it in the place they already look.

Two details separate a system from a shortcut, and they are the reason this is worth paying for.

The first is that it expects the mess. When the entity name does not quite match, when a person already exists in your records, when the contract contains a service that has no template yet, it does not create a duplicate and it does not silently stop. It puts that one decision in front of a person with both versions visible, and proceeds once answered.

The second is that scope becomes structural rather than remembered. What was sold determines what gets created. That single change is where the money is, because it ends the category of loss where work gets performed for free because nobody noticed it was never set up.

Tabworks, a fourteen-person firm, describes the difference in their own words. Tabatha Morrison: "Before Karbon, client onboarding took a month and we still weren't getting paid. Now, we're at 5 days from when a person contacts us." That firm added twenty per cent more clients on four per cent more staff. Note what that is: not a cost reduction, a capacity increase. They accepted more work with substantially the same people.

At Loewen Kruse, a larger firm, the same principle applied to their billing and administration routines allowed them to stop hiring a seasonal administrative role. Their director Curtis Braun put the saving at "at least 350 hours," alongside work in progress down forty per cent and receivables up forty per cent.

This is one part of the wider gap around Karbon, and it usually sits alongside the same firm's tax document automation, because both are the same category of problem: your systems each hold a piece of the client, and your staff are the connection between them.

The reasonable objections

Will this disturb what we have already built? It should not, and if it does, it has been built wrong. Karbon remains where your team works and where the jobs live. Nothing about triage, statuses or templates changes for the people using it. What changes is that fewer items require a person to bring them into existence.

Who owns it afterwards? This is the question we would press hardest if we were you. The most common failure in firm automation is not technical: a capable person builds something that works, and then leaves. One practitioner summarised it well when discussing workflow ownership, observing that if the answer to who maintains it is everyone, the answer is nobody. Establish before anything is built who is responsible, who reviews it, and what happens during that person's holiday.

What about the risk of it going wrong at the worst moment? Be sceptical of anyone who claims none, ourselves included. What is reasonable to expect is a considered failure. If a step cannot complete, the acceptance waits and a person is told, which returns you to the manual process you follow today. Nothing is deleted, and nothing is sent to a client that a person has not approved.

FAQ

Our firm is small. Is this worth it below a certain size?

Probably not, and any vendor who says otherwise is selling rather than advising. If you accept a handful of clients a year, the honest answer is that a well-written checklist and a named owner will serve you better than anything built. The economics turn when acceptance volume is high enough that the work reliably collides with your busiest weeks, or when the omissions have started costing you fees. If you cannot recall an instance of unbilled work caused by a setup step being missed, you are not there yet.

We already pay for Karbon and for our proposal tool. Why another cost?

Because they are priced against different things. Practice management is priced per person per month regardless of what that person does, which is why paying a full seat for someone who works one day a week irritates so many firm owners. What you build alongside it is priced against a specific job you currently pay qualified people to perform manually. The correct test is not whether it adds to your software expenditure. It is whether the work it removes costs you more than it does.

Can this include our client checks before we accept an engagement?

Yes, and this is frequently the more valuable half. The same sequence that creates records can require that verification steps are complete before the work is created at all, so an engagement cannot quietly begin before the checks are done. Firms with regulatory obligations usually find that the audit trail this produces is worth more to them than the hours saved, because it turns a policy that depends on individual diligence into one the process enforces.

How long does implementation take?

Less time than the implementation of the practice management system you already went through, because the scope is narrower and the decisions are mostly yours rather than the software's. The genuine constraint is not build time. It is how quickly your firm can decide what your acceptance process actually is, because a good deal of it currently lives in the heads of two or three long-serving people and has never been written down. Firms who move quickly are the ones who accept that the first version will be imperfect and correct it after a month of real use.