The problem
The CRM was bought so everyone could see where every client and every job stood. What it holds is whatever somebody had time to type in. The quote went out by email, so the record still says "enquiry". The client rang and agreed the variation, so the value is wrong. The site visit happened, the notes are on a phone, and the record has no next action.
Keeping it right means somebody, usually the owner or the office manager, sitting down and going back through the inbox, the sent items, the calendar and the quote folder, and typing what happened into the right fields. That happens when there is time, which is never the week it is needed. So the pipeline number in the CRM is wrong, and everyone knows it is wrong, so nobody uses it, so nobody updates it.
The cost is the afternoons spent re-typing what already happened somewhere else, and the decisions made from a pipeline figure nobody trusts.
When a quote goes out, a meeting is held or a client replies, the record shows it, because the update was drawn from the email and the calendar rather than typed in later.
The pipeline figure is worth looking at, because the stages and the values behind it were changed when the events happened.
The person who used to spend the afternoon catching up reviews a list of proposed changes instead, and rejects the ones the build got wrong.
What it does
The record kept up to date from the emails, quotes and calls that already happened, as proposed changes that a person approves.
The build reads what already happens in your email, your calendar, your quote folder and your job system, and turns it into the updates your CRM should have had: a quote sent moves the stage and sets the value, a client reply sets the next action, a meeting in the diary becomes a logged activity, a signed quote moves the record to won and starts the job. Your stages, your fields, your naming.
It writes those updates as proposed changes, in a batch, for a named person to look through and approve. Once your team trusts a kind of update, that kind can be applied on its own while the rest still wait. Anything the build cannot match to a record, or matches to two, goes on a list for a person rather than into the wrong record.
Who it suits
A business that has a CRM or a job system, is paying for it, and knows it is out of date. It suits teams where the real record of what happened is in email and the calendar, which is nearly all of them, and where a few people carry the whole burden of keeping the system honest.
It suits less well where the CRM is not really used at all, because there is no record to keep up to date. It suits less well where nobody has agreed what the fields mean, because then two people would update the same event differently. If either of those sounds like your office, say so on the free call. We will tell you whether it fits before you pay for anything.
What it needs from you
Access to the CRM and to the mailboxes and calendars the updates come from, arranged so that a person can withdraw it. Your stages and your fields, and what each one is supposed to mean, which is usually where the trouble starts. And an honest account of who updates what today and how far behind it is.
Your records are a mess in the way everybody's are: duplicate clients, contacts on the wrong company, jobs with no value, stages used to mean different things in different years. The data check finds that. Some of it gets tidied before the build, some of it gets rules, and some of it stays manual because the only person who can tell the two Smiths apart is the person who met them.
Signature to live: from 4 weeks, depending on the size of the job.
What it does not do
It does not send anything to a client. It does not create a new client or a new job on its own: a record it cannot match goes to a person. It does not change a value or a stage without leaving a note of why and what it read, so a person can undo it. It does not read anything you have not told it to read.
It does not know that the email saying "great, go ahead" was about the small job and not the big one, and version one will get some of those wrong in a way only the person who was on the call will spot. Every proposed change goes past a person until your team says which kinds are safe to apply without them, and anything that changes a value stays with a person for good.
This is an Assembles build. It gathers what happened from the places it already lives and puts it on the record, for a person to approve. It does not draft a document and it does not check a job for gaps.
Assembles One route, signature to live: from 4 weeks, depending on the size of the job and the state of your data. We'll tell you on the audit.
Where it sits in the process
Automating CRM updating is one route, built on its own. The free 10-minute call tells you whether it fits and gives you a rough estimate: a range for the first route, not a quote. The paid audit looks at your real documents and your real data, works out what the work costs you a year in your own figures, and writes down what to build first. The fixed price for the build comes from the audit, with three options that cut scope rather than corners. Then the data check, the build, the parallel run, go-live and training, and monthly running. All nine stages are on the About page.
Related systems
See it running: read the case study.