To change or to not change the due dates of activities, that is the question.

The most often debated topic when working with activities or tasks in CRMs like Pipedrive is whether you should change the due dates of overdue activities.

I will present what I think is the best thing to do with overdue tasks or activities.

Problem

On any given day, a salesperson has to do a number of tasks. Life happens and they may not be able to get through their tasks for the day, even if the number of tasks is manageable. Moreover, more often than not, salespeople are burdened with more tasks than they can handle. So any task they are not able to complete on a given day becomes an overdue task the next day.

The argument in favor of changing due dates is that people do not want to deal with the burden of having ‘overdue tasks’.

The biggest problem with moving due dates is that you lose context of how overdue you’re. On any given day, it is impossible to tell apart a task that is actually due for today from a task that was rescheduled for today. So there is a very high chance that activities that have been overdue for long will continue to be overdue because you will always have more activities than you can reasonably complete in a given day.

Secondly, it gives you a false impression that you’re on top of your sales pipeline and that things are fine when they’re actually not. The workload in the upcoming week far outweighs the workload in the weeks after.

So, my advice is to not move due dates. When you start your day, focus on everything that’s due for today. Once done, move to the Overdue list, and get cracking. Over time, you will get rid of overdues, but if you keep moving due dates of tasks, you will have to do this due date moving activity every day, which is a complete waste of time.

Scenarios where you need to change due dates

Apologies if this heading got you excited.

But I am going to rule out every case where you want to change the due date of the activity or, in simple words, move the activity.

Moving an activity without talking to a lead

Don’t do that.

If you do that, you’re asking the prospect to move according to your pace, where in fact, you should be responding to the prospect’s needs by moving along their pace.

Moving an activity when your outreach attempt was not successful

If your outreach attempt was unsuccessful, mark the activity as done, and schedule a new activity for a future date.

If you do that, you will get a clear idea of the number of attempts you’ve had to make to finally get in touch with somebody. This information will be very useful when you try to model “what happens if our leads increase by 10%”.

If you don’t do that, you will lose sight of how hard you’ve tried to reach out to somebody, and if you have tried enough. At some point, you have to give up on trying to reach out to a prospect, right?

Moving an activity with an incorrect due date

This one’s easy.

Just be careful when creating activities. Make it a habit to check these details when creating activities to avoid wasted time and effort, and frustration.

Be patient and diligent.

Moving an activity to follow up in the future

Again, don’t do that.

Just mark the previous activity as done, jot down your notes, and schedule the next activity. Let the logged data tell you and your team how many activities are required to get prospects into a particular stage of the pipeline. This will help them plan staffing requirements too.

Conclusion

My advice was always going to be ‘don’t do it’.

I just wanted to rule out every case one would think of to justify moving activities.

So, don’t do it.

It’s better to have overdue tasks than to move due dates of activities or tasks.

I’m starting a CRM and sales operations service and I’m looking for one small business using HubSpot to work with as a pilot.

I’d review and tidy up your sales pipeline things like stale deals, missing information, unclear ownership and missed follow-ups.

I’m doing the first one for free because I want to build a proper case study from real work. I’d just ask for honest feedback and, if you’re happy with the result, a short testimonial.

If your HubSpot pipeline has gotten a bit messy and you’d like some help, feel free to reply.

Short answer: document the business problem, the current workflow, the required outcomes, and the exceptions that matter. You do not need a finished technical specification, but you should give prospective implementers enough detail to distinguish a real solution from a generic software pitch.

A useful preparation packet can be only a few pages. Include these six sections:

1. The decision you are trying to make

State whether you are evaluating a new CRM, improving an existing system, automating a handoff, replacing spreadsheets, or integrating two platforms. Name the decision deadline and who will approve the work.

1. The current workflow

Describe where the process starts, each major step, who owns it, which systems are used, and where work commonly waits or gets re-entered. A simple numbered list is often more useful than polished diagrams. Include one representative example using fictional or redacted data.

1. The required outcome

Define what must be better in observable terms. Examples include one accountable owner per request, fewer duplicate records, visible failure queues, consistent approval history, or a reliable way to report status. Avoid prescribing a feature before explaining the operational result it must support.

1. Users, roles, and permissions

List the people who create, review, approve, assign, complete, and report on the work. Note what each role must see or change. This prevents an estimate built around administrator access while overlooking daily users.

1. Data and integrations

Identify the important records, their current sources, required fields, approximate data condition, and any systems that must exchange information. For every integration, describe the direction of data, trigger, timing expectation, and which system should be authoritative.

1. Exceptions and constraints

Document the cases that do not follow the happy path: duplicates, missing information, cancellations, reassignment, offline work, failed payments, unavailable APIs, or records that require manual review. Also disclose security requirements, retention rules, budget boundaries, internal technical capacity, and dates that cannot move.

Ask every proposer to separate assumptions, standard configuration, custom work, integrations, migration, testing, training, ongoing ownership, and out-of-scope items. Require them to explain how failures are detected and recovered, not only how the normal path works.

You do not need to choose the software first. In fact, documenting the workflow before selecting a platform makes it easier to compare options against the same needs and exposes where process decisions—not technology—are still unresolved.

Which part of your current workflow would be hardest to explain accurately to an implementation partner?

Treat CRM migration as a business-decision project, not a bulk copy. The safest goal is not “move every record.” It is “move the records people need, in a structure they understand, with enough traceability to trust the new system.”

Start with these six decisions:

1. Define what must move. Separate active customers, open opportunities, current contacts, required historical records, and data that can remain in a read-only archive. Keeping everything often preserves duplicates, obsolete fields, and unclear ownership.
2. Assign an owner to each data set. Sales should decide what makes an opportunity active. Finance should confirm which account identifiers matter. Operations should define the customer and job details needed after handoff. A technical team can map fields, but it should not invent business definitions.
3. Create a field-level mapping. For every source field, document the destination field, data type, allowed values, transformation rule, and what happens when the value is blank or invalid. Mark fields that will be retired. This catches ambiguity before import day.
4. Clean by rule, not by intuition. Agree on repeatable rules for duplicate contacts, inconsistent company names, stale statuses, malformed email addresses, and records without owners. Preserve original IDs so questionable records can be traced back to the source.
5. Rehearse with a representative sample. Include ordinary records and difficult cases: multiple contacts at one company, closed and reopened opportunities, missing values, unusually long notes, and records connected to several objects. Have actual users check search, ownership, timelines, reports, and downstream handoffs.
6. Reconcile after each test import. Compare source and destination counts by record type and status, then investigate differences. Spot-check key fields and relationships. “The import finished” is not the same as “the migration is correct.”

Before the final cutover, write down the freeze window, final export time, import sequence, validation owners, rollback threshold, and how changes made during the freeze will be handled. After launch, keep the old system read-only for an agreed period instead of immediately deleting access.

One practical test: ask a salesperson to find an active account, understand its recent history, identify the next action, and hand it to operations. If that flow is confusing in the migrated sample, more mapping work is needed before go-live.

This community is support by Hexagon IT Solutions

Which part of CRM migration has created the most uncertainty for your team: deciding what to keep, cleaning it, mapping it, or validating the result?

Chameleon-CRM has grown to the point where calling it a CRM doesnt really explain what it is anymore.

The original idea was simple: why should a business need a CRM, scheduling platform, dispatch system, invoicing software, payment system, employee management platform, inventory software, marketing tools, customer portal, field-service app, and a pile of integrations just to run one company?

So we started building Chameleon as an Adaptive Business Operating System instead.

Chameleon handles customers, leads, jobs, tickets, appointments, estimates, invoices, receipts, expenses, taxes, vendors, purchase orders, inventory, employees, payroll, time tracking, subscriptions, memberships, gift cards, marketing, payments, automations, customer communication, field technicians, and more from one connected system.

But the biggest difference is that Chameleon is completely adaptive.

When we say adaptive, we don't mean that you can change the color of the dashboard or rearrange a couple widgets.

We mean Chameleon is designed around the idea that the software should adapt to the business instead of forcing the business to adapt to the software.

An HVAC contractor doesn't operate like an auto repair shop. An auto repair shop doesn't operate like a salon. A landscaping company doesn't operate like an MSP. A roofer doesn't operate like a veterinarian. Even two HVAC companies may have completely different workflows depending on their size, services, employees, dispatch model, and how they get paid.

Traditional CRMs usually start with one workflow and expect everyone to fit inside it. Chameleon takes the opposite approach.

Your industry, workflow, enabled features, team structure, permissions, terminology, and the way you actually use the system determine what your Chameleon environment becomes.

That means Chameleon can function as an HVAC CRM, plumbing CRM, electrical CRM, landscaping CRM, roofing CRM, auto repair system, detailing CRM, janitorial platform, pest-control CRM, salon management system, MSP platform, veterinary business system, or something entirely different without us maintaining a completely separate application for every industry.

And adaptation doesn't stop at signup.

A one-person business might primarily use customers, scheduling, estimates, invoices and payments. As that company grows and hires its first technician, Chameleon can become a dispatch system. Add office employees and it becomes a multi-user operational platform. Add inventory and purchasing and it starts managing that side of the company. Add recurring services and memberships and it begins managing recurring revenue.

The same Chameleon workspace can evolve with the company.

That's the philosophy behind the name Chameleon.

Dispatching is one of the largest parts of the system. A company can create a job, assign a technician, schedule it and dispatch it directly from Chameleon.

Road technicians don't need normal Chameleon accounts or passwords. They can receive secure magic-link access to the work they've actually been assigned. That gives them a purpose-built field interface without exposing the company's entire CRM.

From the field, technicians can access job and customer information, view instructions, upload job photos, update work, communicate with dispatch and use the tools required to complete the job.

Chameleon also supports live field location functionality. Dispatch can see technician locations while they're working, and Premium businesses can enable breadcrumb location history when they need additional visibility into field operations.

Internal employees are handled differently. Owners can create authorized users such as managers, dispatchers, supervisors, salespeople, accounting personnel and support staff and control what those users are allowed to access.

And an authorized Chameleon user isn't automatically considered a clocked-in employee. If that person also belongs on payroll, they're created in the payroll system and punch in and out like any other employee. System access and employment records remain separate.

Scheduling is integrated directly with the rest of the platform. Businesses can create appointments, connect them with customers and jobs, manage their calendar and require deposits when necessary.

If you receive an appointment that you're uncomfortable confirming without money down, you can require a deposit and have the customer directed through the payment process before that appointment is confirmed.

Chameleon also handles estimates, invoices, receipts, expenses and taxes. Instead of financial documents existing in an unrelated program, they're connected to the customer and the work that generated them.

For larger jobs, Project Milestones allow businesses to break a project into stages and collect incremental payments instead of financing an entire project themselves until the final invoice.

Recurring revenue is built into the platform through subscriptions and memberships. HVAC maintenance agreements, landscaping plans, cleaning contracts, managed IT services, pest-control programs and other recurring services can live alongside ordinary one-time jobs.

Inventory and purchasing are part of the system as well. Businesses can manage products, inventory, vendors and purchase orders while keeping those operations connected to the rest of the company.

Chameleon includes employee and payroll functionality, time logs and punch-in capabilities so businesses can manage the people doing the work alongside the work itself.

There's a customer-facing side too. Customer portal functionality allows businesses to give their customers access to the information intended for them without exposing the internal CRM.

Chameleon includes communication tools and a Unified Inbox so conversations aren't completely disconnected from the customers and jobs they're about.

We've also built marketing capabilities directly into the platform, including AI-assisted marketing tools. Smart Invoices and other AI functionality are designed around reducing repetitive administrative work rather than adding an AI button just because AI is popular.

Automation is another major part of where Chameleon is headed. If the system already understands the customer, appointment, job, invoice, technician and payment, those pieces shouldn't require humans to constantly move information between different applications.

There's also the System Hub, which gives owners centralized control over authorized users, permissions, configuration and other administrative parts of their workspace.

Payments are integrated into Chameleon as well. Businesses on the Free plan currently have a 2.9% Chameleon platform fee, while Premium reduces that to 0.8%. Premium is currently $79/month or $499/year, meaning businesses processing enough payments may be able to justify Premium from the reduced platform fee alone.

Then there's Desktop Mode, which is our attempt to rethink what business software itself can look like.

Instead of everything being permanently trapped inside the traditional sidebar-and-dashboard CRM design, Chameleon can provide an operating-system-like environment with applications, windows, shortcuts, wallpapers, pop-out functionality and workflows designed with multi-monitor businesses in mind.

Chameleon also supports different saved working environments because an owner, dispatcher, accountant, manager and marketing employee shouldn't necessarily stare at the same workspace all day.

That's really where the adaptive concept comes together.

Different industries. Different employees. Different workflows. Different stages of growth. Same underlying platform.

A two-person HVAC startup should not have to operate Chameleon the same way as a 30-person service company.

A dispatcher shouldn't have to use it like an accountant.

A road technician shouldn't have to use it like the owner.

And a landscaping company shouldn't have to pretend it's an HVAC company because that's how its software was originally designed.

The software changes around the business.

That's what we mean by Adaptive CRM.

The long-term goal isn't to build the biggest collection of features possible. It's to build a system where those features actually understand one another.

A lead becomes a customer. A customer books an appointment. An appointment becomes a job. A dispatcher assigns a technician. The technician performs the work. Photos and information come back from the field. The work generates an invoice. The customer pays. The payment becomes part of the business's financial picture. The relationship can become a membership or recurring service. Marketing can bring that customer back again.

One continuous system instead of ten applications passing data back and forth.

That's why we're increasingly hesitant to describe Chameleon as simply another CRM.

We're building toward something much larger:

An adaptive operating system for running a business.

And we're still building.

DaemonCore

This is a weekly post for you to let out about something which happened this week for you in CRM that mattered: features, client requests that were either great or awful this week, and just generally chat CRM / CRM consulting chatter.

No self promo, just a place to share tales from the front-line of CRM!

Our sales and service teams have been utilizing a Workflow CRM. However, we've hit a limiting point where every new process requires manual configuration, duplicate approvals, and regular follow-up from department managers.

For instance, when a sales opportunity actually results in a customer, the process of setting the account up, onboarding and initiating a service requires separate workflows for each team. If we take too long to get one approval, onboarding can be stalled for days, resulting in a flood of people requesting the same information.

As the Director of Business Applications, I wonder if this signifies that our Workflow CRM might be too rigid or if we are just simply putting together poor processes. I also worry that if we use more automation, this could make it harder to solve problems later.

Has anyone redesigned their Workflow CRM successfully to eliminate approval bottlenecks while retaining the required approval process and audit parameters?