37000 Feet | Browse and search NASA's Aviation Safety Reporting System |
|
Attributes | |
ACN | 1741839 |
Time | |
Date | 202005 |
Local Time Of Day | 0601-1200 |
Place | |
Locale Reference | ZZZ.Airport |
State Reference | US |
Environment | |
Flight Conditions | VMC |
Light | Daylight |
Aircraft 1 | |
Make Model Name | Commercial Fixed Wing |
Operating Under FAR Part | Part 121 |
Flight Phase | Parked Taxi |
Flight Plan | IFR |
Person 1 | |
Function | Captain Pilot Not Flying |
Qualification | Flight Crew Air Transport Pilot (ATP) Flight Crew Multiengine Flight Crew Instrument |
Events | |
Anomaly | Deviation - Procedural FAR Deviation - Procedural Published Material / Policy Deviation - Procedural Weight And Balance |
Narrative:
Some last minute passengers boarded the airplane. Due to new social distancing guidelines with passengers spreading out throughout the cabin I had a flight attendant perform a count. We received a paper clear from ramp. We entered the information and received good numbers and departed on time. Approximately 5 minutes after departure we received the close out data while taxiing and approaching the end of the runway. I assumed the zone data would be wrong; but the total passenger count would be correct. Because I was actively taxiing I asked the first officer to resend the data from the flight attendant count. ATC gave us our takeoff clearance which I instructed the first officer to reject the clearance and let them know we are working on an issue with our takeoff data. We held short of the runway were I was able to review the correct clear date from the paper copy and correct zone data based on the flight attendant count. We re-sent the data to make sure the data on file last sent was correct. We reviewed that nothing in the takeoff data had changed based on what we had sent prior to departure. The rest of the flight was normal. [X] days later I received notification from our company saying our passenger count was off by 'X'. They stated the auto close out numbers showed xx passengers but our manifest on file was showing yy; a difference of X. I sent my reply to our company stating the story I am telling here to explain the situation and apologize for any mistake on my; or my crews part. The next morning (X days after the flight) I received a reply from the company saying further investigation revealed airline updated there system showing yy passengers and apologizing to me stating our count was only off by 'X' passengers. But based on the original and updated notification I received we had yy both times so we should be correct. I'm filling this out as a precaution if we were off of our count due to any error between the gate agent and flight attendant; the flight attendant count; or our pilot inputs to the manifest. I tried to create time to fix the problem prior to takeoff and double check the manifest for accuracy; as well as the takeoff data. The one thing I failed to do was double check the total count of the auto closeout compared to our [count]. Prior to door close and departure I am fairly positive I asked the flight attendant if her total was verified with the agent prior to closing the door; as this is my normal habit with [passenger] counts; and she said yes. I had a great crew; so I had no reason to doubt the count. To sum up; I am not sure if our count was correct or off by one; but I am extremely sorry for any errors on my part. The cause was the auto closeout data coming through the system after departure while taxiing and automatically sending new takeoff data. When this happens it frustrating trying to re-input all of the corrections and find any required changes. Based on prior flights if there is any change in clear or passenger counts the closeout will knock out any inputs previously made; and verified by the crew. This can happen several times even if there is no change in closeout data. I'm not sure if the gate agents are clicking to close out the flight more than once or an error trying to transmit or receive the data from the system. This can cause a rushed and stressed environment if the closeout comes within a few minutes from departure. Particularly if the closeout gets sent multiple times with the same wrong data. This gets increasingly frustrating when the data comes in after departure and pushback or while taxiing. Knowing this I tried to do my best to create more time to avoid rushing and give us both (ca and first officer) together time to review all of the inputs and verify all of our takeoff data was correct and unchanged. We held short of the runway to accomplish this. A major contributing factor on my part was I failed to look at the takeoff data generated by the closeout to verify the total count. I assumed just the zones would be off. I should not have had that mindset. Because I was taxiing when the closeout data came in I did not have a chance to check the totals before the first officer started changing them. Had I caught this we could have called operations and resolved the issue prior to takeoff. This was also a failure on the first officer not to double check the total count prior to making any changes. The first officer was a sharp guy and had been performing great so I also trusted he looked at the data before making changes. I should not have trusted and assumed this would have taken place. Another factor could be a counting mistake by the flight attendant or failure to verify the total with the gate agent. A possible issue could be the gate agent just agreeing with the total the flight attendant said and not actually cross checking it with his computer total. But; I have a feeling the root cause; and what actually happened; was the gate agent did verify the correct total with the flight attendant based on the count; but failed to close out the flight prior to pulling the jet bridge.first and foremost require gate agents to close out the flight prior to coming down to pull the jet bridge. Prior to pulling the jet bridge verify we received the close out data. In our case we were operating off of a paper clear and [passenger] count; no closeout was received until after departure and pushback and we were already taxiing. Require gate agents to split up passengers for social distancing guidelines and not move passenger forward to avoid any weight and balance issues and passengers moving from assigned seats. That way the closeout data will actually be correct and usable and we can mitigate error in the chain such as input error; count error; and verification errors.
Original NASA ASRS Text
Title: Air carrier Captain reported issues with the passenger count on board and social distance seating guidelines which delayed the flight.
Narrative: Some last minute passengers boarded the airplane. Due to new social distancing guidelines with passengers spreading out throughout the cabin I had a Flight Attendant perform a count. We received a paper CLR from ramp. We entered the information and received good numbers and departed on time. Approximately 5 minutes after departure we received the close out data while taxiing and approaching the end of the runway. I assumed the ZONE data would be wrong; but the total passenger count would be correct. Because I was actively taxiing I asked the FO to resend the data from the FA count. ATC gave us our takeoff clearance which I instructed the FO to reject the clearance and let them know we are working on an issue with our takeoff data. We held short of the runway were I was able to review the correct CLR date from the paper copy and correct ZONE data based on the FA count. We re-sent the data to make sure the data on file last sent was correct. We reviewed that nothing in the takeoff data had changed based on what we had sent prior to departure. The rest of the flight was normal. [X] days later I received notification from our company saying our passenger count was off by 'X'. They stated the auto close out numbers showed XX passengers but our manifest on file was showing YY; a difference of X. I sent my reply to our company stating the story I am telling here to explain the situation and apologize for any mistake on my; or my crews part. The next morning (X days after the flight) I received a reply from the company saying further investigation revealed airline updated there system showing YY passengers and apologizing to me stating our count was only off by 'X' passengers. But based on the original and updated notification I received we had YY both times so we should be correct. I'm filling this out as a precaution if we were off of our count due to any error between the gate agent and FA; the FA count; or our pilot inputs to the manifest. I tried to create time to fix the problem prior to takeoff and double check the manifest for accuracy; as well as the takeoff data. The one thing I failed to do was double check the total count of the auto closeout compared to our [count]. Prior to door close and departure I am fairly positive I asked the FA if her total was verified with the agent prior to closing the door; as this is my normal habit with [passenger] counts; and she said yes. I had a great crew; so I had no reason to doubt the count. To sum up; I am not sure if our count was correct or off by one; but I am extremely sorry for any errors on my part. The cause was the auto closeout data coming through the system after departure while taxiing and automatically sending new takeoff data. When this happens it frustrating trying to re-input all of the corrections and find any required changes. Based on prior flights if there is any change in CLR or passenger counts the closeout will knock out any inputs previously made; and verified by the crew. This can happen several times even if there is no change in closeout data. I'm not sure if the gate agents are clicking to close out the flight more than once or an error trying to transmit or receive the data from the system. This can cause a rushed and stressed environment if the closeout comes within a few minutes from departure. Particularly if the closeout gets sent multiple times with the same wrong data. This gets increasingly frustrating when the data comes in after departure and pushback or while taxiing. Knowing this I tried to do my best to create more time to avoid rushing and give us both (CA and FO) together time to review all of the inputs and verify all of our takeoff data was correct and unchanged. We held short of the runway to accomplish this. A major contributing factor on my part was I failed to look at the takeoff data generated by the closeout to verify the total count. I assumed just the zones would be off. I should not have had that mindset. Because I was taxiing when the closeout data came in I did not have a chance to check the totals before the FO started changing them. Had I caught this we could have called Operations and resolved the issue prior to takeoff. This was also a failure on the FO not to double check the total count prior to making any changes. The FO was a sharp guy and had been performing great so I also trusted he looked at the data before making changes. I should not have trusted and assumed this would have taken place. Another factor could be a counting mistake by the FA or failure to verify the total with the gate agent. A possible issue could be the gate agent just agreeing with the total the FA said and not actually cross checking it with his computer total. But; I have a feeling the root cause; and what actually happened; was the gate agent did verify the correct total with the FA based on the count; but failed to close out the flight prior to pulling the jet bridge.First and foremost require gate agents to close out the flight prior to coming down to pull the jet bridge. Prior to pulling the jet bridge verify we received the close out data. In our case we were operating off of a paper CLR and [passenger] count; no closeout was received until after departure and pushback and we were already taxiing. Require gate agents to split up passengers for social distancing guidelines and not move passenger forward to avoid any weight and balance issues and passengers moving from assigned seats. That way the closeout data will actually be correct and usable and we can mitigate error in the chain such as input error; count error; and verification errors.
Data retrieved from NASA's ASRS site and automatically converted to unabbreviated mixed upper/lowercase text. This report is for informational purposes with no guarantee of accuracy. See NASA's ASRS site for official report.