How can I ensure response times are tracked correctly in HubSpot?
I’m having trouble with lead response times.
We lead routing workflows that bring in a lead from a form fill.
During hours:
The lead is time stamped with Timeapi.io webhooks
Branched to the correct team
Assigned to a contact owner (TIME STARTS)
Creates a Deal for the Contact Owner to Follow Up On
After Hours
The lead is time stamped with Timeapi.io webhooks
Branched into a delay until the next morning at 8a (weekdays) or Monday morning at 8a (if after 5pm on Friday)
Then branched to the correct team
Assigned to a contat owner (TIME STARTS)
Creates a Deal for the Contact Owner to Follow Up On
Here’s what I’m struggling with:Half the time to respond is never right.
I.e. the Workflow for the lead may run at 11:00a → the rep will log a call at 11:37a → the lead response time will be 45 minutes?!? or some other random amount of time.
I’m not sure what I’m missing but we have this issue all the time where the lead will have activity against it (on Contact or Deal object) but the response time is messed up and we can get good SLAs for our team.
Our reps are constantly upset that their metric isn’t correct.
Help?! Moderator Note: this post was reviewed for relevancy and optimized for clarity on October 28, 2025. Thank you for your contributions to the HubSpot Community!
So for me it looks like the response time is from assignment to first activity logged. I guess there’s the possibility that we’re having issues with the user coming in as a lead a secondtime and the activity is measured against the first time (previous) time they were assigned – but this seems wrong as well.
Curious as to if anyone else is having trouble with this – and gettin more thinking on the table!
Thanks for clarifying @sethnenstiel, I didn’t realize you were having issues with the default lead value - I thought you had custom properties with Timeapi.io
Maybe we need to dig deeper into the workflow:
I.e. the Workflow for the lead may run at 11:00a --> the rep will log a call at 11:37a --> the lead response time will be 45 minutes?!? or some other random amount of time.
- If the workflow runs at 11:00a, is it triggering as soon as the lead converts (is created) or is there a delay (not necessarily a delay added to the workflow, but an actual delay in processing)?
- With your example being off by about 8 minutes, I’m wondering where that time is spent - is the call being made out of HubSpot?
Is it a manually logged call? Did they initiate another activity that was logged, like a follow up email, and then go back and log the call?
- I’ve found the best way to deal with time discrepancies is to find 3-5 specific examples and see if you can track down exactly why they are off.
Usually it’s something in the process, not the calculation.
@Jnix284 – there is no artificial delay in the workflows that assign leads – I checked. Leads are assigned immediately during normal business hours.
Calls are logged manually as we don’t have an integration with our call center software.
Emails / sequences are logged by HS.
I’ll have to try to find several use cases like you mentioned. But I was looking for Workflow start time (should be pretty close) to First Logged Activity – as I didn’t see an Owner Assigned event in the timeline. But I assume the workflow runtime is pretty much instantaneous to lead assignment – while it’s “complex” the flow isn’t all that complicated and wouldn’t require a delay – the longest lag may be from Contact Assignment to Deal record creation – but this would cause a few minute lag at the beginning and not a discrepancy between Logged Activity and Response Time.
Hi@sethnenstiel,
Might be worth trying a custom field.
- I’ve seen teams get better lead response tracking in HubSpot is by creating a custom property something like “First Rep Assigned” or “Initial Assignment Time.”
- Then, use a workflow to set that value the moment the lead gets assigned.
That way, even if the contact owner changes later, you still have a clear record of when and to whom it was first routed.
- You can also track when the first real activity happens like a call or email by using activity-based triggers. Comparing that to the assignment timestamp gives you a much more accurate view of actual response time (instead of relying only on the timeline, which can be messy).
- And if your routing is getting more complex multiple teams, SLAs, ownership rules tools like LeadAngel can help a lot. It works well alongside Salesforce and handles lead-to-account matching, automated assignment, and even keeps a record of handoffs so your reporting doesn’t fall apart.
HubSpot can definitely do a lot, but combining it with the right external tools makes life way easier for ops and sales teams trying to stay on top of metrics.
What you’re talking about is a fairly common problem when it comes to tracking lead-response time in HubSpot. Certain factors can trigger “random” timescales:
Timestamp error A: The “time recorded” value that you’re saving using TimeAPI may be slightly different from the HubSpot internal time of assignment. Just a few seconds off at the beginning could make the math look a bit off later.
Multiple activities on various objects In the event that you’re using Contact along with Deal objects to gauge the time to respond, HubSpot may be picking the wrong event to stop the loop.
Enrollment criteria and delays Delays that last until the following day or on a weekend could be re-enrolled or replace properties.
Some steps that can solve the problem:
Use a single “start” event only -for e.g. at the moment you assign the person to an ownership. Then, store that information in a designated datetime property.
Utilize one “stop” action -for e.g. the first call logged email, note, or call from the owner. Keep that information in a separate file.
Determine the amount of difference in these two property (HubSpot’s “time between” calculation will be used right today, or you can do it externally).
Convert milliseconds to minutes/hours -divide by 60,000 to get minutes or by 3,600,000 for hours.
This will make your SLA reporting much more reliable because you’re measuring from identical two points each time. If you’re making manual conversions, or are checking long intervals using an hourly calculator (for reference) could be helpful for confirming the math before you write it down.
This usually eliminates the “why does it take the 45 minute time?” complaints and gives your reps a phone number they can count on.
Best Reagrds
Abhatti
I’m just getting started and this looked like the most relevant thread. I have a new Hubspot instance, basic workflows, and am looking to report on initial lead response times excluding nights and weekends. Is the Timeapi.io webhook your recommendation or do you have a different solution? Much appreciated, thanks!
Hi @CBretz4 I would not start with Timeapi.io unless you need precise business-hours math across nights and weekends.
The first thing I would separate is HubSpot’s default lead response time from your own SLA definition. HubSpot’s number can get noisy because it depends on owner assignment and qualifying engagement logic, which may not match how your team thinks about response time.
For a new HubSpot instance, I would create custom properties for:
SLA Start Time
First Real Sales Touch Time
First Sales Touch Type
SLA Status
Assigned During Business Hours
Then only stop the clock when there is a real buyer-facing touch: sales email, call, meeting, or manually confirmed first touch.
I would not stop the clock for task creation, deal creation, owner assignment, internal notes, lifecycle changes, or workflow actions.
If you only need “did we respond inside SLA?”, HubSpot workflows and custom datetime properties can usually get you close. If you need true working-hours elapsed time, like subtracting nights and weekends from the actual timer, that usually needs custom code, an external workflow step, or a purpose-built SLA tool.
@CBretz4 yes, I’d start with a simple HubSpot-native version before adding Timeapi.io or custom code.
I’d build it in this order:
Create a datetime property for SLA Start Time.
This is usually stamped when the lead is created, qualified, or assigned, depending on when your team wants the clock to start.
Create a datetime property for First Real Sales Touch Time.
Only set this when there is buyer-facing activity: sales email, call, meeting, or a manually confirmed first touch.
Create a dropdown property for First Sales Touch Type.
Example options: Email, Call, Meeting, Manual, None yet.
Create a dropdown property for SLA Status.
Example options: Inside SLA, Late, Not contacted, Excluded / outside business hours.
Use workflows to stamp the SLA Start Time and then update the status based on whether First Real Sales Touch Time exists before your SLA deadline.
The tricky part is business hours. If your rule is simple, like “only count leads created Monday-Friday during working hours,” you can usually get close with workflow branches and an Assigned During Business Hours property.
If you need exact elapsed working time, like subtracting nights, weekends, and holidays from the timer, that’s where custom code, an external time API, or a dedicated SLA tool becomes more useful.
I’d start with one question: what should count as your SLA start point — form submission, owner assignment, or lifecycle/lead status change?
Hey @sethnenstiel, this is super common with custom-built routing like yours. The mismatch usually comes down to which timestamp HubSpot is using behind the scenes. If you’re logging time through a webhook into a custom property, but HubSpot’s native response time metric is based on something different, like the creation date or the actual assignment timestamp. That’s exactly the kind of gap that throws everything off, especially with your after-hours delay shifting when ownership technically kicks in.
Are you pulling data from your own custom property or using HubSpot’s native metric? If it’s the native one, that’s highly likely where the 45-minute mystery is coming from.
