Narrative:

The shift started with weather in the ZKC32 and ZKC92 with numerous deviations. The flow board read only 12 miles in trail to ord; and did not specify what routes were in use due to the weather. I brought this to the attention of the supervisor and they said they would check on it. I observed a deviating stream on the keokk fix; and a stream over spi going into ord. The supervisor came back about 5 minutes later and said that the only two streams in use were the ones I had just observed. The flow board did not change indicating we could not use vinca. I also asked the supervisor what the weather was going to do that night and he said it wouldn't be a problem and would either dissipate slowly or move north. Neither of these happened. After coming back from break; the weather had moved into the northern half of sector 84. There were numerous ord arrivals being routed through our airspace due to a flow implementation by tmu at ZAU and ZKC (a knox royku). The aircraft were coming to us at varying altitudes between FL260 and FL350. Three streams were converging on stl and routed stl TRTLL3. This route was not working and all of the aircraft had to be re-routed once entering our airspace to pnt TRTLL3. This could only be accomplished with the drop down in uret; and gateway (sector 12) put a further restriction on us to have the ord landers at or below FL270 prior to their boundary. I also tried to route an aircraft from my stream to the keokk stream to alleviate congestion (at the supervisor's request) and the pilot refused due to weather. On three separate occasions I told the supervisor that this route was not working; and not only were they increasing my work load but they were unnecessarily making the aircraft fly west to stl and then be turned back to the east for sequencing back through gateway's airspace (ZKC12). On all three occasions the supervisor left and came back and said 'that's the way they want them'. I was essentially taking ZID ord landing traffic from the east direct stl and turning them back to the northeast through ZKC12. There was never a route established and I had to use pnt TRTLL3 on my own; the sector was becoming over saturated with ord arrivals and eventually I had to shut off everyone to fix the mess that was around stl. I had basically 40 - 50 miles of airspace to blend three streams of ord arrivals that were deviating and having to be descended for ZKC12. We also had a limited amount of mdw arrivals in the mix that apparently needed to be at or below FL230. This was also not on the flow board. ZKC 94 that was above me was also very busy with deviations and the ord arrivals that he was having to descent through his enroute traffic for the altitude restriction. He was getting his aircraft from FL350 or above and having to blend them with my deviating stream into ZKC12. This event occurred when the ZKC94 controller offered me a point out on SKW5365 and referenced my traffic going to ord. SKW5365 was an ord lander that had been missed and was now being vectored behind my traffic in trail. I reluctantly approved the point out but told the ZKC94 controller I should talk to him since he had to get to FL270 and I had the stream. The ZKC94 controller had traffic as well so he kept SKW5365 and was vectoring him for the sequence. I believe he got behind with something else because I observed him descending SKW5365 through SKW3113 that I was also vectoring for ord. I verbally told him about the traffic again and he asked me to stop SKW3113 at FL290. SKW5365 was at FL332 at this point in a descent to FL270. He then asked me to keep SKW3113 going to FL270 and expedite. I did this but SKW5365 was already at FL290 because he expedited him as well. At this time SKW3113 was at FL281 and SKW5965 was at FL290.the sectors were busy enough with weather; routes; in trail; and increased workload associated with these factors. The ZKC94 controller had just taken the sector and I think he missed the ord sequence and altitude restriction which caused him to have to expedite SKW5365 down for his traffic. This contributed to the event; but ultimately I should have refused the pointout and issued a control instruction and radar contact once he cleared his traffic. There were numerous factors that contributed to this event though. - Very poor coordination between ZKC tmu and the ri controllers. - Very poor supervisor involvement in what was happening at the sectors. - WX and an unusable routing to ord led to increased difficulty and sector saturation.

Related reports:

Google
 

Original NASA ASRS Text

Title: Kansas City Center [ZKC] Controller reported of a loss of separation due to weather; workload; traffic deviating; and having to come up with deviation routes on the fly. Reporter wanted to accept the aircraft instead of taking a point out but did not and a loss of altitude separation ensued.

Narrative: The shift started with weather in the ZKC32 and ZKC92 with numerous deviations. The flow board read only 12 miles in trail to ORD; and did not specify what routes were in use due to the weather. I brought this to the attention of the Supervisor and they said they would check on it. I observed a deviating stream on the KEOKK fix; and a stream over SPI going into ORD. The Supervisor came back about 5 minutes later and said that the only two streams in use were the ones I had just observed. The flow board did not change indicating we could not use VINCA. I also asked the supervisor what the weather was going to do that night and he said it wouldn't be a problem and would either dissipate slowly or move north. Neither of these happened. After coming back from break; the weather had moved into the northern half of Sector 84. There were numerous ORD arrivals being routed through our airspace due to a flow implementation by TMU at ZAU and ZKC (a KNOX ROYKU). The aircraft were coming to us at varying altitudes between FL260 and FL350. Three Streams were converging on STL and routed STL TRTLL3. This route was not working and all of the aircraft had to be re-routed once entering our airspace to PNT TRTLL3. This could only be accomplished with the drop down in URET; and Gateway (sector 12) put a further restriction on us to have the ORD landers at or below FL270 prior to their boundary. I also tried to route an aircraft from my stream to the KEOKK stream to alleviate congestion (at the supervisor's request) and the pilot refused due to weather. On three separate occasions I told the Supervisor that this route was not working; and not only were they increasing my work load but they were unnecessarily making the aircraft fly west to STL and then be turned back to the East for sequencing back through Gateway's airspace (ZKC12). On all three occasions the Supervisor left and came back and said 'that's the way they want them'. I was essentially taking ZID ORD landing traffic from the east direct STL and turning them back to the NE through ZKC12. There was never a route established and I had to use PNT TRTLL3 on my own; The sector was becoming over saturated with ORD arrivals and eventually I had to shut off everyone to fix the mess that was around STL. I had basically 40 - 50 miles of airspace to blend three streams of ORD arrivals that were deviating and having to be descended for ZKC12. We also had a limited amount of MDW arrivals in the mix that apparently needed to be at or below FL230. This was also not on the flow board. ZKC 94 that was above me was also very busy with deviations and the ORD arrivals that he was having to descent through his enroute traffic for the altitude restriction. He was getting his aircraft from FL350 or above and having to blend them with my deviating stream into ZKC12. This event occurred when the ZKC94 controller offered me a point out on SKW5365 and referenced my traffic going to ORD. SKW5365 was an ORD lander that had been missed and was now being vectored behind my traffic in trail. I reluctantly approved the point out but told the ZKC94 controller I should talk to him since he had to get to FL270 and I had the stream. The ZKC94 controller had traffic as well so he kept SKW5365 and was vectoring him for the sequence. I believe he got behind with something else because I observed him descending SKW5365 through SKW3113 that I was also vectoring for ORD. I verbally told him about the traffic again and he asked me to stop SKW3113 at FL290. SKW5365 was at FL332 at this point in a descent to FL270. He then asked me to keep SKW3113 going to FL270 and expedite. I did this but SKW5365 was already at FL290 because he expedited him as well. At this time SKW3113 was at FL281 and SKW5965 was at FL290.The sectors were busy enough with weather; routes; in trail; and increased workload associated with these factors. The ZKC94 controller had just taken the sector and I think he missed the ORD sequence and altitude restriction which caused him to have to expedite SKW5365 down for his traffic. This contributed to the event; but ultimately I should have refused the pointout and issued a control instruction and radar contact once he cleared his traffic. There were numerous factors that contributed to this event though. - Very poor coordination between ZKC TMU and the RI controllers. - Very poor supervisor involvement in what was happening at the sectors. - WX and an unusable routing to ORD led to increased difficulty and sector saturation.

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.