Kewl Consulting — Insights

CRM adoption is a design problem before it is a training problem

2026-09-02T12:00:00-07:00

The call comes about four months after go-live. The system is in, the data is in, the training was delivered, and the sales team is not using it. Could we run another session.

We can, and sometimes we do. But in most of these cases the second training session teaches people how to use a system that was designed to make someone else’s job easier, and no amount of instruction changes what a system is for. Adoption is decided at design time, and here is what deciding it well looks like.

Design for the person’s Tuesday, not for the dashboard

Most CRM configurations are built from the report backward: the leadership team wants a pipeline view, so the fields that feed it become required, and the person entering an opportunity fills eleven fields to record a phone call. The dashboard is excellent. The person stops recording phone calls.

The design has to start from the other end. What does a salesperson, a service agent or a project manager do on an ordinary Tuesday, and what would make that hour shorter? If logging the call takes longer than the call, the system has to change, not the person. Fields that exist only for the report are pushed to later stages, defaulted or derived. The dashboard is still excellent — it is fed by people who are using the system because it helps them.

Give the work an owner who is not IT

Every process that lives in the CRM has a process owner: a person on the business side who decides how the process works, signs off changes to it, and is the one who says “yes, this is how we do it now” to their own team. When the process owner is IT, or the consultant, the team experiences the system as something done to them. When the process owner is their own manager, it is how the team works.

This is why our discovery calls include the process owners and not only the sponsor. A system designed with the people who will run it is a system they have already agreed to use.

Remove the parallel system on purpose

If the spreadsheet is still available, the spreadsheet wins. It is familiar, it is fast and nobody is watching. Adoption needs the old path closed: the report that used to come from the spreadsheet now comes only from the CRM, the weekly meeting runs from the CRM screen, and the data that used to live in email lives in the record. This is a management decision, not a technical one, and the projects where it was not made are the projects that called about training.

Train on the person’s own work, in the first week

Training still matters — but as the last step, and in a specific form. Not a tour of the system: a session where each person brings their real accounts, real open deals and real service cases and enters them, with someone beside them who can change a field label or a default on the spot when it turns out to be wrong.

The first week of use is when the small frictions appear, and the difference between a system that is adopted and one that is abandoned is whether those frictions are fixed in that week or filed for a later phase.

Measure use, not logins

Login counts will be fine. Everybody logs in. The measure that matters is whether the work is happening in the system: are opportunities being updated within a day of a change, are cases being closed with the resolution recorded, is the pipeline report the one the sales director actually reads. These are questions about specific fields and specific reports, agreed at design time and checked in the first ninety days.

When one of them is not being met, the first assumption is that the design is wrong somewhere, and the fix is usually a field, a default or a stage — not a session.

What the second training session should be

A review, with the process owners, of the ninety-day measures: which parts of the system are carrying the work, which are being worked around, and what changes. Sometimes a training need does come out of that review. More often what comes out is a list of fields to remove.

That is adoption as we understand it. Not persuading people to use the system they were given, but giving them the system they would have asked for. It is also most of what our support work is.

When should AI live inside the CRM versus outside it?

2026-08-19T12:00:00-07:00

This is the architecture decision that determines what an agent deployment costs to run for the next five years. It’s usually made by accident — by whichever demo was most convincing, or by whichever team happened to build first.

It deserves to be made deliberately, and it’s a two-week decision rather than a two-year one.

Start inside, and make outside earn it

If the work is CRM work — triage, routing, summarization, next-best-action, quote preparation, anything whose subject is a record in the platform — it belongs in the platform.

The reason isn’t preference. Agent lifecycle, policy enforcement, approvals, execution monitoring and the audit trail are all native there. Build the same thing outside and you’re re-implementing all five, badly, and then maintaining them. Inside, you get one place to look when something goes wrong, one permission model rather than two, and no second system to license.

The test: if you can describe the agent’s job without naming a system other than the CRM, it goes inside.

What outside is genuinely for

Some work needs a model, a data source, a document pipeline or an integration the platform can’t reach. Then you build it outside, on a proper orchestration runtime, and integrate it back over a documented interface — grounding it against your live records so its output still resolves to data you can open.

Typical cases: heavy document extraction, a specialist model your sector requires, an agent that has to work across three systems of which the CRM is one, or work whose volume would be uneconomic inside a metered platform.

The expensive version of this mistake

It isn’t choosing wrong once. It’s choosing both, for the same work, at different times — an agent configured in the platform for one team and a custom-built equivalent for another, because two projects made the call independently.

Now you maintain two implementations of the same logic, two audit trails a reviewer has to reconcile, and two places where a rule change has to land. A rule changes, one of the two gets updated, and for a while the same company gives the same customer different answers. This is the state most organizations we’re called into as a rescue are actually in, and unwinding it costs more than either option would have cost done once.

So the split has to be a written decision that applies across the program, not a per-project instinct.

Where it runs is not which model it calls

Worth separating, because buyers conflate them constantly and it produces a bad conversation with procurement.

Where the agent runs is the runtime — the platform’s own studio, or an external orchestration service. It’s where the approval gates, the grounding and the audit trail live, and it’s the decision this article is about.

Which model it calls is separate and should stay open. Frontier models from more than one vendor, or one you host yourself where residency or a fine-tune requires it. The workflow logic sits in the runtime rather than in the model, so swapping the model is a configuration change rather than a rebuild.

A firm that welds you to one vendor’s model has handed you their negotiating position along with the invoice (how we keep the model swappable). A firm that’s opinionated about the runtime is telling you where its support experience is. That’s a different and more useful kind of opinion.

One caveat about versions

Native agent management is recent. If you’re on an earlier platform version, “inside” may mean planning an upgrade first — a real cost, and one that belongs in the decision rather than being discovered afterwards.

How we actually make the call

Four questions, in order:

Can the platform’s native agent tooling do this? If yes, stop. It goes inside.
What specifically can’t it reach — a data source, a model, a document type, a system? Name it. “Flexibility” isn’t an answer.
What’s the running cost of each option, including metered AI actions inside versus infrastructure and maintenance outside?
Who maintains it in year three? An external agent needs an owner who understands both ends. If that person doesn’t exist, inside is the safer answer even where outside is technically better.

Answer those in Discovery, in writing, before anyone builds. Getting this split wrong is what turns an agent program into a maintenance problem. Two weeks up front is what it costs to settle it before the build instead of after.

We settle the split in Discovery, before anyone builds either side; it is the first line of an automation plan with us.

What does “unlimited CRM” mean?

2026-07-15T12:00:00-07:00

“Unlimited” is a word that deserves checking. So here’s what it covers, and what it doesn’t.

What you genuinely stop counting

Under Creatio’s per-organization licence model, Creatio Unlimited, the platform is priced for the company rather than per seat: unlimited users, applications, workflows, custom objects and API calls, with access to the full platform.

The practical effect isn’t the invoice. It’s that the conversation about who “deserves” a licence stops happening — and that conversation is usually the thing quietly limiting adoption. Warehouse staff who should be updating records but were never licensed. The finance team reading reports off screenshots because nobody wanted to add five seats. The partner who can’t be given access because access has a per-head price.

Every one of those is an adoption problem that looked like a budget problem. Removing the seat count removes it.

What you start counting instead

AI actions. Agent interactions are metered separately. This is the important one, because it changes which number you have to forecast: not how many people you employ, but how many times a month your automated workflows will run. Seat counts were easy to predict — you knew your headcount. Agent volume is harder, and it’s the single most useful thing to model properly before you sign anything.

Get it wrong and a project that looked funded stops being funded in month seven — a worse outcome than having scoped it smaller.

Per-user plans still exist. Unlimited is one option among several. The per-user tiers haven’t gone away, and for a smaller team they’re frequently cheaper. Anyone who doesn’t show you both against your real usage is selling you the tier they prefer to sell.

Implementation. Unlimited licensing does not make the build free, and it doesn’t make change management free either. In our experience the platform is rarely what decides whether a program lands.

What actually changes on the ground

The constraint on your program used to be commercial: how many seats you bought decided how much of the business could participate. That constraint is gone. What replaces it is a harder question — which processes are worth changing, and in what order.

That’s a strategy question rather than a procurement one, and it’s the reason the licence model matters more than it looks. Removing the seat limit doesn’t tell you what to do with the platform. It removes the excuse for not deciding.

Two things to settle before you sign

Your agent volume, modelled rather than guessed. Take the workflows you actually intend to automate in year one, estimate how often each runs, and multiply. If nobody can produce that figure, the AI package size is being picked at random.

Which tier wins on your numbers. Unlimited against per-user, on your real headcount and your real usage, with the AI actions in both columns. Sometimes unlimited is obviously right. Sometimes it isn’t, and knowing which is worth an afternoon.

The honest version

Unlimited is a real change and a good one — it removes the mechanism that has quietly capped CRM adoption for twenty years. It is also not the same as free. The meter moved; it didn’t disappear. Budget for agent volume the way you used to budget for seats, and the model works in your favour.

Modelling agent volume against the licence is part of a CRM implementation with us, before signing rather than after.

Do AI agents need their own permissions?

2026-06-17T12:00:00-07:00

This is the first question every enterprise buyer asks about agents, and the answer should be boring: an agent gets a role, that role lives inside the access model you already have, and an agent cannot read a record its role cannot read.

The interesting part is what goes wrong when it’s answered any other way.

The shortcut everyone takes first

The fast way to ship an agent is to give it a service account with broad access and let the application logic decide what it should see. It works in a demo. It also creates a second permission system that nobody maintains and no reviewer can reason about.

Two things happen after that. First, your access model stops being the source of truth about who can see what — the real answer is now split between the directory and some code. Second, somebody leaves, their access gets revoked, and the agent acting on their behalf still has its own, because nothing ever connected the two. That’s the finding a risk team writes up.

Give the agent a role instead and the properties you want come for free: change the model and the agent’s access changes with it, review the model and you’ve reviewed the agent, remove the role and the agent stops.

Least privilege matters more here, not less

An agent asks more questions per hour than a person does, and it doesn’t get bored. A role scoped generously “so it doesn’t get stuck” will reach everything it can reach, at machine volume, and produce answers drawn from records it should never have opened.

Scope the role to the workflow, not to the department. An intake-validation agent needs the intake queue and the documents attached to it. It does not need the pipeline, and it certainly does not need HR.

The three questions your risk team will ask

What can it see? Exactly what the role permits — and you can show that by inspecting the role rather than by trusting a description.

What can it change? Read and write are separate grants and should be scoped separately. A large amount of useful agent work is read-plus-propose — it drafts, flags or routes, and a person commits. That’s a smaller permission surface than it first appears.

Can you prove what it did? Every action logged, with the records that informed it, so when something is wrong you can find out why, fix the cause and show the trail. Run the work inside a platform with native agent management and the approval step, the execution log and the audit trail are enforced by the platform rather than by convention.

Acting for a person, or acting for itself

Worth separating, because it changes the answer. An assistive agent working alongside someone should act as that person — same permissions, same visibility, nothing they couldn’t have done themselves. An autonomous agent owning a workflow acts as itself, with a role of its own. There’s no person in the seat, and pretending there is makes the audit trail a fiction.

Getting this the wrong way round is a common design error. A copilot with its own broad role can show a user data they aren’t cleared for. An autonomous agent borrowing a named employee’s credentials attributes machine decisions to a human who never made them.

If you remember one thing

Agents do not need special permissions. They need ordinary permissions, granted the ordinary way, scoped tighter than you’d scope a person, and logged. If an implementer proposes anything else, the question worth asking is who’s going to audit it.

We deploy agents with ordinary permissions, scoped and logged, inside the role model you already maintain.

Assistive AI vs autonomous AI — which do you need?

2026-05-20T12:00:00-07:00

Two different things are sold under the words “AI agent”, and deploying the wrong one is the most common way an AI program quietly fails. The distinction isn’t technical sophistication. It’s who does the work.

Assistive: your team, faster

An assistive agent — a copilot — sits with your people. Natural language inside your CRM, your inbox, your chat tool: draft this reply, summarize this account, find the contract term, tell me what happened on this deal.

The person is still doing the job. The agent removes the friction around it.

That has consequences worth knowing before you buy. Adoption is the whole battle, because a copilot nobody opens produces exactly nothing. The payback is broad and quick — everyone gets a bit faster, immediately — and the ceiling is whatever the friction was costing you in the first place. You measure it on time saved per person.

For most organizations this is the right starting point, considerably more often than the market’s enthusiasm for autonomy would suggest.

Autonomous: the work arrives done

An autonomous agent is given an outcome and works toward it on its own schedule, against its own queue, with a person involved at the points you chose. This is the “digital employee” idea.

It earns its keep on continuous, cross-system work nobody has the capacity to do: the referral nobody spotted, the intake queue that’s always three days behind, the document validation that happens when somebody gets to it. You measure it on outcomes produced — revenue found, queue cleared — the way you’d measure a hire rather than a tool.

The ceiling is much higher. So is the design cost, because deciding where the approval gates and confidence thresholds sit is most of the work. Get that wrong and the deployment ends up either pointless or unreviewable.

Neither one is the grown-up version of the other

The framing that does the most damage is “start with copilots, graduate to autonomy”. It implies assistive AI is a training-wheels version of the same thing. It isn’t — they solve different problems, and an organization running both is the normal end state rather than a transitional one.

Your sales team probably wants a copilot. Your intake queue probably wants an autonomous agent. Neither is the immature form of the other, and treating the choice as a maturity question buys you one of two bad outcomes: an autonomous agent doing work a copilot would have done better, or a copilot pointed at a backlog nobody has time to work through with it.

Which one does this workflow want?

One question usually settles it: is there a person currently doing this work who would do it better with help, or is there work nobody is doing at all?

If someone is doing it and the bottleneck is their speed, that’s assistive. If the work is arriving faster than anyone gets to it, that’s autonomous. And if the answer is “someone is doing it and they shouldn’t be”, you’re probably looking at a hybrid workflow — the agent prepares, a person releases.

A person is in both pictures

Both need a human in the loop; the difference is where. With a copilot it’s continuous by construction — the thing never acts alone. With an autonomous agent it’s at designed points: an approval step, a confidence threshold below which the record routes to a queue instead of proceeding, and an exception path for cases nobody anticipated.

That last one is the gate most implementations forget to design, and then discover at the worst possible moment.

Anyone selling you agents with no human in the loop anywhere is selling you a system you can’t review. Autonomy is a decision about where the review happens, not about removing it.

What to do with this

Before the next vendor conversation, write down for one workflow where the review would sit — continuous, or at an approval step, a threshold and an exception path — and what the mistake would cost if the review were skipped. If that answer is easy, you have a copilot job or an agent job and you know which; if it is hard, the workflow is not ready for either yet.

The digital-employee framing is the same distinction from the staffing side, and what an agent should own is the next question after this one.

Where the review sits is the first design decision we make on an AI engagement, and we write it down before the build.

Why CRM data goes bad, and the four fixes that hold

2026-05-06T12:00:00-07:00

Every CRM we have been asked to look at has a data-quality problem, and every one has been described to us the same way: the team does not keep it up to date. The fix proposed is usually a cleanup project and a reminder about discipline.

The cleanup works for a quarter. Then the data is bad again, because the thing that made it bad was never the team. It was the system, and a system that produces bad data will keep producing it after any cleanup.

Here is where the bad data comes from, and the four fixes we have seen hold.

Where it comes from

Fields nobody owns. A field with no owner has no definition, so three people fill it three ways and a fourth leaves it blank. “Industry” is the classic: one person’s “Financial services” is another’s “Banking” and a third’s “FS”.

Text boxes where a list should be. Any value that will ever be reported on, filtered by or used to route work must be a controlled list. A free-text “Region” field will have forty regions within a year, including three spellings of the same city.

More than one way in. Records arrive from the web form, from an import, from an integration and from a person typing. Each path has its own rules, or none, and the duplicates that result are not carelessness — they are four doors and one room.

Reports nobody uses. Data that no report depends on is data nobody has a reason to keep right. If the “Next step” field feeds nothing, it will drift; if it feeds the Monday pipeline review, it will be current by Monday.

Fix one: every reported field has an owner

Not the CRM administrator — a person on the business side whose job depends on the field being right. The owner writes the one-line definition that appears as the field’s help text, decides what the allowed values are, and is the person the report goes to when the field is blank. A field nobody will own is a field the business does not need, and the right fix is to remove it.

Fix two: validate at the door

The point of entry is the only place data quality is cheap. A required field enforced on save costs the person entering it five seconds; the same field backfilled six months later costs a project. Controlled lists instead of text. Formats enforced where formats exist — phone numbers, postal codes, email. A duplicate check that runs as the record is created, not as a monthly report.

The resistance to this is always the same: it slows people down. It does, by seconds, and it stops the hours that follow.

Fix three: one path in, or the same rules on every path

Where the doors cannot be reduced to one, they get the same rules. The web form, the import template and the integration all run through the same validation the manual entry does. In practice this means the rules live in the CRM as workflows and validation, not in the form builder or the import script, so there is one place they are defined and one place they change.

Fix four: put the field in a report someone needs

This is the one that keeps the other three working. Every field the business claims to care about is on a report that a named person reads on a schedule, and that report shows blanks as blanks rather than silently excluding them. A field that is visibly empty on the sales director’s Monday view gets filled by Tuesday. A field that is quietly missing from a chart stays missing.

What a cleanup is for

A cleanup has a place — once, at the start, after the four fixes are in. It brings the existing records up to the standard the system will now hold them to. Done before the fixes, it is a quarter’s grace. Done after, it is the last one.

The honest version of “the team doesn’t keep it up to date”

People keep up to date the data that their own work depends on and that somebody looks at. The rest they do not, and no reminder changes that. Design the system so the fields that matter are owned, validated, single-sourced and looked at, and the discipline problem turns out to have been a design problem all along.

The four fixes are design work, and they belong in a data migration and integration engagement rather than in a cleanup budget.

When should a workflow stay human?

2026-04-22T12:00:00-07:00

Almost everything written about enterprise AI is about what to automate. The more useful question in most discovery calls is the reverse one, because getting it wrong is expensive in a way that doesn’t show up for months.

Here are the signals we look for.

The judgment is real, and nobody wrote it down

Some decisions depend on context that exists only in someone’s head: whether this client relationship can absorb bad news this week, which of two equally valid escalations to run first, how hard to push a renewal with a customer who’s quietly unhappy.

An agent asked to make that call will make it, confidently, against a rule nobody ever defined. The output will look like the work. That’s the problem: a wrong answer that looks right is worse than no answer, because nothing prompts anyone to check.

Being wrong is expensive, and being wrong is quiet

Two conditions, and it’s the combination that matters. High-stakes work with immediate feedback is a good candidate for an agent with an approval gate — the mistake gets caught before it lands. High-stakes work where the error surfaces a quarter later is not, because by then the agent has made the same mistake four hundred times.

The test is not “how bad is a mistake”. It is “how quickly would we know”.

It runs eleven times a month

Placing approval gates, defining confidence thresholds and designing an escalation path that works at 2:00 in the morning is most of the labour in an agent deployment. For a workflow that runs eleven times a month, that design work will never be repaid. You’ll still be maintaining it in three years, when the person who understood it has moved on.

The process is about to change anyway

Automating a workflow that’s under review is building a bridge to a road that’s being moved. Wait. The agent will be cheaper to build against the process you’re about to have than against the one you’re about to retire.

The human contact is the product

Some steps exist because a person doing them is the point — the call where a client feels heard, the negotiation where a relationship gets built, the difficult conversation somebody has to own. Handing these to an agent doesn’t save cost. It removes the thing the client is paying for.

Why an implementer should tell you this

Every one of these findings shrinks the engagement. That’s precisely why it’s worth telling you.

An implementer whose assessment concludes that AI pays everywhere has either not looked or is selling. In practice, most organizations we assess have two or three candidate workflows that should stay human, another handful that belong in a hybrid arrangement — the agent prepares the work, a person releases it — and a smaller set that are genuinely ready for autonomy.

That last group is where the return is. The other two are what makes the return believable, and they’re the reason the deployment is still running two years later instead of having been switched off in six months.

The middle is bigger than either end

Worth saying plainly, because the market frames this as a binary: the answer for most workflows is neither “give it to an agent” nor “leave it alone”. It’s one process with human steps and agent steps in it, and the handoffs designed rather than improvised.

Anything a customer sees, and anything with money attached, generally belongs there — the reasoning is in what an AI agent should own, and it comes down to the review being cheap and the mistake not.

Designing the handoffs in that middle is most of our workflow automation and AI work.

How do you calculate AI ROI?

2026-03-25T12:00:00-07:00

Most AI business cases get built the way software business cases were built, which is why they don’t survive the first serious question. A licence cost on one side, an hours-saved figure on the other: that’s a spreadsheet, not an argument.

There are three benefit lines and three cost lines. Skip either half and the number stops meaning anything.

Three ways it pays

Capacity returned. Hours a week handed back to the team, valued at a blended loaded cost rather than a salary. It’s the easiest number to produce and the weakest one on its own, because “we freed up 130 hours a week” invites the obvious follow-up: freed up for what? It only counts if you can say where the capacity went — more accounts covered, a queue cleared, a role you didn’t have to hire for.

Revenue you’re already leaving on the table. The cross-sell nobody spotted. The renewal that lapsed because it sat in a queue. The quote that arrived two days after the buyer had made up their mind. This is usually the biggest line and always the hardest to defend, because it’s counterfactual — you’re claiming credit for something that didn’t happen.

So measure the leak first. How many referrals actually went unnoticed last quarter, on the record? Now the agent’s contribution is a recovery rate against a real baseline instead of a projection.

Cost taken out. Systems consolidated, contractors not renewed, rework that stops happening. The most credible line of the three, because it shows up on an invoice that either exists next year or doesn’t.

Three ways it costs

Platform. Price the platform per organization and seat count stops being the variable, which kills the annual argument about who “deserves” a licence — usually the thing quietly capping adoption. It does not make the platform free, and for a smaller team the per-user plans are often cheaper. Model both against real usage.

AI actions. New in 2026, and the line most business cases miss entirely. Agent interactions are metered and sold in annual packages, so what you need to forecast is agent volume — how many times a month your workflows will actually run. Not headcount. It’s harder to estimate than seats ever were, and getting it wrong is how a project that looked funded quietly stops being funded in month seven. Work it out before you sign anything.

Build and change. Implementation, integration and the part everyone underprices — getting people to work differently. In our experience the technical build is almost never what decides whether the number lands. Whether the new process survives contact with the people who run it: that’s what decides it.

You cannot compute a return without a before

This is the part that decides whether any of the above is worth anything. A workflow constraint audit — where work stalls today, how often, what that costs you — isn’t the warm-up to the ROI calculation. It is the ROI calculation. Everything after it is arithmetic.

It’s also why a slider on a website is an estimate and nothing more. Ours assumes automation absorbs about 65% of manual entry and triage time, at a blended US$55 an hour. Both of those are our planning defaults, not facts about your business. They’re good for deciding whether the order of magnitude is worth a conversation. They are not good enough for a board paper.

Two ways to tell a real number from a wish

Rank the list, don’t total it. A ranked list of workflows, each with a value against it, is something you can act on. One big aggregate number is not — nobody can act on it and nobody quite believes it.

Include the workflows that shouldn’t be automated. A business case that finds AI pays everywhere hasn’t been tested. Ours routinely concludes that two or three of the candidates should stay human. That shrinks the engagement, and it’s the finding that makes the rest of it credible.

If an assessment hands you a number without the baseline it was measured against, what you’re holding is a proposal wearing a spreadsheet.

What should an AI agent own?

2026-03-04T12:00:00-08:00

This is the question every discovery call turns into, usually about forty minutes in, once the demo enthusiasm has worn off. Not “can an agent do this” — the answer is almost always yes, and it’s not useful. What an agent should own is a question about your business rather than about the technology.

Four tests do most of the work.

1. Is the work continuous?

An agent earns its keep on work that never stops arriving and that nobody has the capacity to keep up with. The intake queue that runs three days behind. The renewal that lapses because the reminder was a person’s memory. The document check that happens when somebody gets to it.

Work that happens twice a month isn’t an agent problem. It’s a calendar problem, and automating it produces a maintenance burden with no offsetting return. The rule of thumb: if nobody is currently behind on it, an agent won’t give you anything you don’t already have.

2. Does it cross systems a person has to bridge by hand?

The most reliable agent wins involve work where a human is currently the integration layer — reading something in one system, deciding and typing it into another. That re-keying is pure cost. It’s where errors enter, and it’s exactly what an agent with access to both sides removes.

If the work happens entirely inside one screen and one record, the honest answer is often that you want a better form, not an agent.

3. Is “correct” checkable after the fact?

This is the test people skip, and it’s the one that decides whether the deployment survives. An agent’s output has to be something a person can look at and tell whether it was right — a routed record, a drafted reply, a flagged discrepancy, a populated field. Then when it’s wrong you can find out why, fix the cause, and show the trail.

Work whose correctness only becomes apparent months later, or that depends on context nobody wrote down, doesn’t fail loudly. It fails quietly, and for a long time. Those workflows need a person, and a good implementer will say so.

4. Would you be comfortable explaining the decision rule out loud?

If the work involves a judgment you’d struggle to articulate to a colleague — whose account to prioritize, whether a client relationship can take bad news this week, how hard to push on a renewal — an agent will produce a confident answer to a question you never actually defined. Confidence without a defined rule is the failure mode, and it looks like success right up until it doesn’t.

Judgment work is not a gap waiting for a better model. It is the part of the job that is the job.

What passing all four looks like

Run the four tests over a real list and the shape falls out quickly. Most organizations find three or four workflows that pass all four, another handful that pass with a human approval gate in the middle, and a long tail that shouldn’t be touched.

The middle group is the interesting one, because it’s where hybrid workflows live: the agent prepares the work and a person releases it. Anything a customer sees, and anything with money attached, generally belongs there rather than in full autonomy — not because the agent can’t do it, but because the review is cheap and the mistake is not. The other half of this decision — which steps stay with a person, and why — is its own piece.

The tail matters too. Telling a client that a workflow should stay human shrinks the engagement. Saying it anyway is the difference between a deployment that’s still running in two years and one that got switched off in six months.

The one thing not to do

Don’t decide this from a demo. A demo shows you the technology working on a scenario chosen because it works. The decision you actually need is which of your workflows clears the four tests, and in what order. That’s a couple of weeks of looking at how work moves through your business, not an afternoon of watching software.

We run the four tests on your own queue before we scope an agent for any of it.

The CRM migration checklist we use

2026-02-25T12:00:00-08:00

Most CRM migrations are planned as a data exercise: export, map, import, check the counts. The counts match, the project is declared done, and six weeks later the sales team is keeping a spreadsheet again because the new system has every record and none of the habits.

The migrations that hold are planned the other way around. The data is the last thing decided, not the first. Here is the list we run, in the order the decisions actually have to be made.

Decide what the new system is for

Not “replace the old one”. A migration is the one moment when a company can ask what it wants the CRM to do, because for once nobody is defending how it works today. Write down the three things the new system has to make easier — the renewal that gets missed, the quote that takes a week, the report that is built by hand every Monday.

Everything below is measured against that list. If a field, a workflow or a report does not serve one of the three, it is a candidate for leaving behind.

Inventory what people actually do, not what the system has

The old system will have four hundred fields. Perhaps sixty carry data anyone has looked at in a year. Before mapping anything, sit with the people who use the system and watch a week of their work: which screens they open, which fields they fill, which they skip, and what they keep in a notebook because the system has nowhere for it.

This is where the migration earns its cost. The fields nobody fills are dropped. The notebook becomes a field. The report that three people rebuild every week becomes the report the system produces. None of this shows up in a data map.

Rebuild the process, do not lift it

A legacy workflow encodes a decision somebody made years ago against constraints that no longer exist. Lifting it into the new system preserves the constraint without the reason. Each workflow that moves gets asked one question: if we were designing this today, for the people who run it today, would it look like this? Usually the answer is “mostly, but the approval step is in the wrong place” — and the migration is when the approval step moves.

The migrations we have seen fail were faithful. The ones that held were unfaithful on purpose.

Map the data last, and map it from the new side

Only now does the field mapping happen, and it is written from the new system’s fields back to the old ones. Starting from the old side produces a map that carries everything; starting from the new side produces a map that carries what the new system needs. Every unmapped old field is listed with a decision beside it: archived, dropped or merged. “Not sure” is not a decision; it becomes a question for the process owner with a date.

Data cleaning happens here, in the old system, before the move — duplicates merged, dead accounts closed, the picklist with nine spellings of the same value collapsed to one. Cleaning after the move means cleaning in a system people are trying to learn.

Rehearse the cutover, twice

The first rehearsal is a full migration into a sandbox with the real data, run by the people who will run the real one, timed. It will surface the field that was mapped to the wrong type, the record that breaks the import, the integration that assumed an ID format. The second rehearsal is the first one again, after the fixes, and it is the one that tells you how long the real cutover will take. If the second rehearsal is not boring, there is a third.

Run the two systems together for one cycle

One business cycle — a month for most sales teams, a quarter for some — with the new system live and the old one read-only. Not both writable: a parallel run where people can still enter data in the old system is a run in which they will. Read-only keeps the old system as a reference for the question “what did we have for this account” while making the new one the only place work happens.

The step everyone skips

Decide, before go-live, what the old system’s fate is and when. Left running “just in case”, it becomes the place where the inconvenient records live, and a year later the company has two CRMs and a reconciliation problem. The decision is a date, a person and an archive format. It is the least technical item on this list and the one most often missing.

What this looks like from the client side

Fewer fields than before. Some workflows that look different from the old ones, on purpose, with the reason written down. A cutover that took about as long as the second rehearsal said it would. And a sales team that stopped keeping the spreadsheet, because the system now has the thing the spreadsheet was for.

That last one is the test. Record counts are not. This checklist is the shape of our migration and integration work; the assessment before it is where the “what is the new system for” question gets answered.

How do AI coding agents speed up development cycles?

2026-02-11T12:00:00-08:00

Coding agents have been useful for two years, and disappointing at enterprise platform work for most of that time. What changed isn’t the models. It’s what the agent can see.

The expensive kind of almost-right

Point a general coding assistant at CRM customization work and you get plausible code that doesn’t belong to your system. It doesn’t know your object model, your naming, or the UI framework everything else is built in. So a developer spends the saved hour reconciling the output with the platform, and the net gain lands somewhere near zero.

The worse outcome is the one that ships: a component that looks and behaves subtly unlike everything around it. Nobody notices for a year. Then someone new opens it, can’t tell why it’s different, and works around it.

Native integration removes that step. Give the agent the platform’s data models and its UI framework — Creatio’s Freedom UI, here — and the code comes out already shaped like the application. There’s nothing to stitch, because it was never in pieces.

Creatio’s July 2026 release is named for the claim — 10x productivity, 10x speed and 10x business impact, with AI-powered design tools doing the accelerating. That’s their figure, for their platform. Treat it as the ceiling rather than the promise — how close you get depends enormously on what you’re building.

Describing the thing instead of assembling it

For the people doing the work, the change is that a component now starts as a sentence. Instead of building the workflow by hand or writing the section from scratch, someone says what it should do, and the agent produces the components, the logic and the dashboards.

This isn’t no-code, and it doesn’t replace it. The pattern that works best is both at once: the agent generates the heavy backend logic and the core structure fast, and the visual designer is where the interface gets assembled and tuned. Each does the part it’s good at, and the handoff between them isn’t a wall.

It also moves the line between developers and the people who know the business. Both are now working in the same governed environment on the same application. That changes who’s on a delivery team, not just how fast the team goes.

So where does 10x actually come from?

Almost none of it is typing faster. The gain sits in the parts of a project that were never coding: the three weeks waiting for a developer with capacity, the round trip to turn a business requirement into a specification, the rework when the thing you built turns out not to be the thing that was described.

Which is also where it stops. A 10x gain on the build doesn’t compress the decisions — what the system should do, who owns which process, what “correct” means for your data. Those still take exactly as long as they took. We’re worth more to you during that part than during the build, and that’s not a coincidence: the build was rarely the expensive part.

So here’s the honest version of the claim. Coding agents make implementation cheap enough that getting the design wrong becomes the biggest line in the budget. That’s an argument for spending more on discovery, not less.

What to do with this

If a proposal quotes you a build time, ask what share of the total is discovery and design, and what happens to the estimate if the requirement changes after week one. A team using coding agents well will give you a small build number and a real answer to the second question. That is what our custom software work is priced around, and the Implementation Assessment exists because the design is where the money is.

How do digital employees differ from traditional software automation?

2026-01-14T12:00:00-08:00

“Digital employee” is worth being precise about, because the alternative is that it turns into a synonym for automation and stops meaning anything at all. The difference is real, and it has nothing to do with the technology being newer.

You hand over the outcome, not the recipe

Traditional automation runs the steps you defined. You specify the trigger, the branches and the outcome, and it does exactly that — reliably, and only that. Then reality hands it a case nobody anticipated, and it either stops or does the wrong thing with total confidence.

A digital employee gets a goal and the means to reach it. It works out the sequence itself, and it can handle a case nobody listed in advance — because it was never working from a list. That’s the real shift: you describe the destination instead of the route.

Which changes how you scope one. You don’t map every branch. You settle three things: what “done” means, what it’s allowed to touch, and what it has to ask about.

It works alone, but it does not decide alone

The other line worth drawing is against assistive AI — copilots (the longer version of that distinction). A copilot sits beside a person and makes them faster: drafts the email, summarizes the thread, answers the question. The person is still doing the work.

A digital employee does the work. It runs on its own schedule against its own queue, and a person steps in at the points you chose: an approval gate, a confidence threshold, an exception. That isn’t a watered-down autonomy — it’s the design. A digital employee with nobody to answer to is not an employee; it is a liability with a queue.

Which means a digital employee needs what a new hire needs. A defined remit. Access that matches it. Someone who’d notice if the output were wrong. A way to escalate.

Measure it like a hire, not like a licence

You justify automation on cost: the licence is cheaper than the hours. You justify a digital employee the way you justify a hire — on what it produced.

A referral agent spotting cross-sell across a bank’s divisions is doing a job you’d hire someone for, at a volume you’d never staff. An intake agent validating loan documentation is absorbing work an underwriting team absorbs today. So the question stops being “what does the licence cost” and becomes “what is this responsible for, and did it deliver”.

That reframing is uncomfortable, and that’s rather the point — it makes the deployment accountable to something. Most AI pilots die because nobody could say what they were for.

Why the pilot never graduates

“Move beyond pilots” has become a slogan because pilots optimize for the wrong thing. A pilot proves the technology works. It almost never proves anyone’s job changed, because it was deliberately scoped not to touch anything that mattered.

Deploying a digital employee means picking a workflow that is genuinely somebody’s problem, giving it an owner, and measuring it afterwards. Smaller than a transformation program. Considerably more real than a proof of concept.

So we hand an agent its first job the way you would hire: one workflow, an owner, a baseline, and a measurement afterwards.